Moving from DMARC p=none to p=reject without killing legitimate email

You set up DMARC six months ago. The record says p=none. You’re getting reports. Life is fine.

Except it isn’t. p=none means receivers are doing absolutely nothing when someone sends a spoofed email from your domain. Phishing attacks, business email compromise, supply-chain scams — all of them can use your domain with zero resistance.

This guide walks you through moving to enforcement without the dreaded “we stopped getting customer emails” phone call.

Why p=none is a starting point, not a destination

When you set p=none, you told every mail server in the world: “If someone sends email pretending to be me and fails authentication, please log it and tell me, but deliver it anyway.”

That’s useful for discovery. It’s dangerous to stay there.

The goal is p=reject: senders who can’t pass DKIM or SPF alignment get their messages dropped entirely. Your domain becomes nearly worthless for phishing.

The risk of rushing straight to p=reject is that you’ll reject your own legitimate email — the newsletter platform you forgot to authorize, the legacy CRM your marketing team uses, the automated invoice system that IT set up three years ago.

The solution is a methodical transition, not a leap.

Step 1 — Read your reports before you touch anything

Spend a week actually reading your DMARC aggregate reports. You want to answer one question: are any legitimate senders currently failing?

Look for patterns in the failure data:

• High volume from a single IP — probably a sending service you haven’t authorized
• Consistent SPF pass, DKIM fail — the sender authenticates via SPF but hasn’t set up DKIM signing
• Low volume scattered failures — likely forwarding artifacts or old bounce handlers, usually safe to ignore

If you see a domain you recognize (sendgrid.net, amazonses.com, mailgun.org) in the failure list, that service needs to be added to your SPF record and configured to sign with DKIM before you move to enforcement.

If you see IPs you don’t recognize sending your domain, that’s exactly what DMARC enforcement is designed to stop.

Step 2 — Fix authentication for every legitimate sender

For each legitimate service that’s failing, do two things:

Add them to SPF. Your SPF record lives at your root domain as a TXT record. Add the service’s include:

v=spf1 include:_spf.google.com include:sendgrid.net include:amazonses.com ~all

One trap: SPF has a limit of 10 DNS lookups. If you have many services, check your lookup count before adding more includes. DMARC Guardian’s DNS tab shows your current count. If you’re near the limit, consider a hosted SPF service that flattens the includes into a single list of IPs.

Configure DKIM for each service. Every major email platform (SendGrid, Amazon SES, Mailchimp, Postmark) has a guide for generating a DKIM key pair and publishing the public key in DNS. Log into each platform and follow their DKIM setup docs. It typically involves adding a CNAME or TXT record at something like s1._domainkey.yourdomain.com.

After each change, wait 24 hours and check your DMARC reports again. The failing sender should start showing passes.

Step 3 — Move to p=quarantine first

Don’t jump straight to p=reject. Move to p=quarantine first:

v=DMARC1; p=quarantine; rua=mailto:your-rua-address; pct=10

The pct=10 parameter tells receivers to apply the quarantine policy to only 10% of failing messages. This lets you catch problems at limited blast radius.

Before moving to quarantine, verify these thresholds:

• SPF + DKIM pass rate is above 99% for legitimate senders
• No legitimate sender appears in the failure list
• Your DMARC reports have been clean for at least 2 weeks

Monitor for two things:

1. Legitimate email landing in spam — check your own spam folder and ask colleagues to do the same for a week
2. Report failures jumping suddenly — a spike means something changed, investigate before proceeding

After a week with no collateral damage, bump pct up: 25, then 50, then 100. Each increment is one to two weeks of monitoring. Rushing this phase is how teams break legitimate email.

Step 4 — Promote to p=reject

Once you’ve run p=quarantine; pct=100 cleanly for two weeks, you’re ready:

v=DMARC1; p=reject; rua=mailto:your-rua-address

At this point, unauthorized senders using your domain get their messages dropped by receiving servers before they reach anyone’s inbox. Your domain is protected.

What to monitor after enforcement

Enforcement isn’t set-and-forget. Three things to watch:

New sending services. Every time the business adds a new tool that sends email (a helpdesk, a CRM, an automated invoice system), it needs to be authorized before it goes live. Make “add to SPF and configure DKIM” part of your SaaS onboarding checklist.

SPF record changes by third-party providers. Providers occasionally change their sending infrastructure and update their SPF includes. If a provider changes their include: mechanism, your SPF may need updating. DMARC reports will show you the failure before your users notice.

Forwarding artifacts. Email forwarding breaks SPF by design — the forwarded message arrives from the forwarder’s IP, not your authorized IP. If colleagues use external forwarders, they’ll see failures in your reports. These are usually low-volume and mostly harmless under p=reject (the forwarded message might land in spam at the destination), but they’re worth understanding.

The failure mode most teams hit

The most common reason teams stay stuck at p=none for years is not technical — it’s organizational. Someone set up DMARC on a Tuesday, got busy, and nobody owns the “move to enforcement” decision.

Fix this by assigning a specific deadline. “We will reach p=reject by [date].” Put it in a ticket. Work through the fixing and monitoring phases with that date in mind.

DMARC Guardian’s timeline charts make the monitoring phases faster because you don’t have to manually parse XML attachments. But the decision to enforce is yours.

A realistic timeline

Total: roughly 11–19 weeks from committed start to full enforcement. This is not fast, but it’s safe. Rushing is how you break legitimate email.

If you’ve already been in p=none for months, your discovery phase is done — you can skip straight to fixing senders.

Rollback plan: Keep a copy of your previous DNS records. If legitimate email starts failing, you can revert to p=none within minutes. This is not a failure; it’s the reason you staged the rollout.

One last check before p=reject

Before you flip the switch, confirm these four things are true:

1. All legitimate sending services have SPF includes and DKIM configured
2. Your SPF record stays under 10 DNS lookups
3. You have an RUA address actively receiving reports
4. SPF + DKIM pass rate is consistently above 99.5% for legitimate traffic
5. Someone on your team will check reports at least weekly

If all five are true, enforce. Your domain will be meaningfully harder to spoof the moment the DNS change propagates.