DMARC Implementation Guide: Staged Rollout from p=none to p=reject with Readiness Criteria

DMARC implementation is one of the few security changes that can break your email if done wrong — yet many guides recommend jumping to p=reject as quickly as possible without adequate guidance on what "adequate" means. The staged approach from p=none to p=quarantine to p=reject exists for good reason: every domain has a unique set of sending sources, third-party services, and authentication configurations, and discovering these incrementally prevents the situation where p=reject silently blocks legitimate email from a system you forgot existed.

This guide documents the full implementation journey with specific readiness criteria for each stage transition, the pct= tag strategy for controlled enforcement rollout, the DNS record syntax for each stage, and the monitoring checkpoints that confirm you're ready to advance.

Before You Start: SPF and DKIM Are Prerequisites

DMARC requires both SPF and DKIM to be correctly configured and aligned. Publishing a DMARC record without both authentication methods in place doesn't provide meaningful protection and can reveal authentication gaps that make your domain look worse in aggregate reports, not better.

Verify before publishing your first DMARC record:

# Verify SPF record exists and has no errors
dig TXT yourdomain.com | grep "v=spf1"
# Should return exactly one record starting with v=spf1

# Verify DKIM record exists
dig TXT mail._domainkey.yourdomain.com +short
# Should return a TXT record starting with v=DKIM1

# Send a test email to a Gmail address you control
# View Show Original — check Authentication-Results header
# Must show: spf=pass, dkim=pass, dmarc=pass or dmarc=bestguesspass

If either SPF or DKIM shows "fail" or is missing, fix those first. A DMARC record at p=none when SPF and DKIM are broken will show your domain's failures in aggregate reports — useful for diagnosis, but don't advance to enforcement until the underlying authentication is clean.

Stage 1: p=none — Monitoring Deployment

What p=none does

p=none instructs receiving mail servers to take no action on messages that fail DMARC — deliver them exactly as they would without DMARC in place. The only thing p=none enables is reporting: ISPs that support DMARC will send aggregate reports to your rua= address showing all sending sources, their authentication results, and their volume.

Authentication-Results: mx.google.com;
       dkim=pass header.i=@company.com header.s=selector1 header.b=abc123;
       spf=pass (google.com: domain of noreply@company.com designates 52.x.x.x as permitted sender)
            smtp.mailfrom=noreply@company.com;
       dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=company.com
       bimi=pass header.indicator=https://cert.entrust.net/...
Received-SPF: pass (google.com: domain of noreply@company.com)
        identity=mailfrom; envelope-from="noreply@company.com"

Authentication-Results: mx.google.com;
       dkim=pass header.i=@esp-provider.net header.s=sendgrid;  ← DKIM passes for ESP domain
       spf=pass (domain of bounce@esp-provider.net designates 167.x.x.x);  ← SPF for ESP
       dmarc=fail (p=QUARANTINE sp=QUARANTINE dis=QUARANTINE) header.from=company.com
            ↑ DMARC FAILS: neither SPF nor DKIM aligns with "company.com" From header
X-Forwarded-To: user@gmail.com
# Fix: Configure ESP to sign with company.com DKIM selector OR add return-path alignment

Initial DMARC record

# DNS TXT record at _dmarc.yourdomain.com
# Minimum viable monitoring record
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com

# More complete monitoring record with forensic reporting
v=DMARC1; p=none; 
  rua=mailto:dmarc-reports@yourdomain.com;
  ruf=mailto:dmarc-forensic@yourdomain.com;
  fo=1

