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

Why p=none Is Only the Starting Point

Most domains start with DMARC at p=none because the standard requires you to. You add a TXT record at _dmarc.example.com with p=none, wait for aggregate reports to arrive, and then figure out what to do next. That waiting period is where most organizations get stuck.

The goal of p=none is not to protect your domain. It is to give you data. Once you have that data, you move toward enforcement.

The transition from p=none to p=reject is the point where most email administrators get nervous. You have been watching reports for weeks or months. You know your domain sends legitimate email through your primary mail server. But you also know there are third-party senders, marketing platforms, and legacy systems that may not be properly aligned. Moving to p=reject without preparation will break some of those.

This guide walks through the full migration path: what to check at each phase, how long to stay there, and what to watch for when you finally move to enforcement.

The Three-Phase DMARC Migration Path

The standard migration approach uses three phases. Each phase has a specific purpose and a minimum recommended duration.

Phase 1: p=none (monitoring)

This is where most domains start. Your DMARC record looks like this:

v=DMARC1; p=none; rua=mailto:reports@example.com;

At p=none, receiving mail servers do not take action based on your DMARC policy. They accept all email and simply send you aggregate reports. You receive XML files describing what authentication results they observed for email claiming to be from your domain.

The purpose of this phase is to build a complete picture of every legitimate sender for your domain. That includes your primary mail server, any third-party marketing platforms, cloud services that send on your behalf, and any legacy systems that may have been configured years ago and forgotten.

Do not rush this phase.

Phase 2: p=quarantine (test enforcement)

After you have identified all legitimate senders and ensured they are properly aligned, you move to p=quarantine:

v=DMARC1; p=quarantine; rua=mailto:reports@example.com;

At p=quarantine, receiving servers treat failing email as suspicious. Most will route it to spam or quarantine rather than rejecting it outright. This is a buffer: if something is misconfigured, legitimate email lands in spam instead of disappearing.

This phase tests whether your alignment is complete. If you missed a legitimate sender, its email lands in quarantine instead of being silently rejected.

Phase 3: p=reject (full enforcement)

Once you have passed through p=quarantine without incident, you move to p=reject:

v=DMARC1; p=reject; rua=mailto:reports@example.com;

At p=reject, receiving servers reject email that fails DMARC alignment. No quarantine, no spam folder. The email is refused at the SMTP level.

This is the level of protection that actually stops spoofing. A p=reject policy means an attacker cannot successfully send email that appears to come from your domain, assuming the attacker is outside your authorized sending infrastructure.

How Long to Stay at Each Phase

Minimum recommended durations:

• p=none: 30 to 60 days, depending on email volume. If your domain sends 10,000 emails per day, 30 days gives you a statistically meaningful data set. If you send 100 emails per week, you may need 90 days or more to capture enough report data.
• p=quarantine: 14 to 30 days. This is long enough to observe any periodic sending patterns (monthly newsletters, quarterly batch jobs) that you may have missed.
• p=reject: permanent, once you are confident.

Volume matters. A domain sending transactional email continuously will surface all its legitimate senders quickly. A domain that sends a monthly newsletter through a third-party vendor needs to observe at least one full cycle before moving to enforcement.

The key question before each transition is: do your aggregate reports show any authentication failures that you cannot explain? If yes, stay at the current phase until you have resolved or accounted for those failures.

Auditing Your Authorized Senders Before Moving to p=quarantine

Before you move from p=none to p=quarantine, review your aggregate reports and answer these questions:

Which IP addresses are sending email from your domain?

Your DMARC reports will show you the source IP addresses that receivers observed sending email claiming to be from your domain. Cross-reference these against your known infrastructure: your primary mail server, your marketing email platform, any SaaS tools that send transactional email, and any cloud services you use.

Any IP address you cannot identify is a gap. It could be a legitimate sender you forgot about, or it could be an attacker spoofing your domain. At p=none you cannot tell the difference.

Which sending domains are DKIM-aligned?

DMARC alignment means the domain in the From: header matches either the SPF domain or the DKIM domain. A third-party email sender that uses its own DKIM domain (such as a platform signing with their own domain rather than yours) will fail alignment unless you have configured custom DKIM signing with that vendor.

Your aggregate reports show DKIM results. Look for DKIM failures on email that you believe is legitimate.

Do any third-party senders DKIM-align with your domain?

If a vendor sends email "from" your domain but uses their own DKIM key, that email will fail DMARC alignment. The fix is usually to configure the vendor to use custom DKIM signing with your domain, if the vendor supports it. Some vendors do not.

If a vendor cannot DKIM-align with your domain, you have three options:
1. Use subdomain segmentation to exclude that vendor's subdomain from your main DMARC policy
2. Accept that the vendor's email will be rejected at p=reject and find an alternative vendor
3. Keep that domain at p=none or p=quarantine while migrating the rest of your infrastructure

What to Do About Senders That Cannot Be Aligned

This is the most common reason organizations stall at p=none. They discover a critical business partner or vendor that sends email from their own infrastructure and cannot configure DKIM signing with the customer's domain.

The first approach is subdomain segmentation. If your main domain is example.com and a legacy CRM sends email from crm.example.com, you can set a relaxed DMARC policy for the subdomain while keeping p=reject on the root domain:

v=DMARC1; p=reject; rua=mailto:reports@example.com; sp=quarantine;

This tells receivers to enforce DMARC strictly on example.com but treat failures on crm.example.com as quarantine instead of reject. You still get protection on your primary domain while giving legacy infrastructure room to operate.

The second approach is to exclude specific subdomains from your main policy using the "sp" tag. If you need a subdomain to remain at p=none because it has a vendor you cannot control:

v=DMARC1; p=reject; rua=mailto:reports@example.com; sp=none;

Note that sp=none means the subdomain has no policy and receivers will take no action. Use this only when you have a specific reason and you accept the risk.

The third approach is to find a vendor that supports proper alignment. Many modern email sending platforms (Postmark, Mailgun, SendGrid with custom DKIM, etc.) support DKIM signing with your domain. If a vendor cannot or will not support this, it is worth evaluating alternatives, particularly for high-volume transactional email.

Rolling Back if Email Breaks After Moving to p=reject

Email will break after you move to p=reject. Not might break, will break. Usually because you missed a legitimate sender during the audit phase. Sometimes because a vendor changed their sending infrastructure without telling you. Occasionally because a receiving server has a bug.

When this happens, you need to be able to roll back fast without going through DNS propagation delays.

The fastest rollback is to change your policy from p=reject to p=quarantine immediately:

v=DMARC1; p=quarantine; rua=mailto:reports@example.com;

This takes effect as soon as the receiving mail servers pick up the new DNS record, typically within minutes to an hour for major providers. Email that was being rejected goes to quarantine instead, buying you time to investigate.

If you need to completely stop enforcement instantly (for example, if your primary mail server fails and you need to fall back to a temporary relay that is not aligned), you can move to p=none:

v=DMARC1; p=none; rua=mailto:reports@example.com;

DNS TTL affects how fast this propagates. Set your _dmarc.example.com TXT record TTL to 300 seconds (5 minutes) during the migration period so that any policy change takes effect quickly. After you have stabilized at p=reject, you can increase the TTL to reduce query load.

One thing most migration guides skip: set up alerting on your DMARC reports before you move to p=reject. If you are manually checking XML reports every few hours, you will miss problems that occur overnight or over the weekend. A monitoring tool that sends you a Slack alert or email when your failure rate spikes is not optional during this transition. It is the difference between discovering a problem from a user complaint versus catching it from a dashboard.

What to Watch in the First 72 Hours After Moving to p=reject

During the first 72 hours after moving to p=reject, check your DMARC aggregate reports at least every 8 to 12 hours. Look for:

Spikes in authentication failures: If your failure rate jumps from 2% to 20% overnight, something changed. Either you missed a legitimate sender, or an attacker just started spoofing your domain (which p=reject should now be blocking, but you want to confirm).

New source IP addresses: Your aggregate reports show which IP addresses are sending email from your domain. A sudden new IP that you do not recognize could be a legitimate sender you missed, or it could be spoofing attempts now being caught.

Complaints from internal users: If legitimate email from your own employees starts bouncing, you have an alignment problem. Common causes include:

• Remote employees using personal devices that relay through non-aligned SMTP servers


• Internal applications that send email using the corporate domain but do not have DKIM signing


• HR systems, ticketing platforms, or DevOps tools that were not included in your sender audit

A monitoring tool like DMARCFlow is specifically useful during this window. It parses your aggregate reports automatically and alerts you when failure rates change, which means you catch problems before they turn into weekend phone calls. The 72-hour window after moving to p=reject is not the time to be checking XML files manually.

FAQ

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

A minimum of 30 days is typical for domains with moderate email volume. If your domain sends fewer than 1,000 emails per week, consider staying at p=none for 60 to 90 days to ensure you capture periodic sending patterns such as monthly newsletters or quarterly batch jobs.

What percentage of DMARC failures is acceptable before moving to p=reject?

Ideally, zero unexplained failures. Your aggregate reports should show 100% alignment for all legitimate senders before you move to enforcement. If you have 5% or fewer failures that you have traced to known senders you have decided not to fix (such as a legacy vendor you have accepted risk for), that is a reasonable threshold.

Can I move to p=reject on just my primary domain and keep subdomains at p=none?

Yes. Use the "sp" (subdomain policy) tag to set a different policy for subdomains. For example: p=reject; sp=none allows you to enforce on your root domain while leaving subdomains unenforced. This is useful during a migration period when some subdomains have vendors you have not yet audited.

What happens if a legitimate vendor suddenly starts failing DMARC after I move to p=reject?

This usually means the vendor changed something on their end: they moved to a new sending infrastructure, changed their DKIM selectors, or updated their SPF records. Contact the vendor's support team and ask them to verify their email authentication setup. In the meantime, move your policy to p=quarantine to avoid blocking their email while you resolve the issue.

Do I need DKIM alignment with all sending sources before moving to p=reject?

You need alignment for every legitimate sender you want to continue receiving email from. If a vendor sends email from infrastructure that cannot be aligned with your domain, you either need to exclude their subdomain from your policy (using sp=none or sp=quarantine) or find an alternative vendor that supports proper alignment.