Performing DMARC Policy Enforcement Rollout
Overview
Domain-based Message Authentication, Reporting and Conformance (DMARC) is the cornerstone of email anti-spoofing protection. A DMARC rollout progresses through three phases: monitoring (p=none), quarantine (p=quarantine), and full enforcement (p=reject). When configured at p=reject, any email that fails both SPF and DKIM checks is outright rejected. Google and Yahoo now require DMARC for bulk senders (5,000+ emails), driving a 65% reduction in unauthenticated messages. The rollout typically takes 3-6 months for safe deployment.
When to Use
- When conducting security assessments that involve performing dmarc policy enforcement rollout
- When following incident response procedures for related security events
- When performing scheduled security testing or auditing activities
- When validating security controls through hands-on testing
Common Misconfigurations & Verification
- Stuck at p=none: monitoring indefinitely yields reports but no anti-spoofing protection - commit to advancing through quarantine to reject on a 3-6 month timeline.
- Jumping straight to p=reject: skipping the
pct ramp blocks legitimate sources that aren't yet aligned - step pct 10->25->50->100 at each policy level with 1-2 weeks of report review between increases.
- SPF over the 10-lookup limit: too many
include: entries cause permerror and silent failure - flatten and consolidate before enforcing.
- DKIM signing missing on a sending source: marketing/CRM/ticketing platforms (Mailchimp, SendGrid, Zendesk) often go unsigned and get rejected at p=reject - inventory and sign every source first.
- Alignment vs. pass confusion: a source can pass SPF/DKIM yet fail DMARC because the domain doesn't align - check alignment in aggregate reports, not just auth pass.
- No subdomain policy / no rollback plan: omit
sp=reject and subdomains stay spoofable; keep an emergency revert (reject->quarantine) ready.
- Verification: confirm aggregate reports show >99% legitimate mail passing with alignment before each step; send a self-domain spoof from an unauthorized IP and confirm it is rejected; verify no legitimate source is blocked after full p=reject and sp=reject.
Prerequisites
- Administrative access to DNS management for the domain
- Understanding of SPF, DKIM, and DMARC protocols (RFC 7208, 6376, 7489)
- Complete inventory of all legitimate email sending sources
- DMARC reporting analysis tool (EasyDMARC, DMARCLY, Valimail, or dmarcian)
- Email gateway with DMARC enforcement capability
Key Concepts
DMARC Policy Levels
| Policy |
Behavior |
Use Case |
| p=none |
Monitor only, no action on failures |
Discovery phase |
| p=quarantine |
Send failing messages to spam/junk |
Transition phase |
| p=reject |
Block failing messages entirely |
Full enforcement |
DMARC Record Anatomy
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-agg@company.com; ruf=mailto:dmarc-forensic@company.com; adkim=r; aspf=r; fo=1
- p: Policy for organizational domain
- sp: Policy for subdomains
- pct: Percentage of messages subject to policy (for gradual rollout)
- rua: Aggregate report destination (daily XML reports)
- ruf: Forensic report destination (per-failure reports)
- adkim: DKIM alignment mode (r=relaxed, s=strict)
- aspf: SPF alignment mode (r=relaxed, s=strict)
- fo: Failure reporting options (0=both fail, 1=either fails)
SPF and DKIM Alignment
- SPF Alignment: The domain in the Return-Path (envelope sender) must match the From header domain
- DKIM Alignment: The d= domain in the DKIM signature must match the From header domain
- Relaxed: Organizational domain match (sub.example.com matches example.com)
- Strict: Exact domain match required
Workflow
Step 1: Inventory All Sending Sources (Week 1-2)
- Audit all systems sending email as your domain (marketing, CRM, ticketing, transactional)
- Document third-party services: Salesforce, Mailchimp, SendGrid, Zendesk, etc.
- Identify internal mail servers, applications, and relay hosts
- Check for shadow IT email sending (departments using unauthorized services)
Step 2: Configure SPF and DKIM (Week 2-4)
- Consolidate SPF record with all legitimate sending IPs and includes
- Ensure SPF record stays under 10 DNS lookup limit
- Generate and publish DKIM keys for each sending source
- Verify DKIM signing works for all outbound mail paths
- Test with MX Toolbox or dmarcian SPF/DKIM validators
Step 3: Deploy DMARC in Monitoring Mode (Week 4-6)
- Publish initial DMARC record:
v=DMARC1; p=none; rua=mailto:dmarc@company.com; fo=1
- Wait 1-2 weeks to collect representative aggregate reports
- Analyze reports to identify unauthorized senders and alignment failures
- Fix SPF/DKIM for all legitimate sources showing failures
- Iterate until all legitimate mail passes DMARC
Step 4: Move to Quarantine with pct Tag (Week 6-12)
- Update to quarantine at 10%:
v=DMARC1; p=quarantine; pct=10; rua=...
- Monitor for false positives (legitimate mail being quarantined)
- Increase pct gradually: 10% -> 25% -> 50% -> 75% -> 100%
- Each increase: wait 1-2 weeks and review reports before advancing
- Fix any remaining alignment issues discovered at each stage
Step 5: Advance to Reject Policy (Week 12-20)
- After stable quarantine at 100%, move to reject at 10%:
v=DMARC1; p=reject; pct=10; rua=...
- Gradually increase pct: 10% -> 25% -> 50% -> 100%
- Monitor closely for legitimate mail being rejected
- Establish emergency rollback procedure (revert to quarantine)
- Apply subdomain policy:
sp=reject for subdomains
Step 6: Ongoing Monitoring and Maintenance
- Continuously monitor DMARC aggregate reports
- Add new sending sources before they start sending
- Review forensic reports for spoofing attempts
- Maintain SPF record as sending infrastructure changes
- Rotate DKIM keys annually
Tools & Resources
- EasyDMARC: DMARC monitoring dashboard with aggregate/forensic report analysis
- DMARCLY: SPF, DKIM, DMARC monitoring with auto-DNS updates
- dmarcian: DMARC deployment and management platform
- Valimail: Automated DMARC enforcement with hosted authentication
- MX Toolbox: DNS record lookup and DMARC validator
- Google Admin Toolbox: DMARC check and diagnostic tools
Validation
- DMARC record published and resolving correctly at _dmarc.domain.com
- All legitimate sending sources pass SPF and/or DKIM alignment
- Aggregate reports show >99% legitimate mail passing DMARC
- Spoofed messages from unauthorized senders are rejected
- No legitimate mail blocked after full p=reject enforcement
- Subdomain policy (sp=) also set to reject
1---2name: performing-dmarc-policy-enforcement-rollout3description: Execute a phased DMARC rollout from p=none monitoring through p=quarantine to p=reject enforcement, ensuring all legitimate email sources are authenticated before blocking unauthorized senders.4license: Apache-2.05---6# Performing DMARC Policy Enforcement Rollout78## Overview9Domain-based Message Authentication, Reporting and Conformance (DMARC) is the cornerstone of email anti-spoofing protection. A DMARC rollout progresses through three phases: monitoring (p=none), quarantine (p=quarantine), and full enforcement (p=reject). When configured at p=reject, any email that fails both SPF and DKIM checks is outright rejected. Google and Yahoo now require DMARC for bulk senders (5,000+ emails), driving a 65% reduction in unauthenticated messages. The rollout typically takes 3-6 months for safe deployment.101112## When to Use1314- When conducting security assessments that involve performing dmarc policy enforcement rollout15- When following incident response procedures for related security events16- When performing scheduled security testing or auditing activities17- When validating security controls through hands-on testing1819## Common Misconfigurations & Verification2021- **Stuck at p=none:** monitoring indefinitely yields reports but no anti-spoofing protection - commit to advancing through quarantine to reject on a 3-6 month timeline.22- **Jumping straight to p=reject:** skipping the `pct` ramp blocks legitimate sources that aren't yet aligned - step pct 10->25->50->100 at each policy level with 1-2 weeks of report review between increases.23- **SPF over the 10-lookup limit:** too many `include:` entries cause `permerror` and silent failure - flatten and consolidate before enforcing.24- **DKIM signing missing on a sending source:** marketing/CRM/ticketing platforms (Mailchimp, SendGrid, Zendesk) often go unsigned and get rejected at p=reject - inventory and sign every source first.25- **Alignment vs. pass confusion:** a source can pass SPF/DKIM yet fail DMARC because the domain doesn't align - check alignment in aggregate reports, not just auth pass.26- **No subdomain policy / no rollback plan:** omit `sp=reject` and subdomains stay spoofable; keep an emergency revert (reject->quarantine) ready.27- **Verification:** confirm aggregate reports show >99% legitimate mail passing with alignment before each step; send a self-domain spoof from an unauthorized IP and confirm it is rejected; verify no legitimate source is blocked after full p=reject and sp=reject.2829## Prerequisites30- Administrative access to DNS management for the domain31- Understanding of SPF, DKIM, and DMARC protocols (RFC 7208, 6376, 7489)32- Complete inventory of all legitimate email sending sources33- DMARC reporting analysis tool (EasyDMARC, DMARCLY, Valimail, or dmarcian)34- Email gateway with DMARC enforcement capability3536## Key Concepts3738### DMARC Policy Levels39| Policy | Behavior | Use Case |40|---|---|---|41| p=none | Monitor only, no action on failures | Discovery phase |42| p=quarantine | Send failing messages to spam/junk | Transition phase |43| p=reject | Block failing messages entirely | Full enforcement |4445### DMARC Record Anatomy46```47v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-agg@company.com; ruf=mailto:dmarc-forensic@company.com; adkim=r; aspf=r; fo=148```49- **p**: Policy for organizational domain50- **sp**: Policy for subdomains51- **pct**: Percentage of messages subject to policy (for gradual rollout)52- **rua**: Aggregate report destination (daily XML reports)53- **ruf**: Forensic report destination (per-failure reports)54- **adkim**: DKIM alignment mode (r=relaxed, s=strict)55- **aspf**: SPF alignment mode (r=relaxed, s=strict)56- **fo**: Failure reporting options (0=both fail, 1=either fails)5758### SPF and DKIM Alignment59- **SPF Alignment**: The domain in the Return-Path (envelope sender) must match the From header domain60- **DKIM Alignment**: The d= domain in the DKIM signature must match the From header domain61- **Relaxed**: Organizational domain match (sub.example.com matches example.com)62- **Strict**: Exact domain match required6364## Workflow6566### Step 1: Inventory All Sending Sources (Week 1-2)67- Audit all systems sending email as your domain (marketing, CRM, ticketing, transactional)68- Document third-party services: Salesforce, Mailchimp, SendGrid, Zendesk, etc.69- Identify internal mail servers, applications, and relay hosts70- Check for shadow IT email sending (departments using unauthorized services)7172### Step 2: Configure SPF and DKIM (Week 2-4)73- Consolidate SPF record with all legitimate sending IPs and includes74- Ensure SPF record stays under 10 DNS lookup limit75- Generate and publish DKIM keys for each sending source76- Verify DKIM signing works for all outbound mail paths77- Test with MX Toolbox or dmarcian SPF/DKIM validators7879### Step 3: Deploy DMARC in Monitoring Mode (Week 4-6)80- Publish initial DMARC record: `v=DMARC1; p=none; rua=mailto:dmarc@company.com; fo=1`81- Wait 1-2 weeks to collect representative aggregate reports82- Analyze reports to identify unauthorized senders and alignment failures83- Fix SPF/DKIM for all legitimate sources showing failures84- Iterate until all legitimate mail passes DMARC8586### Step 4: Move to Quarantine with pct Tag (Week 6-12)87- Update to quarantine at 10%: `v=DMARC1; p=quarantine; pct=10; rua=...`88- Monitor for false positives (legitimate mail being quarantined)89- Increase pct gradually: 10% -> 25% -> 50% -> 75% -> 100%90- Each increase: wait 1-2 weeks and review reports before advancing91- Fix any remaining alignment issues discovered at each stage9293### Step 5: Advance to Reject Policy (Week 12-20)94- After stable quarantine at 100%, move to reject at 10%: `v=DMARC1; p=reject; pct=10; rua=...`95- Gradually increase pct: 10% -> 25% -> 50% -> 100%96- Monitor closely for legitimate mail being rejected97- Establish emergency rollback procedure (revert to quarantine)98- Apply subdomain policy: `sp=reject` for subdomains99100### Step 6: Ongoing Monitoring and Maintenance101- Continuously monitor DMARC aggregate reports102- Add new sending sources before they start sending103- Review forensic reports for spoofing attempts104- Maintain SPF record as sending infrastructure changes105- Rotate DKIM keys annually106107## Tools & Resources108- **EasyDMARC**: DMARC monitoring dashboard with aggregate/forensic report analysis109- **DMARCLY**: SPF, DKIM, DMARC monitoring with auto-DNS updates110- **dmarcian**: DMARC deployment and management platform111- **Valimail**: Automated DMARC enforcement with hosted authentication112- **MX Toolbox**: DNS record lookup and DMARC validator113- **Google Admin Toolbox**: DMARC check and diagnostic tools114115## Validation116- DMARC record published and resolving correctly at _dmarc.domain.com117- All legitimate sending sources pass SPF and/or DKIM alignment118- Aggregate reports show >99% legitimate mail passing DMARC119- Spoofed messages from unauthorized senders are rejected120- No legitimate mail blocked after full p=reject enforcement121- Subdomain policy (sp=) also set to reject
xalgord