DMARC Implementation Guide

DMARC implementation isn't just publishing a DNS record - it's a process that requires understanding your email ecosystem, configuring SPF and DKIM properly, and progressively tightening policy as you verify authentication is working.

Rushing to enforcement can block legitimate email. A methodical approach ensures you protect your domain without disrupting business communication.

Implementation Phases

1. Audit and inventory all sending sources
2. Configure SPF for all authorized senders
3. Configure DKIM for all sending services
4. Publish DMARC at p=none (monitoring only)
5. Analyze reports and fix authentication failures
6. Progress through quarantine to reject

Identify All Sending Sources

Before configuring authentication, inventory every service that sends email using your domain:

• Primary email system (Google Workspace, Microsoft 365, on-premise)
• Marketing platforms (Mailchimp, HubSpot, Marketo)
• Transactional email (SendGrid, Postmark, Amazon SES)
• CRM and sales tools (Salesforce, Outreach)
• Support/helpdesk systems (Zendesk, Freshdesk)
• Application notifications (custom apps, SaaS tools)

Document Each Service

For each sending source, document:

• Service name and purpose
• Sending IPs or include statements for SPF
• DKIM configuration options
• Current authentication status (if known)
• Business owner and technical contact

This inventory becomes your implementation checklist. Missing even one source can cause authentication failures.

Initial DMARC Record

Start with a monitoring-only policy to collect data:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; ruf=mailto:dmarc@yourdomain.com

• p=none: Don't affect message delivery
• rua: Address for aggregate reports (daily XML)
• ruf: Address for forensic reports (per-failure)

What p=none Does

With policy at none, receiving servers will:

• Check SPF and DKIM as usual
• Check DMARC alignment
• Send aggregate reports to your rua address
• NOT change delivery based on DMARC result

This gives you visibility into authentication results across all senders without risk of blocking legitimate mail.

Understanding Aggregate Reports

DMARC aggregate reports (rua) are XML files showing:

• IP addresses that sent email as your domain
• Volume of messages from each source
• SPF and DKIM pass/fail results
• DMARC alignment status

Raw XML is difficult to interpret. Use a tool like DMARCsimple to parse reports into actionable dashboards.

Common Issues to Fix

• Missing SPF include: Add the service to your SPF record
• DKIM not configured: Enable DKIM in the service and publish DNS records
• Alignment failures: Ensure Return-Path (SPF) or signing domain (DKIM) matches From
• Unknown senders: Investigate - could be legitimate services you forgot or unauthorized use
• Forwarding issues: Forwarded mail often breaks SPF; ensure DKIM passes

Policy Progression

Once authentication is working for all legitimate sources, progress policy:

1. p=quarantine; pct=10 - Quarantine 10% of failing mail
2. p=quarantine; pct=50 - Increase to 50%
3. p=quarantine; pct=100 - Full quarantine
4. p=reject; pct=10 - Start rejecting failures
5. p=reject - Full enforcement

Monitoring During Progression

• Continue monitoring reports at each stage
• Watch for new authentication failures
• Have a process for quick rollback if needed
• Communicate with stakeholders about timeline
• Be prepared to pause if issues arise

Most organizations reach full enforcement within 4-12 weeks, depending on complexity.

• Rushing to reject: Moving to enforcement before fixing all authentication issues blocks legitimate mail
• Incomplete inventory: Missing sending sources causes unexpected failures
• Ignoring forwarding: Mailing lists and forwarded email break SPF; ensure DKIM is working
• Not monitoring ongoing: Authentication can break when services change infrastructure

• SPF lookup limits: Exceeding 10 DNS lookups causes SPF to fail completely
• Subdomain gaps: Subdomains need their own DMARC records or policy inheritance
• Third-party alignment: Some services can't align DKIM; evaluate alternatives
• Report overload: Use a monitoring tool rather than parsing XML manually