DMARC Reject vs Quarantine: How to Choose and Roll Out

Which DMARC Policy Should You Use: Reject or Quarantine?

The question comes up every time an organization finishes setting up SPF and DKIM: should the DMARC record say p=quarantine or p=reject?

The short answer: use whichever you have earned the right to use. If you have spent 4 to 8 weeks at p=none reviewing aggregate reports and confirmed every legitimate sending source passes DMARC alignment, p=reject is safe. If you have not, it will break something.

This guide explains what each policy level does in practice, what typically goes wrong during rollout, and how to move from p=none to p=reject without discovering the problem at the moment an invoice gets bounced.

What p=none Does: Your Monitoring Baseline

p=none tells receivers to take no action on messages that fail DMARC. The messages pass through normally. At this stage your DMARC record is invisible to receiving servers in terms of filtering behavior.

The entire purpose of p=none is the aggregate reports. These arrive daily from every major receiver (Gmail, Yahoo, Microsoft 365, and most mid-size mail providers) as XML files. They tell you exactly which IPs are sending on behalf of your domain, whether they are passing SPF and DKIM alignment, and which receivers are seeing failures.

Four to eight weeks at p=none is the minimum. Skipping this step is the most common cause of email breakage when organizations move to enforcement prematurely. Without aggregate reports, you are guessing which senders are aligned and which are not.

What p=quarantine Actually Does

p=quarantine tells receiving servers to treat DMARC failures as suspicious. The practical result depends entirely on the receiver:

Gmail may route the message to the spam or junk folder
Microsoft 365 may quarantine it or route it to junk, depending on tenant settings
Smaller providers may deliver normally or quarantine selectively

p=quarantine is not equivalent to "send to spam." It is closer to "apply your own suspicion threshold." Some receivers treat quarantine as a soft redirect to junk. Others treat it as borderline and still deliver. You cannot rely on consistent behavior across providers.

This variation is why p=quarantine is better understood as a monitoring tool than an enforcement tool. It surfaces alignment problems without the full impact of outright rejection. Any legitimate failures at this stage will show up as messages in spam rather than silent disappearance, which means users are more likely to notice and report the problem.

What p=reject Actually Does

p=reject tells receiving servers to refuse delivery of messages that fail DMARC alignment. The server should generate a bounce and not deliver the message to the recipient mailbox.

Most major receivers honor this fully. Gmail, Yahoo, and Microsoft 365 all handle p=reject as specified in RFC 9989. Some smaller providers implement it inconsistently or not at all.

The critical thing p=reject does not do: it does not protect against look-alike domains, it does not automatically cover subdomains unless you have subdomain policies, and it does not protect domains you do not control. If someone sends from examp1e.com pretending to be example.com, p=reject does nothing because the From: domain is technically different.

Alignment: Strict vs Relaxed Mode

Alignment determines how strictly SPF and DKIM results must match the From: domain. This affects whether your policy will break at each level.

Relaxed alignment: the organizational domain must match. example.com and mail.example.com are considered aligned. This is what most organizations use because it accommodates subdomain senders.

Strict alignment: the domains must match exactly. If your DMARC policy domain is example.com and a message comes from mail.example.com, it fails strict alignment even if SPF and DKIM are technically correct.

If your organization sends from subdomains (a marketing platform sending from sends.example.com, a billing system sending from billing.example.com), strict alignment will fail at those sources unless each subdomain has its own aligned DKIM key. Relaxed alignment handles this by default.

For most organizations, relaxed alignment is the practical choice. The security benefit of strict alignment is marginal compared to the operational complexity it adds.

Decision Framework: Which Policy Fits Your Situation

Start with p=none for at least 4 to 8 weeks. Identify every IP and service sending mail on your behalf. Verify each one passes alignment in your aggregate reports.

Move to p=quarantine when p=none shows no unexpected failures. Run this for another 4 to 8 weeks. Watch for any legitimate mail appearing in spam or quarantine folders. Fix alignment issues as they surface.

Move to p=reject only when p=quarantine shows zero unexpected failures. If anything fails alignment at p=quarantine, it will stop delivering at p=reject. Fix it first.

Stay at p=none or p=quarantine if your domain has many third-party senders (marketing platforms, SaaS billing, CRM tools) that you cannot fully audit for alignment. Every untracked sender becomes a potential email outage at p=reject.

Third-Party Senders and Subdomain Considerations

Third-party senders are the most common source of problems at p=reject. If you use a marketing platform, billing system, helpdesk, or any other service that sends email with your From: domain, that sender must be aligned.

The standard checklist for each third-party sender:

