DMARC policy migration: the complete roadmap from p=none to p=reject

The three DMARC policy stages

DMARC defines three enforcement levels. Each one tells receiving mail servers what to do with messages that fail authentication. The progression is always the same: monitor, quarantine, reject.

p=none (monitoring only)

The receiving server delivers the message regardless of whether it passes or fails DMARC. You still receive aggregate and forensic reports, but no enforcement action is taken. This is where every DMARC deployment starts.

p=quarantine (partial enforcement)

Messages that fail DMARC are routed to the recipient's spam or junk folder. The message is not lost, but it is flagged as suspicious. This gives you a safety net. If a legitimate source is misconfigured, users can still find the message in spam and report the problem.

p=reject (full enforcement)

The receiving server rejects the message outright during the SMTP transaction. The sender gets a bounce. The recipient never sees the message at all. This is the strongest protection against spoofing and phishing.

Skipping from p=none directly to p=reject is a common mistake that causes legitimate mail loss. Marketing emails, transactional messages, CRM notifications, and helpdesk replies can all fail silently if they have not been properly authenticated. The phased approach described below eliminates that risk.

Phase 1: publish p=none and start monitoring

Your first DMARC record should enable monitoring without any enforcement. Publish the following TXT record at _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]

The rua tag tells receivers where to send aggregate reports (XML summaries of authentication results). The ruf tag requests forensic reports (individual failure details). Not all receivers send forensic reports, but aggregate reports are widely supported.

How long to stay at p=none

Minimum: 2 to 4 weeks. Ideal: 4 to 8 weeks. The goal is to capture every sending pattern your domain uses. Some senders only fire once a month (newsletters, quarterly financial reports, automated billing summaries). If you move to enforcement before capturing these, you will miss them and they will break.

What to look for in reports

Your aggregate reports will show every IP address that sent mail using your domain in the From header. For each source, you need to answer three questions:

1. Is this a legitimate sender? (Your mail server, your ESP, your CRM, a partner sending on your behalf)
2. Does it pass SPF? (The sending IP is listed in your SPF record, and the Return-Path domain aligns with your From domain)
3. Does it pass DKIM? (The message is DKIM-signed with a d= value that matches your From domain)

Build a sending source inventory

Create a spreadsheet or document listing every legitimate sending source. For each one, record:

• Source name: e.g., Mailchimp, Salesforce, your on-premise Exchange server
• Sending IPs: the IP addresses or ranges shown in your reports
• SPF status: pass or fail
• DKIM status: pass or fail, and the d= domain used
• Alignment: does SPF or DKIM align with your From domain?

Your target before moving to the next phase: 95%+ DMARC pass rate across all legitimate sources. Use the DMARCTrust dashboard to track this automatically.

Phase 2: reading reports and fixing sources

How to interpret aggregate reports

Aggregate reports are XML files. Each report contains one or more <record> elements. Each record describes a group of messages from a single source IP with identical authentication results.

The key elements inside each record:

• <source_ip>: the IP address that sent the messages
• <count>: the number of messages in this group
• <policy_evaluated>: the DMARC verdict. Contains <dkim> (pass/fail), <spf> (pass/fail), and <disposition> (none, quarantine, or reject)
• <auth_results>: the raw SPF and DKIM results before alignment is applied

The difference between <policy_evaluated> and <auth_results> matters. A message can pass raw SPF (the IP is authorized) but fail DMARC SPF alignment (the Return-Path domain does not match the From domain). This is one of the most common causes of DMARC failure for third-party senders. For a detailed explanation of the DMARC record structure, see the DMARC tags guide.

Common sources that fail

• Old marketing tools still sending as your domain but using their own Return-Path and no custom DKIM
• Forgotten subdomain services like support.yourdomain.com or billing.yourdomain.com with no SPF/DKIM setup
• Partners and vendors sending on your behalf (recruitment platforms, payroll systems, e-commerce platforms)
• Legacy on-premise servers with outdated configurations
• Internal test environments that send email using production domain names

Fix each failing source

For each source that fails DMARC, you have two paths:

1. Configure custom DKIM: ask the vendor to sign messages with a DKIM key where d=yourdomain.com. This is the preferred approach because DKIM survives forwarding. Most modern ESPs support this.
2. Configure a custom Return-Path: set the bounce address (envelope sender) to a subdomain you control, like bounce.yourdomain.com, and include the vendor's sending IPs in that subdomain's SPF record. This achieves SPF alignment.

Ideally, configure both. If you can only do one, prioritize DKIM. It is more resilient.

Use pct= for gradual rollout

The pct tag controls what percentage of failing messages have the policy applied. For example:

v=DMARC1; p=quarantine; pct=10; rua=mailto:[email protected]

This means only 10% of messages that fail DMARC will be quarantined. The other 90% will be treated as if the policy were p=none. This lets you test enforcement on a small subset before committing fully.

Subdomains

By default, subdomains inherit the parent domain's DMARC policy. You can override this with:

• sp= in the parent record: sets a default subdomain policy (e.g., sp=reject)
• A separate _dmarc.subdomain.yourdomain.com record: gives that specific subdomain its own policy

If you have subdomains that send mail, audit them individually. If you have subdomains that should never send mail, set sp=reject to block spoofing on those subdomains.

Phase 3: move to p=quarantine (soft enforcement)

Once your sending source inventory is complete and your pass rate is above 95%, you are ready for soft enforcement. Update your DMARC record:

v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]

Gradual escalation

Increase the pct value over 2 to 4 weeks:

1. Week 1: pct=25. One quarter of failing messages go to spam.
2. Week 2: pct=50. Half of failing messages go to spam.
3. Week 3: pct=100 (or remove the pct tag entirely). All failing messages go to spam.

What to monitor

