Before You Start
- SPF record configured and validated for your domain
- DKIM signing enabled for your primary email platform
- An email address or mailbox dedicated to receiving DMARC reports
- Access to your DNS provider to create TXT records
Publish a DMARC record in monitor mode
Start with a permissive DMARC policy to collect data without affecting mail delivery. Create a TXT record at _dmarc.yourdomain.com with the value v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensics@yourdomain.com; fo=1. The p=none policy tells receiving servers to deliver all email regardless of authentication results but send reports. The rua tag specifies where aggregate reports are sent, and ruf specifies where forensic failure reports are sent. The fo=1 tag requests forensic reports for any authentication failure. Set the TTL to 3600 seconds. This monitoring phase should run for at least four to six weeks to capture a full picture of your email ecosystem.
Set up a DMARC report analyzer
Raw DMARC aggregate reports arrive as XML files attached to emails, and they are difficult to read manually. Sign up for a free or paid DMARC report analyzer such as dmarcian, Postmark DMARC, Valimail, or DMARC Analyzer. Configure the analyzer by adding its reporting address as an additional rua recipient in your DMARC record. The analyzer will parse incoming reports and display dashboards showing which IP addresses are sending email as your domain, whether those messages pass or fail SPF and DKIM, and whether they align with your From domain. This visibility is essential for identifying legitimate senders you have not yet authorized and for spotting spoofing attempts against your domain.
Fix SPF and DKIM alignment issues
DMARC requires alignment, meaning the domain in either the SPF check or the DKIM signature must match the From header domain. Review your DMARC reports for sources that fail alignment. Common causes include third-party services using their own domain in the envelope sender instead of yours, email forwarding services that break SPF, and services that sign with their own DKIM domain. Fix these by configuring custom envelope senders and DKIM signing on each third-party platform. For forwarding issues, rely on DKIM alignment since SPF will naturally break when mail is forwarded. Aim for one hundred percent of your legitimate email to pass DMARC before moving to the next phase.
Move to quarantine policy with a percentage ramp
Once your reports show high pass rates for legitimate mail, begin enforcement by moving to p=quarantine with a percentage tag. Update your DMARC record to v=DMARC1; p=quarantine; pct=10; rua=mailto:dmarc-reports@yourdomain.com. The pct=10 tells receivers to apply the quarantine policy to only ten percent of failing messages, sending the rest to the inbox as before. Monitor reports closely for two weeks. If no legitimate mail is being quarantined, increase to pct=25, then pct=50, then pct=100, pausing two weeks at each stage. This gradual ramp minimizes the risk of accidentally blocking real email while you tighten the policy.
Enforce reject policy
After running at p=quarantine; pct=100 for at least two weeks with clean reports, you are ready for full enforcement. Update your DMARC record to v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.com; ruf=mailto:dmarc-forensics@yourdomain.com. The p=reject policy instructs receiving servers to silently drop any email that fails both SPF and DKIM alignment. This is the strongest protection against domain spoofing. Continue monitoring reports after enforcement because new services may be added to your organization that send email on your behalf. If a new service appears in failure reports, authorize it in SPF and configure DKIM before it becomes a deliverability problem.
Apply DMARC to subdomains
Attackers often spoof subdomains that lack their own DMARC records. The sp tag in your organizational domain DMARC record sets the default policy for subdomains. Add sp=reject to your DMARC record so that subdomains without their own DMARC records inherit the reject policy. If specific subdomains send email legitimately, create individual DMARC records for those subdomains with appropriate policies. For subdomains that should never send email, publish a DMARC record with p=reject and an SPF record of v=spf1 -all to explicitly block all email from those subdomains. This defense-in-depth approach closes off subdomain spoofing attacks entirely.
Document and maintain your DMARC deployment
Create a runbook documenting your DMARC configuration, all authorized senders, their SPF and DKIM settings, and the escalation process for DMARC failures. Assign an owner who reviews DMARC reports at least monthly. Set calendar reminders for DKIM key rotations and SPF record audits. When new email-sending services are onboarded, the runbook should require SPF and DKIM configuration before the service goes live. Include a rollback procedure in case a configuration change causes delivery failures. Store the runbook in your security documentation alongside your incident response plan and review it during quarterly security reviews to keep it current.
Common Mistakes to Avoid
Jumping straight to p=reject without a monitoring phase, causing legitimate email to be silently dropped
Not setting up a DMARC report analyzer and ignoring the XML reports that arrive by email
Forgetting the sp tag for subdomains, leaving them open to spoofing even after the main domain is protected
Failing to configure DKIM alignment for third-party senders before enforcing DMARC
Not reviewing DMARC reports after enforcement when new email services are added to the organization
Get your Cyber Defense Score™ in 60 seconds.
100 tools. No installation. No credit card.
Get My Cyber Defense Score™ →