1. Confirm they DKIM-sign with your domain (most major platforms do this by default)
2. Confirm their sending IPs are in your SPF record
3. Test at p=none and verify alignment appears in your aggregate reports
4. Move to p=quarantine and confirm no new failures
5. Only then move to p=reject

Subdomain policies are separate. A p=reject record on example.com does not apply to mail.example.com or newsletter.example.com. If you send from subdomains, publish separate DMARC records for each one, or use a wildcard record (*._dmarc.example.com) to cover all subdomains at once. Check aggregate reports for each subdomain separately.

The Three-Phase Rollout Plan

Phase 1: p=none for 4 to 8 weeks

Set your DMARC record to:


v=DMARC1; p=none; rua=mailto:your-reports@example.com; pct=100

Collect and review daily aggregate reports. Build a complete list of every source sending on your domain. Verify each one passes alignment.

Phase 2: p=quarantine for 4 to 8 weeks


v=DMARC1; p=quarantine; rua=mailto:your-reports@example.com; pct=100

Watch for new senders appearing unexpectedly. Any new source at this stage that fails alignment will not cause hard bounces -- it will appear in spam folders, which users tend to notice and report. Fix issues before they become outages.

Phase 3: p=reject when reports are clean


v=DMARC1; p=reject; rua=mailto:your-reports@example.com; pct=100

Make this switch only after a clean p=quarantine phase with zero unexpected alignment failures. If something goes wrong, update your DNS record to step back to p=quarantine. DNS changes take minutes to propagate.

What Google and Yahoo Require in 2024

Google and Yahoo's 2024 bulk sender requirements added real consequences for DMARC non-compliance. If you send more than 5,000 messages per day to Gmail or Yahoo addresses:

p=reject is required, not a best practice recommendation
Valid SPF and DKIM are required for delivery
One-click unsubscribe headers are required in RFC 5321 message headers

If you are at p=none or p=quarantine and sending bulk to Gmail or Yahoo addresses, you are already non-compliant with their deliverability requirements. Moving to p=reject is not just good security hygiene -- it is a prerequisite for reaching those inboxes.

FAQ

What happens if a legitimate sender fails DMARC after I switch to p=reject?

Their mail is discarded. The sending system typically generates a bounce message. Fix the alignment issue (confirm DKIM signing is active for your domain and the sending IP is in your SPF record) and have them resend. If you are seeing unexpected failures, step back to p=quarantine immediately while you investigate.

Does p=quarantine still cause email problems?

Yes. If a receiver treats quarantine as "send to spam," transactional mail like password resets, invoices, and notifications may reach spam instead of the inbox. Users often do not check spam for transactional mail. For high-reliability email streams, p=quarantine is not risk-free.

Does p=reject stop all email spoofing of my domain?

No. p=reject stops exact-domain spoofing where the From: address exactly matches your domain and alignment fails. It does not stop look-alike domains (examp1e.com vs example.com), it does not protect subdomains unless you have subdomain policies, and it does not protect domains you do not own.

How do I read aggregate reports without a tool?

Manually, it is painful. DMARC aggregate reports are XML files that require parsing. They contain per-receiver breakdowns of pass and fail counts by source IP. Organizations running p=none at scale typically use a DMARC monitoring tool to make this interpretable. DMARCFlow parses these reports automatically, flags new senders, and tracks alignment pass rates over time so you do not need to open raw XML files.

What does pct=100 mean in a DMARC record?

pct controls what percentage of messages the policy applies to. pct=100 means 100 percent. Starting with a lower percentage (like pct=10) applies the policy to only 1 in 10 messages, which can be useful for cautious testing after a long p=none run. At pct=100, every failing message is affected.

How DMARCFlow Fits Into This Process

Every step of the rollout described above depends on aggregate report data. Without it, you are operating blind. At p=none, you need reports to identify senders. At p=quarantine, you need them to catch new failures. At p=reject, you need them to catch any sources you missed before they cause an outage.

DMARCFlow reads DMARC aggregate reports and converts them into a readable format that surfaces failures by source, flags new senders that appear without your knowledge, and tracks alignment pass rates over time. The practical benefit during a rollout: before moving from p=none to p=quarantine, DMARCFlow shows you exactly which IPs are failing and why. Before moving to p=reject, it confirms that no unexpected failures are present. If a new source starts sending unaligned mail after you have switched to p=reject, DMARCFlow alerts you before that becomes an invoice that never arrived.

Running DMARC at p=none without a report parsing tool is technically possible but practically painful. The reports exist specifically to make policy rollout survivable.