Move DMARC from p=none to p=reject Without Breaking

How to Move Your DMARC Policy from p=none to p=reject Without Breaking Email

The sequence is: stay at p=none until you have found every legitimate sender, move to p=quarantine until you have validated that alignment failures are expected, then move to p=reject. Skip the first two steps and you will have mail breakage. This guide covers each gate in order.

If you are running DMARC at p=none, you already have visibility into who is sending mail that appears to come from your domain. The problem is that p=none tells receiving servers to do nothing with mail that fails authentication checks. Switching to p=reject before you know what is failing means those messages get refused, which looks like bounced notifications, lost password resets, and silent failures that your users report before you do.

What p=none Actually Does (And Why It Is Not Protection)

p=none is a monitoring setting. It generates aggregate reports. It does not enforce anything. A message from an unaligned third-party sender arrives in the recipient's inbox exactly as it would without DMARC at all.

p=reject is the opposite. Receiving servers refuse any message that fails DMARC alignment, permanently. There is no soft landing, no spam folder, no retry.

The gap between those two states is where legitimate mail breaks. Almost every time, the cause is a vendor, subsidiary, or internal system sending on your behalf that does not have aligned SPF or DKIM set up.

The Discovery Principle: Know Every Sender Before You Enforce

Before you change your DMARC record, use your aggregate reports to build a complete list of everyone who sends mail from your domain. This is the single most important step in the entire process, and it is the one most commonly skipped.

An aggregate report covers a 24-hour window. For each sending IP, it shows the result of the SPF check, the DKIM check, and the DMARC alignment result. You are looking for three patterns:

Aligned and passing. Your known senders with correct SPF and DKIM setup. These should keep working. Confirm they are actually passing in your reports, not just assumed to be passing.

Aligned but failing. A system is sending mail that appears to come from your domain, but the SPF or DKIM result does not align with the From header. This is the critical case. This mail will be refused at p=reject. It must be fixed or isolated before you enforce.

Sending from your domain that you did not authorize. A vendor may be sending on your behalf without your knowledge. This is a deliverability problem and a security signal. You need to know about it.

During discovery, DMARCFlow makes this practical by aggregating reports across all your receivers, alerting you when new sending sources appear, and surfacing alignment failures as events rather than as data you have to parse manually. You want that alerting active before you change any policy setting.

How to Configure SPF for Third-Party Senders

SPF authorizes specific IP addresses to send mail for your domain. When a third-party platform sends from its own infrastructure, you add their IPs to your SPF record.

The error most practitioners make is adding vendors to SPF until the record exceeds the 10-DNS-lookup limit in RFC 7208. When that limit is hit, SPF checks return PermError and receivers may treat mail as unauthenticated by default.

To stay within limits:

Minimize include mechanisms in your SPF record
Prefer platforms that can DKIM-sign with your domain over adding their IPs to SPF
Consolidate vendors under shared sending infrastructure where you control both SPF and DKIM
For infrequent senders, a dedicated subdomain with its own SPF is cleaner than adding to the apex record

For platforms like Brevo, SendGrid, and Amazon SES that offer DKIM signing with your domain, the DKIM signature's d= tag shows your domain. That satisfies DMARC alignment on its own, even without SPF. You only need SPF include for the platform if you want that as a belt-and-suspenders backup.

How to Configure DKIM for Third-Party Senders

DKIM signs outgoing mail with a private key held by your sending platform. The receiving server uses a public key in your DNS to verify the signature.

For DMARC alignment, the domain in the DKIM d= tag must match your From header domain exactly, or be an explicitly authorized subdomain.

Third-party platforms offer two configurations:

The platform signs with your domain (preferred). You add their DKIM public key to your own DNS. The platform sends from your domain. The DKIM signature shows your domain, alignment passes, and DMARC is satisfied. Configure this whenever the platform supports it.

The platform signs with their own domain. The DKIM d= tag shows the platform's domain, not yours. Alignment fails. A common workaround is to use a subdomain for that vendor's mail (e.g., alerts@example.com) and set the subdomain's DMARC to p=none or p=quarantine while your apex domain is at p=reject. The subdomain gives that vendor its own isolated policy.

The Three-Stage Progression: p=none, p=quarantine, p=reject

Do not move directly from monitoring to rejection. p=quarantine is your validation gate.

Stage 1: p=none (Monitoring)

Run this long enough to capture your complete sending pattern. Minimum 2 weeks, ideally a full email cycle including monthly billing runs, quarterly statements, and low-frequency automated alerts. Every time you add a new vendor or change a sending platform, you generate new sending patterns. Stay at p=none until those patterns are stable.

Stage 2: p=quarantine

Move to p=quarantine and watch your aggregate reports. Failing aligned mail now goes to recipients' spam folders instead of being refused. You catch any senders you missed in your inventory, because quarantine reports show up in your data as a change in disposition rates.

Stay at p=quarantine until your alignment failure rate is stable and accounted for. A new spike in quarantine dispositions from a previously passing sender means something changed and needs investigation.

