Quick DMARC policy reference
DMARC has three policy values: p=none (monitor only), p=quarantine (route failing mail to spam), and p=reject (refuse delivery entirely). The roll-out roadmap is to move from one to the next as confidence builds, not to publish reject on day one. Moving too fast breaks legitimate mail; staying at none indefinitely defeats the standard.
p=none | Monitor mode. Aggregate reports flow, no filtering action. Compliant with Gmail and Yahoo bulk rules. |
p=quarantine | Failing messages routed to spam folder. First real enforcement layer. Recoverable: recipients can dig messages out. |
p=reject | Failing messages refused at SMTP. Strongest protection against impersonation. Not recoverable: rejected mail is gone. |
| Typical timeline | 2-4 weeks at none, 4-8 weeks at quarantine, then reject if reports are clean |
| BIMI requirement | quarantine with pct=100 or reject (any pct, full coverage best) |
The three DMARC policies
DMARC publishes a policy in DNS that tells receiving mail servers what to do with messages claiming to be from your domain that fail authentication. The policy is the p= tag in your DMARC TXT record at _dmarc.example.com. Three values exist:
p=none
Monitor only. The receiver checks SPF and DKIM alignment, records the result, and delivers the message as if DMARC didn’t exist. Aggregate reports flow back to the addresses listed in your rua= tag, giving you visibility into which sources pass and which fail, without any action being taken on failing mail.
p=quarantine
Soft enforcement. Messages that fail DMARC are routed to the recipient’s spam or junk folder instead of the primary inbox. The receiver still accepts the message at the SMTP layer, so it’s not bounced; recipients can find quarantined messages by checking spam. This is the safety net layer: legitimate mail you didn’t account for gets quarantined, not lost.
p=reject
Hard enforcement. Messages that fail DMARC are refused at the SMTP layer with a 5xx response. They never reach the recipient at all. This is the strongest protection against impersonation, and it is also the most dangerous policy to publish without preparation. A single misconfigured legitimate sender (say, a forgotten transactional ESP) and you’ve blackholed its mail to your own customers.
An additional tag, pct=N, lets you apply the policy to only a percentage of failing mail. p=quarantine; pct=25 means 25 % of failing messages get quarantined, 75 % are delivered. Useful for gradual roll-out, especially the move from quarantine to reject. Default is pct=100.
Why p=none is not enough
p=none is monitor mode. It gives you reports. It doesn’t actually protect your domain from being impersonated, because failing mail is still delivered. A spammer using your domain in their From address gets through to receivers as long as the recipient’s spam filter doesn’t catch them on other signals.
Many senders publish p=none and consider DMARC “done”. This was a fair posture until February 2024, when Gmail and Yahoo’s bulk sender rules made DMARC alignment mandatory for any sender exceeding 5,000 messages per day. p=none satisfies the technical requirement (a DMARC record exists), but it provides no impersonation protection and no real defense against your brand being weaponized in phishing campaigns.
The full value of DMARC requires moving to quarantine and ideally reject. The roll-out is the work; p=none is the starting line, not the finish.
The roll-out roadmap
Three phases, each with clear exit criteria:
Phase 1: p=none with reports flowing
Goal: see every source of mail claiming to be from your domain.
Setup: publish DMARC with p=none, a valid rua= address (your DMARC report aggregator, like Postmark, dmarcian, or EasyDMARC). Wait for reports to come in.
What to look for: every legitimate sender (your ESP, your Workspace, your transactional provider, your support platform, your sales tool) should appear in reports with spf=pass and/or dkim=pass and aligned=true. Any source failing alignment needs configuration fixes (SPF inclusion, DKIM selector setup, custom Return-Path).
Exit criteria: 2 to 4 weeks of clean reports showing all legitimate sources passing. Unknown sources (phishing) appear failing, which is the correct behavior; you don’t need to fix those, you need to block them, which is what the next phase does.
Phase 2: p=quarantine
Goal: start filtering failing mail to spam without risking permanent loss.
Setup: change the DMARC record to p=quarantine. Optionally start with pct=25 or pct=50 and increase over weeks if you want extra caution. Most senders go straight to pct=100 after a clean Phase 1.
What to look for: aggregate reports continue to show your legitimate sources passing. Disposition column in reports shifts to “quarantine” for failing mail. User support tickets about “I can’t find an email” stay flat (recipients can recover quarantined mail from spam).
Exit criteria: 4 to 8 weeks of clean reports with no legitimate sources being quarantined. Any internal support cases about quarantined mail traced back to a misconfigured source and fixed.
Phase 3: p=reject
Goal: refuse impersonating mail entirely.
Setup: change the DMARC record to p=reject. Use pct=25, pct=50, pct=75 over a few weeks if you want a gradual ramp. Most senders who completed Phase 2 cleanly go straight to pct=100.
What to look for: reports continue clean. Any new dkim=fail or spf=fail for legitimate sources is now a real outage; failing mail is being rejected at SMTP, not just routed to spam. Have a rollback plan: if reports show legitimate breakage, revert to p=quarantine within hours, not days.
How long to stay at each stage
| Stage | Minimum time | Typical time | Maximum value |
|---|---|---|---|
p=none | 2 weeks | 4 weeks | 3 months (beyond is “stuck”; signals weak commitment) |
p=quarantine pct=25-50 | 2 weeks | 2-4 weeks | 1 month |
p=quarantine pct=100 | 4 weeks | 4-8 weeks | 6 months (beyond is also “stuck”) |
p=reject pct=25-75 | 1-2 weeks | 2-4 weeks | 1 month |
p=reject pct=100 | indefinite | indefinite | your steady state |
The full roll-out from p=none to p=reject pct=100 typically takes 12 to 20 weeks for a domain with multiple sending sources. Senders with a single sender (just Workspace and one ESP) can move faster, 6 to 10 weeks.
Reading aggregate reports to decide
DMARC aggregate reports are XML files sent daily by major receivers (Gmail, Yahoo, Microsoft, AOL, others) to the address in your rua= tag. Raw XML is unreadable; you’ll use an aggregator (Postmark DMARC, dmarcian, EasyDMARC, OnDMARC, or GlockApps’s DMARC analyzer) to parse and visualize.
Three numbers per source matter:
- Volume. How many messages did this source send claiming to be from your domain?
- Alignment pass rate. What percentage of those messages passed DMARC (SPF or DKIM aligned with the From header)?
- Source identity. Is this source one of yours (recognized ESP, Workspace, internal IP range) or unknown (probable phishing or forgotten SaaS)?
Decision rules:
- All known sources at 100 % alignment → ready to move forward.
- A known source below 100 % alignment → fix that source’s configuration before moving.
- Unknown sources at any failure rate → investigate. Could be a forgotten internal tool, a phishing campaign (failure is the desired outcome here), or a new SaaS a team subscribed to without telling you.
- New sources appearing recently → audit before moving forward.
Common breakage when moving to reject
- A forgotten internal tool sending unauthenticated mail. Marketing’s analytics platform, finance’s invoicing system, HR’s onboarding service. None of them is in SPF or signed by DKIM. They pass at
p=none, get quarantined atp=quarantine(recoverable), and get rejected atp=reject(gone). Audit aggregate reports thoroughly before moving. - A subsidiary or sister domain sending from your domain. Common for companies with multiple brands. Each brand needs its own authentication setup.
- Bulk mail from a personal account. Sales team using their @example.com personal Workspace mailbox to send 200-recipient cold outreach via a tool that doesn’t sign with your domain. The tool’s mail goes from a different envelope but uses example.com in From. Quarantine catches it. Reject ends it.
- Mailing list traffic without ARC. Mailing lists modify messages in ways that break DKIM. Without ARC, the modified messages fail DMARC at the final receiver. Reject means the list traffic gets rejected.
- Forwarded mail without ARC. Same principle. A recipient who forwards your mail to another account triggers the same problem.
- Subdomain mail without a subdomain policy. The DMARC tag
sp=applies to subdomains. If you havep=rejectbut nosp=, subdomains inherit reject. Mail fromupdates.example.comthat wasn’t authenticated gets rejected.
10 common DMARC roll-out mistakes
- Publishing
p=rejectimmediately. Almost always breaks legitimate mail. Start atp=none. - Skipping the report aggregator. Reading raw XML is unsustainable. Use a paid or free DMARC analyzer.
- Setting
rua=without monitoring the address. Reports pile up unread. The data is the whole point ofp=none; if you don’t read it, you can’t move forward. - Confusing SPF alignment with DKIM alignment. DMARC only requires ONE to align (relaxed mode default). Both don’t need to pass, just both don’t need to fail.
- Moving forward with unknown sources still failing. “I don’t know who that source is, let’s reject anyway” sounds bold; in practice it’s how you blackhole the marketing department’s surprise tool.
- No rollback plan. Have the DNS provider login ready and a teammate cross-trained. Reverting
p=rejecttop=quarantinetakes a TTL window to propagate; you don’t want to be hunting for credentials at 11pm. - Forgetting the subdomain policy. Set
sp=quarantineorsp=rejectexplicitly when you setp=reject, or subdomains inherit the wrong behavior. - Moving to reject before BIMI is ready. If BIMI matters to you, sequence: clean reports →
p=quarantine→p=reject→ BIMI setup. Don’t try to do BIMI in parallel with reject; the DMARC discipline needs to be settled first. - Setting
aspf=soradkim=stoo early. Strict alignment (instead of the default relaxed) requires the From subdomain to exactly match the authenticated subdomain. Most senders need relaxed for legitimate mail to pass. Default is fine for almost everyone. - Treating
p=noneas compliant with bulk sender rules. Technically yes, philosophically no.p=nonemeans DMARC exists but does nothing. Gmail and Yahoo accept this for compliance, but the standard’s protection comes from quarantine and reject.
DMARC policy roadmap FAQ
Should I jump straight to p=reject?
Only if you have absolute confidence that every legitimate source is authenticated and aligned. For most domains, “absolute confidence” doesn’t exist until you’ve watched aggregate reports for several weeks. Start at p=none, walk through quarantine, then reject. The total time investment is weeks, not months, and the safety margin is worth it.
How is p=quarantine different from p=reject from the recipient’s view?
Quarantine routes the message to the spam folder; the recipient can recover it if they go look. Reject refuses the message at SMTP; the recipient never receives it, and the sender gets a bounce. Quarantine is recoverable; reject is not. That distinction matters when legitimate mail unexpectedly fails authentication.
What does pct=N actually do?
It tells receivers to apply the policy to only N percent of failing messages. p=quarantine; pct=25 means 25 % of failing messages get quarantined; the other 75 % are delivered (treated as if the policy were none). Useful for gradual roll-out, especially when moving from quarantine to reject. Default is pct=100 if you don’t specify it.
Can I have different DMARC policies for the main domain and subdomains?
Yes. The p= tag applies to the main domain; the sp= tag applies to subdomains. Common pattern: p=reject; sp=reject for strictness across the board, or p=reject; sp=quarantine if you have many subdomains with mixed authentication maturity. Always set sp= explicitly; otherwise subdomains inherit the p= value, which may not be what you want.
What happens to mailing list traffic when I move to p=reject?
Without ARC support at the list and at the receiver, mailing list traffic that fails DMARC will be rejected. List subscribers stop receiving your messages distributed through the list. Modern lists (Mailman 3.3+, Discourse, Google Groups) sign ARC, which receivers like Gmail, Microsoft and Yahoo can trust to override DMARC failure. See our ARC guide for the mechanism. If your audience uses older list software, plan for some breakage when moving to reject.
How quickly can I roll back if p=reject breaks something?
As fast as you can update DNS and wait for TTL. If your DMARC record has a 3600-second TTL, receivers cache the policy for up to an hour after you change it. Set the TTL lower (300 to 900 seconds) the day before any policy change so rollbacks propagate quickly. Once the new policy reaches receivers, rejected mail is rejected; rolled-back mail starts delivering again at the next receiver query.
Final words
The DMARC roadmap from none to reject is the project most senders underestimate. The first record is easy; the discipline of reading reports, fixing sources, and incrementally tightening is the actual work. Done well, the whole sequence takes about 3 to 5 months for a mid-size B2B sender and ends with a domain that can’t be impersonated for phishing.
The honest test of DMARC maturity is whether you can move to reject without anyone in the company noticing. If yes, the project is done; if not, your aggregate reports are telling you where to look.
For broader context, see our guides on DMARC setup, SPF, DKIM, BIMI, ARC, and the Deliverability hub.
Clean your list before you send.
SMTPing catches what regex misses: disposable addresses, role-based emails, catch-all domains, syntax errors, dead mailboxes and known traps. 13 validation types, 25 free checks daily, no card required.
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
