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.
Not using the pct= tag
The pct= tag lets you apply the policy to a percentage of failing traffic. Without it, you go from 0% enforcement to 100% in a single DNS change. There's no reason to skip this.
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=quarantine; pct=10. Only 10% of messages that fail DMARC will be sent to spam. The other 90% are still delivered normally. This lets you test enforcement impact on a small fraction of traffic. - Monitor for 1-2 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. - Increase to pct=25, then pct=50, then pct=100. At each step, monitor for at least a week. Look for legitimate senders that are newly failing. Fix alignment issues as they surface.
- Move to
p=reject; pct=10. Once quarantine at pct=100 is stable and your reports are clean, begin the same ramp with reject. At this stage, 10% of failing mail is dropped entirely. - Gradually increase reject percentage. pct=25, pct=50, pct=100 — same cadence as quarantine. Monitor at each step.
- Reach
p=reject; pct=100— 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=: The pct= tag tells receivers to apply the stated policy to a percentage of failing messages. Not all receivers honor it precisely — some treat it as a probability per message, others batch — but major providers (Google, Microsoft, Yahoo) support it. It's the best mechanism available for gradual rollout.
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?
It tells receiving servers to apply the stated policy (quarantine or reject) to only 10% of messages that fail DMARC. The remaining 90% are treated as if the policy were p=none. It's a gradual rollout mechanism that lets you test enforcement on a fraction of traffic before going all-in.
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 pct=100 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.