DMARC Enforcement Guide
Moving from p=none to p=reject is the goal of every DMARC deployment. But getting there safely — without blocking legitimate email — requires a methodical approach. This guide walks through the three stages of DMARC enforcement, what to look for at each stage, and how to know when you're ready to move forward.
The three stages
DMARC enforcement is a journey through three policy levels:
| Stage | Policy | What happens to unauthorized mail |
|---|---|---|
| 1. Monitor | p=none | Nothing — mail is delivered normally, but reports are generated |
| 2. Quarantine | p=quarantine | Unauthorized mail is sent to the recipient's junk/spam folder |
| 3. Reject | p=reject | Unauthorized mail is rejected outright — it never reaches the recipient |
Each stage builds confidence. You never skip stages, and you never rush through them.
Stage 1: Monitor (p=none)
What you're doing
Publishing a DMARC record with p=none and a rua= address to collect aggregate reports. No email is blocked or quarantined. The only purpose of this stage is to discover every source of email that uses your domain, and to verify that each one passes SPF and/or DKIM.
The DMARC record
v=DMARC1; p=none; rua=mailto:[email protected]What to look for in reports
DMARC aggregate reports are XML files sent by receiving mail servers (Google, Microsoft, Yahoo, and others). Each report contains:
- The source IP address of the sending server
- Whether SPF passed or failed, and which domain was checked
- Whether DKIM passed or failed, and which domain signed the message
- Whether DMARC passed or failed (based on SPF/DKIM alignment)
- The volume of messages from each source
During the monitoring stage, you need to classify every source into one of these categories:
- Known and passing — your mail servers, your SaaS tools, all passing SPF/DKIM. No action needed.
- Known but failing — legitimate senders that aren't configured correctly. Fix their SPF include or DKIM signing before moving forward.
- Unknown but legitimate — services you didn't know were sending as your domain. Identify them, add their SPF include or configure DKIM, and verify they pass.
- Unauthorized — spoofing, phishing, or misconfigured third-party systems. These are what DMARC enforcement will block.
How long to stay at p=none
Minimum: 2-4 weeks. This gives you at least two full weekly reporting cycles from major providers. However, you may need longer if:
- You discover unknown senders that need investigation
- Your organisation has seasonal email patterns (monthly invoices, quarterly newsletters)
- You're onboarding a new SaaS tool that sends email
- You have many domains and need to work through them methodically
What "clean" looks like
You're ready to move to Stage 2 when:
- All legitimate senders are identified — you have a complete inventory of every service, server, and platform that sends email as your domain
- All legitimate senders pass DMARC — either through SPF alignment, DKIM alignment, or both
- Pass rate is above 95% — a small number of failures from forwarded mail or mailing lists is normal and expected
- No unknown high-volume senders remain — every source with significant volume has been classified
Don't rush this stage
The monitoring stage is where you do the hard work. Skipping ahead without a complete sender inventory is the most common cause of legitimate mail being blocked after enforcement.
Stage 2: Quarantine (p=quarantine)
What you're doing
Telling receiving mail servers to send unauthorized messages to junk/spam instead of the inbox. Legitimate mail that's properly authenticated continues to arrive normally. This is your first real enforcement action.
Using pct= for gradual rollout
The pct= tag lets you apply the policy to only a percentage of failing messages. This is your safety net. Start low and increase gradually:
Week 1 — 10%:
v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected]Only 10% of messages that fail DMARC are sent to junk. The other 90% are treated as if the policy were still p=none. This lets you catch problems early without affecting most mail.
Week 2 — 25%:
v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]Week 3 — 50%:
v=DMARC1; p=quarantine; pct=50; rua=mailto:[email protected]Week 4 — 100%:
v=DMARC1; p=quarantine; pct=100; rua=mailto:[email protected]You can omit pct=100
When pct= is absent, the default is 100%. So p=quarantine without a pct= tag is the same as p=quarantine; pct=100.
Monitoring for false positives
During the quarantine stage, actively watch for:
- User complaints about expected emails going to junk. Ask your help desk to flag any "I can't find an email" tickets.
- DMARC report changes — look for legitimate sources that suddenly show DKIM or SPF failures. Providers occasionally change their sending infrastructure.
- New SaaS tools — if another team starts using a new email-sending service during this period, it will fail DMARC and go to junk. Keep your sender inventory up to date.
How long to stay at quarantine
Stay at p=quarantine; pct=100 for at least 2-4 weeks with no issues before moving to reject. If you see false positives at any point, stop, fix the issue, and restart the clock.
What to do if something breaks
If legitimate mail is being quarantined:
- Don't panic. Quarantined mail is in the junk folder, not lost. Recipients can retrieve it.
- Identify the sender. Check DMARC reports to find which source IP is failing.
- Fix the authentication. Add the missing SPF include or configure DKIM for the sender.
- Consider rolling back pct= temporarily while you fix the issue. Dropping from
pct=50topct=10buys you time without losing all enforcement.
Stage 3: Reject (p=reject)
What you're doing
Telling receiving mail servers to reject unauthorized messages entirely. They are not delivered to junk — they are bounced back or silently dropped. This is the strongest protection against domain spoofing.
Gradual rollout with pct=
Just as with quarantine, use pct= to roll out reject gradually:
Week 1:
v=DMARC1; p=reject; pct=10; rua=mailto:[email protected]Week 2:
v=DMARC1; p=reject; pct=25; rua=mailto:[email protected]Week 3:
v=DMARC1; p=reject; pct=50; rua=mailto:[email protected]Week 4:
v=DMARC1; p=reject; rua=mailto:[email protected]What happens at p=reject
When a message fails DMARC evaluation and the policy is p=reject:
- The receiving server rejects the message during the SMTP transaction (550 response) or silently drops it
- The sender receives a bounce (NDR) if rejection happens during the SMTP transaction
- The recipient never sees the message — not in inbox, not in junk, nowhere
- Your DMARC reports continue to show the failed attempts, so you can monitor ongoing spoofing
Once you're at p=reject
Congratulations — your domain is fully enforced. But you're not done:
- Continue monitoring DMARC reports. New spoofing campaigns targeting your domain will appear in reports. This data is valuable for security awareness.
- Keep your sender inventory updated. When your organisation adopts a new email-sending service, add its SPF include or DKIM configuration before the service starts sending.
- Review quarterly. SPF records drift over time as providers change IPs and services are added or removed.
Signs you're NOT ready to move forward
Do not advance to the next stage if any of these are true:
Unknown senders with high volume
If your DMARC reports show a source IP sending hundreds or thousands of messages that fail DMARC, and you haven't identified what it is, stop. Investigate first. It could be:
- A forgotten SaaS tool
- A regional office's local mail relay
- An IT vendor sending on your behalf
- A printer or IoT device relaying through an on-premises server
Known senders failing SPF or DKIM
If you've identified a sender as legitimate but it's still failing DMARC, fix the authentication before enforcing. Common causes:
- SPF include not yet added to your DNS record
- DKIM not configured in the sending platform
- DKIM key rotation broke the signature
- The service sends with a misaligned envelope sender
Recently added a new SaaS tool
If your organisation just started using a new email-sending platform in the last 2 weeks, wait for a full reporting cycle to confirm it passes DMARC before increasing enforcement.
You're near the SPF lookup limit
If you're at 9 or 10 SPF lookups and need to add another service, fix your SPF record first (flatten or remove unused includes). Exceeding the lookup limit causes SPF to fail for all mail, which would trigger DMARC failures across the board.
Timeline expectations
For a well-managed domain with a clean sender inventory, the typical timeline is:
| Stage | Duration | Running total |
|---|---|---|
| p=none (monitoring) | 2-4 weeks | 2-4 weeks |
| p=quarantine (gradual rollout) | 2-4 weeks | 4-8 weeks |
| p=reject (gradual rollout) | 2-4 weeks | 6-12 weeks |
For domains with many unknown senders or complex email infrastructure, the monitoring stage can take much longer — sometimes 2-3 months. That's fine. The goal is getting it right, not getting it fast.
Start with your simplest domain
If you manage multiple domains, start enforcement on your simplest one — perhaps a parked domain that doesn't send email, or a domain with only Microsoft 365. This builds confidence and establishes the process before tackling more complex domains.
What about subdomains?
DMARC has a separate tag for subdomain policy: sp=. If you don't set it, subdomains inherit the parent domain's policy.
v=DMARC1; p=reject; sp=reject; rua=mailto:[email protected]This is important because attackers often target subdomains (e.g., hr.yourdomain.com or billing.yourdomain.com) that may not have their own SPF or DKIM records. Setting sp=reject on the parent domain blocks this.
If you have subdomains that legitimately send email, ensure they have their own SPF and DKIM configuration before setting sp=reject.
Quick reference: enforcement checklist
Before moving from none to quarantine:
- [ ] All legitimate senders identified and classified
- [ ] All legitimate senders passing DMARC (SPF or DKIM aligned)
- [ ] DMARC pass rate above 95%
- [ ] At least 2 weeks of clean monitoring data
- [ ] SPF record under the 10-lookup limit
Before moving from quarantine to reject:
- [ ] At least 2 weeks at p=quarantine pct=100 with no false positives
- [ ] No new email-sending services onboarded during the quarantine period
- [ ] Help desk has not reported legitimate mail in junk folders
- [ ] DMARC reports show consistent pass rates
Before declaring enforcement complete:
- [ ] At p=reject with no pct= tag (or pct=100) for at least 2 weeks
- [ ] sp= policy set for subdomains
- [ ] Monitoring process established for ongoing report review
- [ ] Sender inventory documented and shared with IT team