Email Deliverability
The Agency Guide to DMARC Enforcement: Moving from p=none to p=reject
A step-by-step guide for agencies helping clients move DMARC from p=none to p=reject without breaking email delivery. Includes what to check at each stage.
Most domains that have DMARC are stuck at p=none. It's been there for months, sometimes years. Nobody touched it because it was working or at least, nobody knew it wasn't.
p=none means your DMARC record exists but does nothing. It collects reports (if you've configured an rua address). It doesn't protect against spoofing. It doesn't affect deliverability. It just watches.
Moving to p=reject means your domain is fully protected unauthorized senders are rejected by receiving mail servers, and your brand can't be spoofed in email. It's the end goal. It's also where most organizations get stuck, because moving too fast breaks legitimate email.
This guide covers every step of the journey, what to check at each stage, and how agencies can manage this process for clients without breaking anything along the way.
Why p=none is not enough
When DMARC was first deployed across a domain, p=none was the sensible starting point. It let you start collecting data about who was sending from your domain without risking any legitimate email. The intent was always to monitor, fix, then enforce.
The problem is that most organizations deployed p=none, discovered it required more work than expected, and left it there.
p=none with a domain that's actively used for email means:
No spoofing protection. Anyone can send email that appears to come from your domain. Phishers, scammers, and competitors can impersonate your client's brand in email. The DMARC record exists but provides no enforcement.
Non-compliance with Google and Yahoo requirements. Since 2024, Google and Yahoo require bulk senders (5,000+ emails/day to Gmail) to have DMARC in place. They currently accept p=none, but the direction of travel is clear p=quarantine or p=reject is where requirements are heading.
Missed BIMI eligibility. BIMI the feature that displays a brand's logo next to email in Gmail and other clients requires DMARC at p=quarantine or p=reject. A client stuck at p=none can't use BIMI regardless of how well everything else is configured.
The pre-flight checklist before raising policy
Moving to p=quarantine or p=reject before your authentication stack is complete will break legitimate email. The goal is to make every legitimate sending source pass SPF or DKIM before enforcement kicks in.
Here's what needs to be confirmed before touching the DMARC policy.
1. Map every sending source
Start by identifying every system that sends email from the client's domain. This includes:
- Primary ESP (Mailchimp, Klaviyo, HubSpot, ActiveCampaign, etc.)
- Transactional email (SendGrid, Postmark, Resend, AWS SES, etc.)
- CRM email (Salesforce, HubSpot CRM, Pipedrive, etc.)
- Marketing automation
- Internal tools that send email (support platforms, helpdesks)
- Calendar invites and meeting tools
- Invoice and billing software
- Anything else that sends email with the client's domain in the From field
This step is where most agencies underestimate the work. There are almost always more sending sources than the client knows about. DMARC aggregate reports (from the rua address) are the most reliable way to find them they show every sending source that claimed to be the domain, passed or failed.
2. Confirm SPF covers all sending sources
Every sending source identified above needs to be listed in the SPF record. This means adding include: entries for each ESP's SPF record.
Check the SPF record covers all sources and stays within the 10 DNS lookup limit. Exceeding 10 lookups invalidates the SPF record, which will break authentication for all senders.
If you're close to the limit, use SPF flattening replacing include: entries with the resolved IP addresses to reduce lookup count.
3. Confirm DKIM is configured for all sending sources
Every sending source should have DKIM configured. This means:
- Publishing the DKIM public key provided by each ESP as a TXT record at
[selector]._domainkey.[domain] - Verifying the DKIM signature appears in sent email headers
- Confirming the key is at least 2048 bits
Some older ESPs or self-hosted mail servers may default to 1024-bit keys. Rotate these to 2048-bit before proceeding.
4. Confirm DMARC alignment
SPF and DKIM both need to pass, and they need to pass with alignment the domain in the From header must match the domain used for authentication. A sending source that passes SPF on a different domain doesn't satisfy DMARC alignment.
Pull a raw email from each sending source and check the Authentication-Results header. You want to see dmarc=pass with policy=none (or quarantine/reject once you raise the policy). If you're seeing dmarc=fail, identify whether SPF or DKIM (or both) are failing, and fix them before raising the policy.
5. Set pct=100 and confirm rua is working
Before raising the policy, confirm your DMARC pct is set to 100 (or raise it there) and that your rua address is receiving and being processed. You need the aggregate report data to confirm all sources are passing.
The staged rollout
Once the pre-flight checklist is complete, raise the policy in stages.
Stage 1: p=none, pct=100
You should already be here. Confirm pct=100 and that you're receiving and reviewing aggregate reports. This is your baseline.
Stage 2: p=quarantine, pct=5
The first enforcement step. p=quarantine tells receiving servers to send failing email to the spam folder rather than reject it. Starting at pct=5 means the policy applies to only 5% of email that fails authentication the rest is still treated as if policy is p=none.
This is a safety net. If something is misconfigured that you missed, only 5% of failing email is affected rather than 100%.
Monitor for 48–72 hours. Check aggregate reports. Look for legitimate email sources appearing in the fail category.
Stage 3: p=quarantine, pct=25 → pct=50 → pct=100
Gradually raise pct over 1–2 weeks while monitoring for legitimate sources appearing in the fail bucket. Each increase should be followed by 48–72 hours of monitoring.
At p=quarantine, pct=100, all email that fails DMARC goes to spam. If there are still legitimate senders in the fail bucket, they need to be fixed before proceeding to p=reject.
Stage 4: p=reject, pct=5 → pct=100
The final stage. p=reject tells receiving servers to reject (bounce) email that fails DMARC rather than spam-folder it. Raise pct gradually using the same 48–72 hour monitoring cadence.
At p=reject, pct=100, your domain is fully protected. Unauthorized senders are rejected. Legitimate email passes because you've confirmed all sources are authenticated.
What to watch during rollout
Aggregate report data Your rua address should be receiving DMARC reports from major mailbox providers. These reports list every sending source, whether they passed SPF and DKIM, and whether they're aligned. Any source appearing in the fail column that's sending legitimate email needs to be fixed before you raise pct.
Bounce rate A sudden spike in hard bounces after raising pct often means a legitimate sending source is failing authentication. Pull the bounce log, identify the sending source, and check its SPF and DKIM configuration.
Client alerts Tell the client what you're doing at each stage. If they start getting reports of bounced email or missing notifications, you need to hear about it immediately. The staged rollout is designed to limit blast radius, but you want to know about any failures.
Forwarded email Email that's been forwarded by a third party often fails DMARC because the forwarding server modifies the message. This is expected behavior and not something you need to fix it's a known limitation of DMARC. ARC (Authenticated Received Chain) is the longer-term solution, but most agencies don't need to implement it.
Adding subdomain protection
Once the root domain policy is at p=reject, pct=100, extend protection to subdomains by adding the sp= tag.
sp=reject tells receiving servers to apply the reject policy to all subdomains that don't have their own DMARC record. Without it, subdomains like mail.domain.com or newsletter.domain.com may not be protected even when the root domain is.
The updated DMARC record: v=DMARC1; p=reject; sp=reject; pct=100; rua=mailto:dmarc@domain.com
The full journey at a glance
| Stage | Policy | pct | Duration | |---|---|---|---| | Baseline | none | 100 | Until reports confirmed | | Initial enforcement | quarantine | 5 | 48–72 hours | | Gradual enforcement | quarantine | 25, 50, 100 | 1–2 weeks | | Full quarantine | quarantine | 100 | 1 week stable | | Initial reject | reject | 5 | 48–72 hours | | Full enforcement | reject | 100 | Ongoing |
This process takes 3–6 weeks when done carefully. Agencies that rush it jumping straight from p=none to p=reject, pct=100 regularly break legitimate email and end up emergency-rolling it back.
The staged approach is slower. It's also the one that doesn't generate a 2am client call about broken email.
Maintaining enforcement after rollout
Getting to p=reject, pct=100 is not the end. It's the beginning of ongoing maintenance.
Clients add new tools that send email. ESPs change their sending infrastructure. Developers add a new service that sends notifications from the company domain without telling anyone. Any of these can break authentication and cause legitimate email to start failing DMARC checks.
Continuous monitoring catches these changes as they happen rather than at the next quarterly audit. When a new sending source appears in the DMARC fail bucket, you know immediately not when the next campaign bounces.
That's the difference between a one-time project and a managed service. The project gets you to p=reject. The managed service keeps you there.