DMARC: Safely Migrating from p=none to p=reject

You’ve published your DMARC record with p=none. That’s a good start, but p=none blocks nothing: fraudulent emails still get through. The end goal is p=reject, and this guide walks you through the migration without breaking your legitimate mail flows.

Why p=none Isn’t Enough

With p=none, you’re asking mailbox providers to do nothing when an email fails DMARC. You receive RUA reports, but:

• Emails spoofing your domain still reach inboxes
• Your domain can be used for phishing
• Google and Yahoo now require a published DMARC record, but the real benefits start at p=quarantine or p=reject

Recommended Timeline

This timeline is indicative. The key is to never skip a step without verifying that reports are clean.

Step 1: Inventory All Sources

During the first weeks on p=none, DMARC reports reveal every IP sending emails on behalf of your domain. Classify them:

Known Legitimate Sources

• Your own mail server (own IP)
• Your main ESP (Brevo, Mailchimp, SendGrid…)
• Google Workspace / Microsoft 365

Shadow IT (Legitimate but Unmanaged Sources)

• Marketing tools (HubSpot, Salesforce, Intercom…)
• Transactional services (Stripe, Zendesk, Freshdesk…)
• Internal tools with email sending

Non-Legitimate Sources

• Unknown IPs with DKIM and SPF both failing → spoofing

The Sender Audit dashboard automatically classifies sources by status for easy sorting.

Step 2: Fix Legitimate Sources

For each legitimate source that fails:

Missing SPF

Add the corresponding include: mechanism to your SPF record:

v=spf1 include:_spf.google.com include:spf.brevo.com include:sendgrid.net -all

Missing DKIM

Enable custom DKIM at each ESP/service. Typically: add a CNAME or TXT record in your DNS, then activate in the service’s interface.

Verify with the DKIM Checker.

Broken Alignment

SPF or DKIM pass, but the domain doesn’t align with the From:. This is common with services that use their own domain as Return-Path. Solution: configure a custom bounce domain, or rely on DKIM (which aligns via the d= tag).

Step 3: Handle Shadow IT

This is often the longest step. Shadow IT refers to services that teams use to send emails from your domain without IT knowing.

How to find them: DMARC reports show unknown IPs with spf=pass (they’re in your SPF) but dkim=fail.

What to do:

1. Identify the service via rDNS or whois of the IP
2. Contact the relevant team
3. Configure DKIM for that service, or
4. Remove the SPF authorization if the service shouldn’t be sending with your domain

Step 4: Escalate Gradually

The pct= Tag

The pct= (percentage) tag applies the policy to only a fraction of traffic:

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

Here, 10% of emails failing DMARC will be sent to spam. The remaining 90% are treated as p=none. This is your safety net.

Use the DMARC Generator to easily adjust pct= and p= tags.

From Quarantine to Reject

quarantine sends failed emails to spam. reject blocks them entirely. The transition between the two is less risky because you’ve already validated that your legitimate flows pass DMARC.

Step 5: Protect Subdomains

Don’t forget the sp= tag (subdomain policy). Without it, subdomains inherit the parent domain’s policy. But an attacker can use billing.yourdomain.com for phishing.

v=DMARC1; p=reject; sp=reject; rua=mailto:your-rua@example.com

5 Pitfalls to Avoid

1. Jumping straight to p=reject without a monitoring period: you risk blocking your own emails
2. Not monitoring reports at each step: a new SaaS service added by a team can break things
3. Forgetting subdomains: sp=none by default leaves the door open
4. SPF with ~all instead of -all: in quarantine/reject mode, SPF softfail weakens protection
5. Ignoring transactional services: order confirmations, invoices, notifications often use your domain

Migration Checklist

• DMARC record published with rua=
• Reports collected for at least 2 weeks
• All legitimate sources identified
• SPF fixed (all sources included, -all)
• DKIM enabled on all ESPs/services
• Shadow IT addressed
• p=quarantine tested with progressive pct=
• p=reject tested with progressive pct=
• sp=reject added
• Ongoing monitoring in place

Further Reading

• Configure DMARC, the complete guide
• Understanding DMARC Reports
• Configure SPF
• Configure DKIM
• DMARC Checker, verify your record
• DMARC Generator, create or adjust your record
• Sender Audit Dashboard