• User complaints: "My emails are going to spam." This usually indicates an unauthenticated source you missed.
• Aggregate reports: look for unexpected failures. New sources may appear that were not active during your monitoring period.
• Bounce rates: a sudden increase in bounces from a specific sending service suggests a configuration problem.

Stay at p=quarantine; pct=100 for at least 2 weeks with clean reports before moving to reject. If you see problems, fix them before escalating.

Rolling back

If something goes wrong, change the policy back to p=none. DNS propagation typically takes minutes to a few hours. During propagation, some receivers will still apply the old policy. This is expected and temporary.

Phase 4: move to p=reject (full enforcement)

This is the final stage. At p=reject, unauthorized messages are dropped entirely. There is no undo for individual messages. Once the receiving server rejects a message, it is gone.

v=DMARC1; p=reject; pct=25; rua=mailto:[email protected]

Gradual escalation

Same approach as quarantine. Increase pct over 2 to 3 weeks:

1. Week 1: pct=25. One quarter of failing messages are rejected.
2. Week 2: pct=50. Half of failing messages are rejected.
3. Week 3: pct=100. All failing messages are rejected.

Once you reach pct=100, you can simplify your record to:

v=DMARC1; p=reject; rua=mailto:[email protected]

Expected impact

Legitimate forwarded mail will be affected. When a message is forwarded through an intermediary (mailing list, email forwarding service), SPF breaks because the sending IP changes. If the intermediary also modifies the message body or headers, DKIM breaks too. This is a known limitation of DMARC. For details and mitigation strategies, see the forwarding and ARC troubleshooting guide.

Ongoing vigilance

New services, new employees, mergers, and acquisitions can introduce new sending sources at any time. A marketing team signs up for a new campaign tool. An HR department starts using a new recruiting platform. Each of these can start sending mail as your domain without proper authentication. Keep monitoring.

Pre-reject checklist

Before you change your policy to p=reject, verify every item on this list:

• All known sending sources authenticate with SPF or DKIM (or both)
• DKIM alignment is confirmed for every ESP. The DKIM d= value matches your From domain
• Your SPF record is within the 10-lookup limit. Use dig TXT yourdomain.com and count the include:, redirect=, a:, and mx: mechanisms
• Subdomain policy (sp=) is set appropriately. Non-sending subdomains should have sp=reject
• You have been at p=quarantine; pct=100 for at least 2 weeks with a 99%+ pass rate
• The impact on forwarded mail has been assessed and communicated to affected users
• All stakeholders have been notified: marketing, HR, customer support, IT, finance, and any team that sends email externally

Use the DMARCTrust DMARC checker to verify your current record and authentication status before making the change.

Rollback procedure

If legitimate mail is being rejected after moving to p=reject, follow this procedure:

1. Step 1: downgrade to quarantine immediately. Change your DMARC record to p=quarantine. This stops messages from being dropped. They will go to spam instead, which is recoverable.
2. Step 2: identify the failing source. Check your DMARC aggregate reports for the source IP that is failing authentication. Cross-reference it with your sending source inventory.
3. Step 3: fix authentication. Configure DKIM or SPF for the failing source. If it is a third-party vendor, contact their support team for custom domain authentication setup.
4. Step 4: verify DNS propagation. After updating DNS records, confirm the change has propagated:

   dig TXT _dmarc.yourdomain.com
   dig TXT yourdomain.com  # Check SPF
   dig TXT selector._domainkey.yourdomain.com  # Check DKIM

5. Step 5: return to reject. Once the fix is confirmed in your aggregate reports (allow 24 to 48 hours for reports to arrive), move back to p=reject.

Never go straight back to p=none unless there is a critical, business-wide impact. Dropping to p=none removes all enforcement and re-exposes your domain to spoofing. Quarantine is almost always sufficient as an intermediate step.

Timeline summary

The following timeline assumes a medium-complexity domain with 5 to 15 sending sources. Simpler domains can move faster. Domains with dozens of sending sources or complex subdomain structures may need longer at each stage.

Prevention and ongoing monitoring

Email infrastructure changes after you reach p=reject. New tools get adopted, vendors change their sending infrastructure, and employees set up services that send email as your domain without telling IT.

Set up automated alerts

Configure DMARCTrust alerts to notify you when your authentication pass rate drops below a threshold. A sudden spike in DMARC failures usually means a new or changed sending source.

Weekly report review

Even with alerts, review your aggregate reports at least once a week. Look for:

• New source IPs that you do not recognize
• Changes in volume from known sources (could indicate a compromised account)
• Failures from sources that previously passed (could indicate a DNS or key rotation issue)

Vendor onboarding process

Every time your organization adopts a new tool that sends email, add an authentication step to the onboarding process:

1. Ask the vendor for their SPF include mechanism and DKIM setup instructions
2. Configure custom DKIM with d=yourdomain.com (preferred) or add their IPs to your SPF record
3. Send a test message and verify it passes DMARC using the DMARCTrust checker
4. Add the vendor to your sending source inventory

Document your email sending inventory

Maintain a living document that lists every service authorized to send email as your domain. Include the service name, purpose, SPF/DKIM configuration status, and the team responsible. Review it quarterly. This document saves hours during incident response and when onboarding new IT staff.

Next steps

If you are just starting your DMARC deployment, begin with the introduction to DMARC to understand the fundamentals. Use the DMARC generator to create your initial p=none record, then follow the phases described above.

If you are already at p=quarantine or p=reject and experiencing authentication failures, the other troubleshooting guides cover specific failure types:

• SPF errors: permerror, too many lookups, and void lookups
• DKIM failures: body hash mismatch, signature verification, and key problems
• Alignment issues: why SPF and DKIM pass but DMARC still fails
• Forwarding and ARC: why authentication breaks and how to fix it