Dr.Who
← blog

DMARC p=none vs quarantine vs reject: which policy you actually want

· dmarc · email · spoofing · deliverability · policy

dmarcemailspoofingdeliverabilitypolicy

You want p=reject. It is the only DMARC policy that actually stops someone from sending mail as your exact domain. p=none is monitoring only — receivers take no action on failing mail, so it gives you reports but zero spoofing protection. p=quarantine routes failing mail to the spam folder. The catch: you cannot jump straight to reject without first fixing SPF/DKIM alignment, or you will bounce your own legitimate mail. The safe path is none → quarantine → reject, with pct ramps in between.

What each policy actually does

The policy lives in the p= tag of your _dmarc TXT record and tells receiving servers how to handle mail that fails DMARC (fails SPF/DKIM alignment):

  • p=none — take no action. Deliver the failing message as if DMARC were not published, but send aggregate reports to your rua address. This is monitoring only.
  • p=quarantine — treat failing mail as suspicious. In practice receivers drop it in the spam/junk folder.
  • p=reject — refuse failing mail outright. The receiver returns a 5xx at the SMTP transaction, so the message never lands anywhere.

A live reject record looks like this:

v=DMARC1; p=reject; rua=mailto:[email protected]; adkim=s; aspf=s

p=none gives you zero protection (the big misconception)

This is the one people get wrong. Publishing v=DMARC1; p=none does not stop spoofing. It tells the world your domain is DMARC-aware, but it explicitly instructs receivers to deliver forged mail anyway. Anyone can still send From: [email protected] and it will reach the inbox.

none exists for one reason: discovery. The rua aggregate reports show you every IP sending as your domain — your real ESPs, that forgotten CRM, the billing platform nobody documented, and the actual attackers. You stay at none only long enough to find and authenticate all of them.

Why you cannot skip to reject

DMARC passes when SPF or DKIM passes and that result aligns with your From: domain. Plenty of legitimate senders pass raw SPF but fail alignment (the bounce domain is your ESP's, not yours). Flip straight to p=reject with even one misaligned stream and the receiver rejects your real invoices, password resets, and newsletters at the edge. That is a self-inflicted outage — and from the user's seat it looks exactly like an attack.

So: read reports at none, get every legitimate sender aligned, and only then start tightening.

The pct tag: ramp, do not flip

pct applies the policy to a percentage of failing mail; the rest falls back to the next-weaker policy. It is your gradual rollout dial. A sane sequence:

v=DMARC1; p=none; rua=mailto:[email protected]
v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected]
v=DMARC1; p=quarantine; pct=50; rua=mailto:[email protected]
v=DMARC1; p=quarantine; rua=mailto:[email protected]
v=DMARC1; p=reject; rua=mailto:[email protected]

Sit at each step for at least one to two weekly report cycles. If reports stay clean — only legitimate, aligned senders failing nothing — advance. If a real sender shows up failing, fix its SPF/DKIM before you raise pct. (Note: pct only applies below reject in newer receiver behavior, so do the real ramping at quarantine.)

Check which policy your domain is publishing →

Further reading