Email Authentication Guide
DMARC Quarantine vs Reject
Understanding the difference between quarantine and reject — and why moving too fast breaks legitimate mail.
1. What Each Policy Does
DMARC policies are instructions you publish in DNS that tell receiving mail servers what to do with messages that fail authentication. There are three options:
p=none (Monitoring Only)
No enforcement. Messages that fail DMARC are delivered normally. You receive reports about authentication results, but nothing is blocked or redirected. This is where every domain should start.
p=quarantine (Soft Enforcement)
Failing messages are routed to the recipient's spam or junk folder. The mail is still delivered — recipients can find it if they look — but it's flagged as suspicious. This is the intermediate enforcement step.
p=reject (Full Enforcement)
Failing messages are dropped entirely. The receiving server refuses the message — it is never delivered to any folder. The sender typically receives a bounce notification, but the recipient never sees the message at all.
These policies are instructions, not guarantees. Not every receiving server handles them identically. However, major providers — Google Workspace, Microsoft 365, Yahoo — honor quarantine and reject policies consistently. For the vast majority of email traffic, these policies work as specified.
2. Quarantine vs Reject: The Tradeoffs
| Quarantine | Reject | |
|---|---|---|
| Failing mail goes to | Spam/junk folder | Dropped entirely |
| Recoverable? | Yes — recipients can check spam | No — message never delivered |
| Spoofing protection | Partial — spoofed mail reaches junk | Full — spoofed mail is blocked |
| Risk to legitimate mail | Lower — misconfigured senders land in spam | Higher — misconfigured senders are silently dropped |
| Best when | You're not 100% sure all senders are configured | You have high confidence in your sender inventory |
| Reversibility | Effectively reversible | Not reversible per-message |
Key insight: Quarantine is a safety net. If a legitimate sender fails alignment, their messages land in spam where someone can still find them. At reject, those messages disappear without a trace. The difference matters most for senders you didn't know about.
3. Common Rollout Mistakes
Most DMARC enforcement failures aren't caused by the protocol itself — they're caused by rushing the rollout. These are the mistakes we see repeatedly:
Jumping straight from p=none to p=reject
Skipping quarantine means you have no intermediate step where legitimate mail is flagged but still recoverable. If you miscounted your senders, you won't know until someone complains that their email vanished.
Relying on the pct= tag to ramp enforcement
Earlier DMARC used the pct= tag to apply your policy to a fraction of failing traffic. RFC 9989 (DMARCbis) removed it because receiver behavior was inconsistent, and many receivers now ignore it. Don't build your rollout around a percentage — move the whole policy in stages (p=none → p=quarantine → p=reject) gated by observation windows.
Forgetting about mailing lists and forwarding
Mailing lists and auto-forwards are the most common source of false failures. When a mailing list resends your message, it sends from its own IP — breaking SPF. If it modifies the body (adding a footer, for example), DKIM can break too. These need to be accounted for before enforcement.
Not monitoring reports during the transition
Changing your DMARC policy without watching aggregate reports is flying blind. You need to know which senders are failing and whether they're legitimate before each escalation step.
Relying on SPF alone without DKIM
SPF validates the sending server's IP address, which breaks whenever mail is forwarded. DKIM validates a cryptographic signature on the message itself, which survives forwarding as long as the message body isn't modified. If you enforce DMARC without DKIM configured for all your senders, forwarded mail will fail. Set up DKIM before you enforce.
4. A Safe Rollout Model
This is the rollout sequence we recommend. It's not the fastest path — it's the safest one. Each step gives you a checkpoint to verify nothing is broken before moving forward.
- Start with
p=noneand monitor for 2-4 weeks. Publish your DMARC record withrua=pointing to a monitoring address. Collect aggregate reports and build a picture of every service sending as your domain. - Identify and authorize all legitimate senders. Review your reports. For every sender that should be sending as your domain, ensure their IP is in your SPF record and DKIM is configured with proper alignment. Use the DMARC checker to verify your records.
- Move to
p=quarantineonce your legitimate senders authenticate cleanly. This moves the whole policy, not a fraction of traffic — every message that fails DMARC now goes to spam. That's why you confirm your reports are clean before making the change, rather than ramping a percentage. - Observe quarantine for 2-4 weeks. Watch for complaints, delivery issues, or new senders appearing in reports that you missed. If something breaks, you can roll back to
p=noneimmediately. Give the window long enough to cover infrequent senders — quarterly billing runs, seasonal campaigns — before advancing. - Move to
p=rejectafter a stable observation window. Once quarantine has run cleanly with no legitimate mail affected, advance the whole policy to reject. Fix any alignment issues that surface before you make the change. - Maintain
p=reject— full enforcement. At this point, every message that fails DMARC is rejected. Your domain is fully protected against spoofing. Continue monitoring — new senders and configuration changes can reintroduce failures.
Note on pct=: Earlier DMARC used the pct= tag to apply the stated policy to a percentage of failing messages. Receiver behavior was never consistent — some treated it as a probability per message, others batched or ignored it — so RFC 9989 (DMARCbis) removed it. Don't plan your rollout around a percentage; move the whole policy in stages gated by observation windows instead.
5. What Breaks During Enforcement
These are the real-world scenarios that cause legitimate mail to fail DMARC after you tighten policy:
Mailing list forwarding
When you send to a mailing list (like a Google Group or Mailman list), the list server resends your message from its own IP address. This breaks SPF because the sending IP no longer matches your SPF record. DKIM usually survives — unless the list modifies the message body by adding a footer, subject prefix, or other changes. If both fail, DMARC fails.
Email forwarding rules
Auto-forwards from one mailbox to another (for example, forwarding from an old address to a new one) break SPF for the same reason as mailing lists: the forwarding server's IP isn't in your SPF record. DKIM typically survives forwarding if the message isn't modified, but many forwarding setups add headers or modify the envelope in ways that can cause issues.
Third-party senders you forgot
Marketing platforms, CRM systems, helpdesk software, newsletter tools, transactional email services, survey tools — any service that sends email as your domain needs to be in your SPF record and configured with DKIM. Organizations frequently discover senders they didn't know about only after enforcement causes failures. This is why the monitoring phase exists.
Subdomain mail
If you set sp=reject in your parent domain's DMARC record, every subdomain without its own DMARC record inherits that policy. This catches people off guard when a subdomain they didn't think about — like events.yourdomain.com or support.yourdomain.com — suddenly has mail rejected because it inherited the parent's strict policy without having SPF or DKIM configured.
6. How Monitoring Supports Safer Enforcement
Enforcement without visibility is guesswork. The entire risk of tightening DMARC policy comes from not knowing what will break. Monitoring eliminates that uncertainty.
With proper DMARC monitoring, you can see exactly which senders pass and fail authentication, which messages would be affected by a policy change, and whether your SPF and DKIM records are correctly configured — all before you change anything in DNS.
Some platforms take this further with enforcement simulation — the ability to preview what would happen at quarantine or reject without actually changing your DMARC record. You can see exactly which senders would be quarantined or rejected, review whether they're legitimate, and fix any issues before making the policy change.
This eliminates the guesswork from the rollout. Instead of changing the policy and hoping nothing breaks, you change the policy knowing exactly what the impact will be.
FAQ
Can I go directly from p=none to p=reject?
Technically, yes. Practically, you shouldn't — unless you have complete visibility into your sending ecosystem and are confident every legitimate sender is properly authenticated. Skipping quarantine means any misconfigured sender's mail will be silently dropped with no safety net. Quarantine gives you a chance to catch mistakes before they become invisible.
What does pct=10 mean in a DMARC record?
Historically, it told receiving servers to apply the stated policy (quarantine or reject) to only 10% of messages that fail DMARC, treating the remaining 90% as if the policy were p=none. RFC 9989 (DMARCbis) removed the pct= tag because receiver behavior was inconsistent, and many receivers now ignore it. Instead of ramping a percentage, move the whole policy in stages gated by observation windows.
Will quarantine affect my email deliverability?
Quarantine sends failing messages to spam, which will impact legitimate mail if those senders aren't properly authenticated. That's exactly why you monitor first: to identify and fix all legitimate senders before enforcement affects them. If your monitoring data is clean — all legitimate senders passing — quarantine will only affect unauthorized mail.
How long should I stay at quarantine before moving to reject?
Until you're confident no legitimate mail is being quarantined. For most organizations, 2-4 weeks at quarantine with clean reports is sufficient. If you're seeing failures from senders you can't identify, stay at quarantine longer and investigate. Don't move to reject until your reports are consistently clean.
What happens to mail from senders I haven't authorized?
At quarantine, it goes to the recipient's spam folder. At reject, it's dropped entirely and never delivered. Either way, the original sender isn't notified by your domain — they won't know their mail was blocked unless they check their own DMARC reports or receive a bounce from the receiving server (which only happens at reject, and not always).
Should I set sp= (subdomain policy) to the same as p=?
Not necessarily. Subdomains you don't use for email should have sp=reject to prevent subdomain spoofing — attackers frequently target unused subdomains precisely because they lack authentication records. But subdomains with active email need their own DMARC records, SPF, and DKIM configuration, along with their own monitoring. Enforce them independently.
Enforce with confidence, not guesswork
SpoofSentry shows exactly which senders pass and fail before you tighten policy. Simulate enforcement without changing your DNS.