DMARC Deployment Guide: Moving from p=none to p=reject Without Breaking Email
To move from DMARC p=none to p=reject without breaking email delivery, complete three sequential phases: a 3-6 week discovery period at p=none to inventory all sending sources, an alignment-fix phase where you add DKIM signing and correct SPF records for every legitimate sender, and a controlled enforcement ramp through p=quarantine before reaching p=reject. DMARC (Domain-based Message Authentication, Reporting, and Conformance) controls what happens when email claiming to be from your domain fails SPF or DKIM authentication. Moving from p=none to p=reject is a 3-phase process taking 6-12 weeks for most organizations, and organizations that skip the discovery phase reliably break legitimate mail when they enforce.
Phase 1: Deploy p=none and Start Collecting Aggregate Reports
The first step is publishing a DMARC record that generates reports without enforcing anything. Add this DNS TXT record to your domain:
_dmarc.yourdomain.com TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-failures@yourdomain.com; fo=1"
Record field breakdown:
p=none: monitor-only, no enforcement actionrua=: aggregate report destination (XML files, delivered daily by receiving mail servers)ruf=: forensic report destination (individual failure reports, not all receivers send these)fo=1: request forensic reports on any authentication failure (not just total DMARC failure)
What aggregate (RUA) reports contain: Each aggregate report is an XML file covering a 24-hour period. Key fields:
source_ip: the IP that sent mail claiming to be from your domaincount: number of messages from that IP in the perioddisposition: what the receiver did (none/quarantine/reject)dkim: pass or failspf: pass or failheader_from: the domain in the From: headerenvelope_from: the MAIL FROM domain used in the SMTP transaction
Tools to parse aggregate reports:
- dmarcian (dmarcian.com): visual dashboard, free tier covers most organizations
- Postmark DMARC (dmarc.postmarkapp.com): free aggregate report parser
- Google Admin Toolbox: useful for Google Workspace users
- Self-hosted: parsedmarc (Python, open source) -- outputs to Elasticsearch or CSV
# Verify your DMARC record is published
dig +short TXT _dmarc.yourdomain.com
# Expected output:
"v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; ..."
Leave p=none in place for a minimum of 3 weeks before reviewing the data. Do not attempt to move to quarantine until you have full sender inventory.
Identifying Every Legitimate Sending Source
After 2-3 weeks of aggregate report collection, export your source IP list and build a sender inventory. Every IP that appears with significant volume is either a legitimate sender you need to align or a spoofing source you will block when you enforce.
Common third-party senders to look for in your aggregate reports:
| Sender | Typical Source IP Range | Default Auth Method | Action Required |
|---|---|---|---|
| Google Workspace | 209.85.x.x / 74.125.x.x | DKIM (google.com) | Add custom DKIM domain via admin console |
| Microsoft 365 | 40.92.x.x / 52.x.x.x | DKIM (onmicrosoft.com) | Configure custom DKIM domain in Defender portal |
| Mailchimp | 198.2.x.x / 205.201.x.x | Custom DKIM via CNAME | Add k1._domainkey CNAME |
| Salesforce | 182.75.x.x / 96.43.x.x | SPF include, optional DKIM | Add custom DKIM key in Salesforce deliverability settings |
| HubSpot | 185.240.x.x | Custom DKIM via CNAME | Configure in HubSpot domain settings |
| Zendesk | 192.161.x.x | SPF include only by default | Add DKIM signing in Zendesk email settings |
| Workday | 167.89.x.x | SPF only | Contact Workday support for DKIM configuration |
| DocuSign | 209.197.x.x | DKIM via CNAME | Add CNAME records provided in DocuSign Admin |
| AWS SES | 54.240.x.x / 23.251.x.x | DKIM via CNAME | Add three CNAME records from SES console |
| SendGrid | 167.89.x.x / 149.72.x.x | Custom DKIM | Add CNAME records from SendGrid domain authentication |
For each sender in your reports:
- Identify the organization from the source IP (use ipinfo.io or Spamhaus lookup)
- Check the dkim and spf columns: is it passing alignment for YOUR domain?
- If dkim=fail or spf=fail (relative to your domain): that sender needs alignment work
- Document in your inventory: Sender | Volume/Day | DMARC Status | Action Required | Owner
Do not move to enforcement until every sender with volume above your threshold (suggest: >10 messages/day) shows DMARC PASS.
Briefings like this, every morning before 9am.
Threat intel, active CVEs, and campaign alerts, distilled for practitioners. 50,000+ subscribers. No noise.
Fixing SPF and DKIM Alignment
Alignment fixes fall into two categories: DKIM signing under your domain, and SPF record hygiene.
SPF record management:
Your SPF record at yourdomain.com should list only sending sources that use your primary domain in the MAIL FROM. Example:
yourdomain.com TXT "v=spf1 include:_spf.google.com include:amazonses.com include:mail.zendesk.com ~all"
Count your current lookup depth:
# Count SPF lookups (each include: = 1 lookup, recursive)
dig +short TXT yourdomain.com | grep spf
# Trace includes manually
dig +short TXT _spf.google.com
dig +short TXT amazonses.com
# Or use a tool
# https://mxtoolbox.com/spf.aspx shows lookup count automatically
If you are at 8+ lookups, use subdomain delegation for bulk senders:
# Create marketing.yourdomain.com with its own SPF
marketing.yourdomain.com TXT "v=spf1 include:servers.mcsv.net ~all"
# Your primary domain record now does not include Mailchimp
yourdomain.com TXT "v=spf1 include:_spf.google.com include:amazonses.com ~all"
DKIM alignment -- adding custom DKIM keys:
For each third-party sender, the process is:
- Log into their admin console and enable custom DKIM signing
- They provide a CNAME or TXT record (e.g.,
k1._domainkey.yourdomain.com CNAME dkim.mailchimpsites.com) - Add the record to your DNS
- Wait for propagation, then verify:
# Verify DKIM record is live
nslookup -type=TXT k1._domainkey.yourdomain.com
# Or with dig
dig +short TXT selector._domainkey.yourdomain.com
# Expected: a TXT record with v=DKIM1; k=rsa; p=<public key>
- Send a test message through that sender and check the raw email headers for:
DKIM-Signature: v=1; a=rsa-sha256; d=yourdomain.com; s=selector;Thed=value must be yourdomain.com for alignment to pass.
Testing full alignment before enforcement:
# Send a test through each sender, then examine headers
# Gmail: open message > three dots > Show original
# Outlook: File > Properties > Internet headers
# Look for:
Authentication-Results: mx.google.com;
dkim=pass header.i=@yourdomain.com;
spf=pass smtp.mailfrom=yourdomain.com;
dmarc=pass (p=NONE) header.from=yourdomain.com
All three must show pass before you move to enforcement.
Moving to p=quarantine
Prerequisites before changing the policy:
- Aggregate reports show 95%+ DMARC pass rate sustained for 3+ weeks
- All senders with volume above your threshold are showing DMARC PASS
- You have reviewed the sources showing DMARC FAIL and confirmed they are spoofing attempts or decommissioned services, not legitimate mail
Update your DMARC record:
_dmarc.yourdomain.com TXT "v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-failures@yourdomain.com"
The pct= tag: This controls what percentage of failing messages receive the quarantine treatment. At pct=10, only 10% of DMARC-failing messages go to spam -- the other 90% are delivered normally. This creates a controlled blast radius for discovering alignment gaps you missed.
Escalation path:
- Start at pct=10 for 1 week. Check spam folders at receiving domains for legitimate mail. Review aggregate reports for unexpected FAIL volume.
- If no legitimate mail appears in spam: move to pct=50 for 1 week
- If still clean: move to pct=100
- Run at pct=100 with p=quarantine for 1-2 weeks before moving to p=reject
What to monitor at p=quarantine:
- Check your own domain's spam folder (send test messages to Gmail, Yahoo, Outlook accounts)
- Watch aggregate reports for FAIL volume that exceeds your known spoofing baseline
- Set up an alert: if authenticated mail volume drops more than 20% week-over-week, investigate before continuing the escalation
- Ask IT and customer-facing teams to report any complaints about email delivery failures
Moving to p=reject
Move to p=reject only when you have been at p=quarantine pct=100 for at least 1-2 weeks with zero confirmed legitimate mail being quarantined.
Final DMARC record:
_dmarc.yourdomain.com TXT "v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; aspf=s; adkim=s; sp=reject"
Record field explanations:
p=reject: failing messages are rejected at the SMTP level, not deliveredaspf=s: strict SPF alignment (envelope From must exactly match your domain, not just share the organizational domain)adkim=s: strict DKIM alignment (d= in signature must exactly match your domain)sp=reject: apply the same reject policy to subdomains not covered by their own DMARC record
Strict vs. relaxed alignment: The default (aspf=r, adkim=r) allows subdomain matching -- mail from marketing.yourdomain.com passes alignment for yourdomain.com. Strict alignment (aspf=s, adkim=s) requires exact domain match. For most organizations, strict is the right choice at p=reject -- it eliminates the subdomain spoofing vector. If you have legitimate mail from subdomains, add their own DMARC records before switching to strict.
Post-enforcement monitoring:
- Continue reviewing aggregate reports weekly
- Configure an alert if DMARC pass rate drops below 98% (indicates a newly deployed sender that missed alignment)
- When onboarding a new email-sending tool: complete DKIM setup and verify alignment before the tool sends its first message to external recipients
- Verify the record is still correct after any DNS provider migration or zone file import
The bottom line
DMARC enforcement fails when organizations skip the discovery phase. Spend 6 weeks at p=none, build an inventory of every sender, fix SPF and DKIM alignment for each one, then ramp through quarantine slowly. The organizations that break mail on the way to p=reject all skipped one of those steps.
Frequently asked questions
What does p=none actually mean in a DMARC record?
p=none is the monitor-only DMARC policy. When a receiving mail server processes a message claiming to be from your domain, it checks SPF and DKIM authentication. If either check fails, p=none instructs the receiver to take no enforcement action -- the message is delivered normally regardless. However, the receiver sends aggregate reports (RUA) and forensic failure reports (RUF) to the addresses you specify in the DMARC record. This reporting is the entire point of p=none: you collect data about every source sending mail that claims to be from your domain, whether legitimate or fraudulent, before you make any enforcement decisions. No mail is blocked, quarantined, or rejected at p=none.
How long should I stay at p=none before moving to p=quarantine?
A minimum of 3-6 weeks, and only move when your aggregate reports show a DMARC pass rate above 95% for all your known legitimate senders. Aggregate reports arrive as XML files in your RUA mailbox, usually daily. Parse them with a tool like dmarcian, Postmark DMARC, or Google Admin Toolbox. Look at the 'disposition' and 'dkim'/'spf' pass/fail columns for each source IP. You want to see every known sending source -- your primary MTA, your ESP, your CRM platform, your helpdesk tool -- showing consistent DMARC PASS results before you apply any enforcement. If you still have a source showing FAIL after 6 weeks, that sender is not aligned yet and will have its mail blocked when you enforce.
What is DMARC alignment and why does it break third-party senders?
DMARC alignment is the requirement that the authenticated domain matches the domain in the From: header that users see. For SPF alignment, the envelope From (also called Return-Path or MAIL FROM) must match your domain. The problem: many third-party senders use their own domain in the envelope From (e.g., bounces.mailchimp.com) to handle bounces, while putting your address in the From: header. This passes SPF for Mailchimp's domain but fails SPF alignment for your domain. For DKIM alignment, the d= value in the DKIM signature must match your From: domain. The fix for third-party senders is to have them sign outgoing mail with a DKIM key you control and publish under your domain, or to use subdomain delegation so the sending subdomain is a child of your domain.
How do I add DMARC without breaking Mailchimp, Salesforce, or other third-party senders?
Each third-party sender requires one of two alignment fixes. Option 1 (DKIM): Request that the sender sign mail with a DKIM key specific to your domain. Most major ESPs support custom DKIM domains. They give you a CNAME record to add to your DNS (e.g., k1._domainkey.yourdomain.com CNAME dkim.mailchimpsites.com) and then sign your mail with that key. This creates DKIM alignment. Option 2 (Subdomain delegation for SPF): Use a subdomain for bulk mail (e.g., marketing.yourdomain.com) with its own SPF record listing only that sender. This contains the SPF include count for your primary domain. Never add a third-party ESP's SPF include to your primary domain's SPF record if you can avoid it -- it bloats your lookup count toward the 10-lookup limit.
What is the SPF 10 DNS lookup limit and how do I stay under it?
RFC 7208 specifies that an SPF evaluation may not trigger more than 10 DNS lookups. Each 'include:', 'a:', 'mx:', 'ptr:', and 'exists:' mechanism in your SPF record counts as one lookup, and the included records' own includes count recursively. Exceeding 10 causes SPF to return PermError, which means DMARC treats SPF as failed for all mail from your domain. To count your current lookups: run 'dig +short TXT yourdomain.com' and trace each include recursively. Tools like dmarcian's SPF Surveyor, MXToolbox, and kitterman.com/spf/validate.html do this automatically. To reduce lookup count: flatten macros (replace includes with the literal IP ranges they resolve to), use subdomains for different senders, or consolidate senders.
What happens to email when I move to p=reject?
At p=reject, a receiving mail server that processes a message claiming to be from your domain will reject it at the SMTP level if it fails both SPF alignment and DKIM alignment. Rejection happens during the SMTP transaction -- the sending server receives a 5xx permanent failure response and the message is not delivered. Unlike p=quarantine (which delivers to spam), rejected messages are not delivered at all and generate a non-delivery report (NDR) to the sender. This means any legitimate sender not yet aligned will have their mail hard-bounced. The mitigation approach: ramp through p=quarantine with pct=10, 50, 100 while watching aggregate reports, confirm zero legitimate sources are failing, then move to p=reject. Post-enforcement, maintain weekly aggregate report reviews and alert on significant drops in authenticated mail volume.
Sources & references
Free resources
Critical CVE Reference Card 2025–2026
25 actively exploited vulnerabilities with CVSS scores, exploit status, and patch availability. Print it, pin it, share it with your SOC team.
Ransomware Incident Response Playbook
Step-by-step 24-hour IR checklist covering detection, containment, eradication, and recovery. Built for SOC teams, IR leads, and CISOs.
Get threat intel before your inbox does.
50,000+ security professionals read Decryption Digest for early warnings on zero-days, ransomware, and nation-state campaigns. Free, weekly, no spam.
Unsubscribe anytime. We never sell your data.
Founder & Cybersecurity Evangelist, Decryption Digest
Cybersecurity professional with expertise in threat intelligence, vulnerability research, and enterprise security. Covers zero-days, ransomware, and nation-state operations for 50,000+ security professionals weekly.
The Mythos Brief is free.
AI that finds 27-year-old zero-days. What it means for your security program.