DMARC quarantine vs reject explained

Once you have published a DMARC record, you face a decision: stay at p=none, move to p=quarantine, or enforce with p=reject. Getting the progression wrong in either direction causes real problems — move too fast and you break legitimate mail; stay at p=none forever and you have no protection against spoofing.

This article explains exactly what each policy does, when to advance, and how to use the pct= knob to roll out enforcement safely.

For a full introduction to DMARC, read What is DMARC?.

The three DMARC policies

All three policies still produce DMARC aggregate reports when you have a rua= address in your record. The policy only controls what happens to failing messages — it does not affect reporting.

What p=none does (monitor mode)

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

p=none is the observation phase. Receiving servers treat all messages normally — they do not filter or reject anything based on DMARC. Your aggregate reports accumulate data showing:

• Which IP addresses are sending mail that claims to be from your domain
• Whether those messages pass SPF, DKIM, and DMARC
• What volume each source is sending

This phase is not optional. Skip it and you will break legitimate mail when you enforce. Stay in it too long and you have no protection. The recommended window is 2–4 weeks — enough to see all your regular sending patterns across a full send cycle.

p=none is also the policy to fall back to if you discover a misconfigured sender after advancing to quarantine or reject. Retreat, fix the sender, confirm it passes in reports, then re-advance.

What p=quarantine does

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"

p=quarantine moves failing messages to the spam or junk folder at the receiving mail server. The message still reaches the recipient — they can find it if they look — but it is out of the inbox.

This policy is useful as a transition step. It catches real spoofing attacks (spam filters route the phishing emails away from inboxes) while still allowing legitimate mail that fails authentication to be recovered by recipients. If a forgotten sender breaks under quarantine, affected users notice spam-folder deliveries and can flag it before it becomes an invisible hard fail.

Use quarantine until you are confident your reports show no unexpected failing sources.

What p=reject does

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com"

p=reject is full enforcement. Receiving servers drop messages that fail DMARC entirely. The message does not reach the inbox, the spam folder, or the recipient at all. The sending server typically receives a bounce (5xx SMTP rejection).

This is the goal. A domain at p=reject with complete SPF and DKIM coverage for all legitimate senders cannot be spoofed in the From: header — any forged message gets rejected before delivery.

The cost of advancing too early is immediate: legitimate mail from a sender you forgot to configure disappears with no recovery path. Recipients never see it; they have no spam folder to check.

When to advance from quarantine to reject

Work through this checklist before moving to p=reject:

1. All legitimate senders pass SPF or DKIM. Your aggregate reports should show consistent pass rates for every source you recognise. No known senders should appear in the fail column.

2. No unexplained sources in reports. The reports may show IP addresses you do not recognise. Investigate each one before advancing. Some will be legitimate (a CRM you forgot, a subsidiary's mail tool). Others will be spoofers — that is exactly what you are trying to stop. Only advance when every IP in your reports is accounted for.

3. Alignment is confirmed. Passing SPF or DKIM is not enough — the authenticated domain must align with the From: header domain. Check that your aggregate reports show DMARC pass (not just SPF pass or DKIM pass) for all your senders.

4. Reports show a low DMARC fail rate from legitimate sources. A small residual fail rate from forwarded mail (mailing lists, email forwarding services) is normal and expected — those messages will be dropped at p=reject. Confirm those sources are genuinely not under your control before accepting the loss.

5. Your team is aware of the change. Reject-mode failures are invisible to recipients. Make sure support and operations teams know to check DMARC aggregate reports if a user reports missing email.

The pct= rollout knob

The pct= tag applies your policy to a random percentage of failing messages. The remainder are treated as if the policy were p=none.

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@example.com"

This record applies quarantine to 10% of failing messages. The other 90% are delivered normally.

pct= gives you a staged rollout path:

Moving through these stages over several weeks — checking aggregate reports at each step — significantly reduces the risk of breaking legitimate mail. Most organisations spend 2–4 weeks at stage 1, a few days to a week at stage 3, then advance quickly through stages 4 and 5 once confidence is high.

Note that pct= applies only to the quarantine and reject actions. It has no effect on reporting — you always receive full aggregate reports regardless of pct=.

Monitoring your DMARC policy with DomainCare

DomainCare's email deliverability check monitors your DMARC record every 6 hours. If the p= policy changes unexpectedly — for example, a team member accidentally downgrades from reject to none — the dmarc_policy_changed alert fires immediately.

An undetected policy downgrade removes your phishing protection silently. Monitoring ensures that any change is intentional or investigated fast.

For a step-by-step diagnosis when DMARC is failing, see Fix a DMARC failure.