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

DMARC p=none means monitor only — emails that fail authentication are still delivered to recipients. It provides visibility into who's sending as your domain, but zero protection against spoofing.

Many organizations stay at p=none indefinitely because moving to enforcement is perceived as risky. The risk is real: if you enforce DMARC before all your legitimate sending sources pass authentication, you'll block your own legitimate email.

But the risk of staying at p=none is also real: attackers can impersonate your domain in phishing and BEC attacks with zero consequences. The path below is the safe approach used by security teams.

1. 1

   Publish p=none with RUA reporting address

   v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com — Collect aggregate reports before making any enforcement decisions.

2. 2

   Analyze reports for 2–4 weeks

   Identify every server sending email as your domain. Classify each as legitimate (known ESP, internal system) or unauthorized (spoofing).

3. 3

   Authorize all legitimate senders

   Add legitimate senders to your SPF record. Enable DKIM signing in each service. Verify alignment passes in subsequent reports.

4. 4

   Advance to p=quarantine pct=10

   Start enforcement at 10% of failing messages. Monitor reports closely for legitimate traffic that's failing authentication.

5. 5

   Increase pct gradually: 25 → 50 → 100

   Spend at least 1 week at each percentage. Fix any legitimate authentication failures found before increasing further.

6. 6

   Move to p=reject

   Once p=quarantine pct=100 shows zero false positives for 2+ weeks, advance to p=reject. Full spoofing protection achieved.

7. 7

   Maintain: rotate DKIM keys, monitor reports

   New services, infrastructure changes, and key rotation can break authentication. Review DMARC reports monthly and act on failures immediately.

Review your DMARC aggregate reports (rua) for all sources claiming your domain. For each IP or domain in the report:

1. Identify which service it represents (Google Workspace, SendGrid, Mailchimp, HubSpot, etc.) 2. Verify it's a legitimate authorized sender 3. Check whether it passes SPF alignment and DKIM alignment 4. For sources with DMARC failures: configure SPF (add to your SPF record) and/or DKIM (enable signing in the service)

Common surprises during audits: old marketing automation platforms, forgotten CRMs, server-generated emails from developer tools, support ticketing systems.

The pct= tag in your DMARC record specifies what percentage of failing emails the policy applies to. This lets you enforce gradually:

v=DMARC1; p=quarantine; pct=10; rua=mailto:reports@yourdomain.com

This applies quarantine to 10% of failing messages while monitoring the other 90%. Increase pct in stages: 10% → 25% → 50% → 100%.

At each stage, watch DMARC reports for legitimate traffic that's failing. Fix any issues before increasing pct.

Move to p=quarantine before p=reject. Quarantine sends failing emails to spam rather than rejecting them outright. This gives you a safety net — if you accidentally block legitimate email, it's in spam (recoverable) rather than rejected (gone).

Spend 2-4 weeks at p=quarantine, pct=100 while monitoring for false positives.

Only move to p=reject once you're confident all legitimate senders pass authentication and quarantine hasn't caught any legitimate email.

Email forwarding: Forwarded emails often break SPF alignment. This is expected and unavoidable — DKIM alignment should still pass if the forwarding server doesn't modify the message. Forwarding that strips DKIM signatures is a problem.

Marketing platforms with shared infrastructure: Some platforms send from their own domain and use your domain in the From: header only — these need DKIM set up with your domain.

Server-generated email: Developer tools, monitoring systems, cron job notifications — often sent from the server's localhost without authentication.

Mailing lists: List software that rewrites the From: header breaks DMARC. Use DMARC-compatible mailing list software or SRS (Sender Rewriting Scheme).