Stage 3: p=reject

Move here only when aggregate reports show zero unexpected alignment failures from legitimate senders. Not "very few." Zero unexpected failures.

The reason for the strict gate: p=reject produces hard bounces. A refused password reset or two-factor code is a visible user failure. You want to know about alignment problems from your reports, not from user complaints.

Vendor Compatibility: What Breaks and How to Fix It

Proofpoint, Mimecast, Cisco IronPort (security gateways): These platforms often rewrite the From header for DLP scanning, encryption, or archival purposes. When the From header is rewritten, the DKIM signature (if any) no longer aligns with what the receiver sees, and SPF likely fails because the envelope sender differs from the header From. The fix: configure the gateway to relay from a dedicated subdomain you control, or enable ARC (Authenticated Received Chain) so downstream receivers can reconstruct the original authentication results.

Brevo: DKIM-signs with your custom domain when configured correctly, and the sending IPs can be added to your SPF record. Most setups pass DMARC alignment cleanly. The critical check: verify that the domain shown in Brevo's sender settings exactly matches your From header domain, including any subdomain portion.

SendGrid: Supports DKIM signing with your verified domain via custom domain authentication. Their legacy Mail API historically rewrote From headers in some configurations. The current best practice is using the Mail Send API with custom domain authentication and verifying alignment with a test message before going live.

Amazon SES: Signs with your verified sending domain by default. Add SES sending IPs to your SPF record. SES can generate DMARC records for your verified domains directly through the console.

Salesforce, HubSpot, Marketo: CRMs and marketing platforms that typically send from their own infrastructure. Salesforce and HubSpot both support custom domain sending with DKIM signing. Marketo requires careful SPF configuration and dedicated IPs to avoid alignment issues in some legacy setups. Test all three with a p=none policy active before assuming they are working.

What to Do When a Vendor Cannot Support Aligned Authentication

Sometimes a vendor's infrastructure cannot be configured to pass DMARC alignment. Their product was not designed for it.

1. Use a dedicated subdomain for that vendor. Set the subdomain's DMARC to p=none or p=quarantine while your apex domain runs at p=reject. Mail from that vendor is quarantined or accepted at the subdomain level and does not affect your main domain policy.

2. Enable ARC. ARC (RFC 8617) lets intermediate handlers like security gateways add authenticated results to mail headers. If your vendor supports ARC and your receiving infrastructure processes it, downstream receivers can use the ARC chain to verify the original authentication even if the From header was rewritten. Not all receivers process ARC, so this is not a universal solution, but it handles many Proofpoint and Mimecast cases.

3. Accept quarantine for that sender. Keep the sending infrastructure at p=quarantine. Mail goes to spam rather than being refused. This is a user experience compromise, not a security ideal, but it is better than hard bounces.

4. Replace the vendor. Some workflows can move to a platform that supports aligned authentication. This is the most durable solution when the vendor is not flexible.

How to Monitor the Transition

During p=none and p=quarantine, you need a reliable flow of aggregate reports. DMARC report volumes are large, formats vary between receivers, and missing a day of reporting means missing visibility into sending patterns.

DMARCFlow handles report ingestion and produces a normalized view of your authentication results over time. During a policy transition, the value is the alerting: when a previously passing sender starts showing alignment failures, you find out from a report alert rather than from a user complaint about missing password resets.

Set a standing habit: after every change to your DMARC record, watch your reports for 48 hours before assuming the change was successful.

Frequently Asked Questions

How long should we stay at p=none before moving to p=quarantine?

A minimum of one full email cycle. Most organizations need 2 to 4 weeks minimum. You want to see monthly billing runs, quarterly statements, and low-frequency automated alerts. If your aggregate reports still show new sending sources appearing between weeks, you are not ready.

What percentage of legitimate mail should be aligned before we move to p=reject?

100% of your known legitimate senders. If one sender represents 2% of your volume and is unaligned, 2% of your transactional mail starts bouncing at p=reject. For password resets, shipping notifications, and security alerts, a 2% loss rate is not acceptable. Make the decision based on which senders are failing, not on a percentage threshold.

One vendor cannot add our DKIM key or change their From header. What do we do?

Use a dedicated subdomain for that vendor's mail. Set the subdomain's DMARC to p=none or p=quarantine. Your apex domain proceeds to p=reject. This is the standard workaround for vendors with inflexible infrastructure.

Does p=quarantine risk our legitimate mail going to spam?

Yes. Transactional mail that lands in spam folders creates a poor user experience. Use p=quarantine as a transition phase, not a destination. Move to p=reject as soon as your alignment failures are resolved or isolated.

We enabled p=reject and now one sender is completely blocked. What went wrong?

Check your aggregate reports for that sender. The three most common causes: the sender started using a new IP not in your SPF record, the platform updated their DKIM signing to use a different domain after a configuration change, or a vendor changed their sending infrastructure without telling you. In every case, the fix is in your DNS records or the vendor's configuration, not in your DMARC policy.