The rua= address must be able to receive email and must be actively monitored. At high volume, a dedicated mailbox for DMARC reports fills up quickly — consider using a DMARC reporting service (Postmark's free tool, dmarcian, EasyDMARC) that parses the XML automatically rather than trying to read raw XML files.

What to do during Stage 1

Collect reports for at least 2–4 weeks before making any policy decisions. For complex organisations with many sending services, 4–6 weeks. During this period:

1. Build a sender inventory: For every source IP that appears in your aggregate reports, identify which service it belongs to via reverse DNS lookup. Create a spreadsheet: IP, service name, current DKIM status, current SPF status, authentication result in DMARC.
2. Fix failing legitimate sources: For each known sending service showing DKIM fail or SPF fail, configure proper authentication. Common issues:
   • Marketing platform using their default Return-Path domain (SPF alignment failure) — configure custom bounce domain via CNAME
   • CRM not configured with DKIM for your sending domain — configure in the platform's settings
   • Transactional email service using shared DKIM key — configure dedicated domain signing
3. Document unknown sources: Sources that appear in reports that you don't recognise. These could be: forgotten SaaS tools, shadow IT, or domain spoofing attempts. Investigate each one before advancing to enforcement.

Readiness criteria to advance to Stage 2

• You have identified every significant source IP in your aggregate reports
• All known legitimate sources show DMARC pass (either DKIM pass+aligned or SPF pass+aligned)
• Any remaining DMARC fail records are either: confirmed spoofing attempts (not your mail) or forwarded mail (which always fails SPF after forwarding)
• You've been at p=none for at least 2 weeks with clean data

Stage 2: p=quarantine — Controlled Enforcement

What p=quarantine does

p=quarantine instructs receiving servers to accept the message but deliver it to the recipient's spam/junk folder rather than their inbox. The message is not lost — it can be recovered from spam — but it's treated as suspicious. This is a significant step: legitimate email from an unconfigured sending source will now go to spam.

The pct= tag for incremental rollout

The pct= tag in DMARC specifies what percentage of failing messages should be subject to the policy. This allows you to begin enforcement without immediately affecting all email:

# Stage 2a: Start quarantine at 10% of failing messages
v=DMARC1; p=quarantine; pct=10; 
  rua=mailto:dmarc-reports@yourdomain.com

# Stage 2b: Increase to 50% after verifying no legitimate mail affected
v=DMARC1; p=quarantine; pct=50; 
  rua=mailto:dmarc-reports@yourdomain.com

# Stage 2c: Full quarantine
v=DMARC1; p=quarantine; pct=100; 
  rua=mailto:dmarc-reports@yourdomain.com

Stay at pct=10 for 1–2 weeks and monitor reports carefully. If no legitimate mail appears in spam folders and aggregate reports continue showing your known sources as DMARC pass, advance to pct=50, then pct=100.

Common issues discovered at quarantine stage

The quarantine stage often reveals sending sources that weren't visible during p=none because they sent low enough volume that they didn't appear prominently in reports:

• A development environment sending test emails using the production domain
• An automated monitoring tool emailing alerts using the domain
• An old marketing platform integration that's still active despite a vendor change
• A helpdesk system's auto-responder sending from a subdomain without DKIM

When you discover a new failing source at this stage, return to p=none or reduce pct while you fix the configuration, then advance again.

Readiness criteria to advance to Stage 3

• p=quarantine at pct=100 for at least 2 weeks with no legitimate mail appearing in spam
• Aggregate reports consistently show 95%+ DMARC pass rate across all sources
• The remaining DMARC fail traffic is confirmed as spoofing/forgery (IPs you don't control)
• All major ISPs (Gmail, Microsoft, Yahoo) are sending aggregate reports — confirming visibility across providers

Stage 3: p=reject — Full Enforcement

What p=reject does

p=reject instructs receiving servers to reject outright any message that fails DMARC. Rejection generates a 5xx SMTP error — the message cannot be recovered from any folder. For spoofing and phishing attempts using your domain, this is the desired outcome. For any legitimate mail that fails DMARC (which there should be none of if you completed Stages 1 and 2 correctly), this means the sender gets a bounce.

Staged p=reject rollout

# Stage 3a: Start reject at 10%
v=DMARC1; p=reject; pct=10; 
  rua=mailto:dmarc-reports@yourdomain.com

# Stage 3b: Full reject
v=DMARC1; p=reject; pct=100; 
  rua=mailto:dmarc-reports@yourdomain.com

Even at the reject stage, use pct= to ramp up. pct=10 for 1–2 weeks with close monitoring before advancing to full enforcement.

Subdomains: the sp= tag

By default, your DMARC policy applies to subdomains too. If you have subdomains that send email (mail.yourdomain.com, newsletter.yourdomain.com), they inherit your root domain's DMARC policy unless you configure them separately or use the sp= tag.

# Apply p=reject to root domain but keep subdomains at quarantine
# While configuring subdomain sending
v=DMARC1; p=reject; sp=quarantine; pct=100; 
  rua=mailto:dmarc-reports@yourdomain.com

# Or give specific subdomains their own policy by publishing
# a separate DMARC record at _dmarc.subdomain.yourdomain.com

Parked Domains and Defensive DMARC

Every domain you own that doesn't send email should have a DMARC record at p=reject. Parked domains, legacy domains, and redirect-only domains are frequent targets for spoofing because domain owners often don't monitor them. A simple defensive DMARC record for non-sending domains:

# Defensive DMARC for domains that send zero email
# _dmarc.parked-domain.com
v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s; 
  rua=mailto:dmarc-reports@yourdomain.com

Also publish a null SPF record for non-sending domains: v=spf1 -all

DMARC Alignment Explained

The most common DMARC failure for senders who have both SPF and DKIM passing is alignment failure — passing the authentication check on the wrong domain.

DMARC alignment requires that the authenticated domain matches the From: header domain:

• SPF alignment: The Return-Path (envelope sender / MAIL FROM) domain must match or be a subdomain of the From: header domain. Under relaxed alignment (default), the organisational domain must match. Under strict alignment (aspf=s), they must match exactly.
• DKIM alignment: The d= value in the DKIM-Signature header must match or be a subdomain of the From: header domain. Under relaxed alignment (default), the organisational domain must match. Under strict alignment (adkim=s), they must match exactly.

Relaxed alignment (the default) is appropriate for most senders. Strict alignment is appropriate for high-security domains where you want to prevent any subdomain variation from counting as aligned.

Ongoing DMARC Maintenance

Reaching p=reject is not the end — it's the beginning of an ongoing operational practice. Email infrastructure changes constantly: new vendors, new SaaS tools, new sending services. Each new sending source requires authentication configuration before it goes live, otherwise your DMARC policy will reject its mail.

Establish these operational practices after reaching p=reject:

• Weekly aggregate report review: Even at p=reject, new sources appear. Weekly review catches issues before they cause delivery problems.
• New vendor checklist: Any new tool that will send email from your domain must have SPF and DKIM configured and verified before go-live. Make this part of vendor onboarding.
• Quarterly SPF audit: SPF records accumulate includes from vendors you no longer use. Quarterly audit removes stale entries and keeps the lookup count under control.
• Annual DKIM key rotation: Rotate DKIM keys at minimum every six months per M3AAWG guidance.