SPF and DKIM authenticate email, but they do not tell receivers what to do when authentication fails. Should the email be delivered anyway? Sent to spam? Rejected entirely? DMARC answers these questions and adds visibility through reporting.
As of 2024-2025, major mailbox providers require DMARC for anyone sending bulk email. We help organizations implement DMARC correctly, and this guide covers everything you need to know.
How DMARC Works
DMARC builds on SPF and DKIM by adding two critical components:
- Policy: Instructions for what receivers should do with failing messages
- Reporting: Feedback about who is sending email using your domain
The Authentication Check
For DMARC to pass, at least one of the following must be true:
- SPF passes AND the SPF domain aligns with the From header domain
- DKIM passes AND the DKIM signing domain aligns with the From header domain
Alignment means the authenticated domain matches the domain that appears in the visible From address. This prevents attackers from passing SPF or DKIM with their own domains while spoofing your domain in the From header.
DMARC Record Syntax
DMARC is published as a TXT record at _dmarc.yourdomain.com:
v=DMARC1; p=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; pct=100Required Tags
- v=DMARC1: Version (must be first)
- p=: Policy for your domain (none, quarantine, or reject)
Optional Tags
- rua=: Address for aggregate reports
- ruf=: Address for forensic reports
- pct=: Percentage of mail to apply policy (1-100)
- sp=: Policy for subdomains
- adkim=: DKIM alignment mode (r=relaxed, s=strict)
- aspf=: SPF alignment mode (r=relaxed, s=strict)
DMARC Policies Explained
p=none (Monitor Only)
No action is taken on failing messages. Use this when first implementing DMARC to collect data without affecting delivery. This policy satisfies Gmail and Yahoo's minimum requirement.
p=quarantine
Failing messages should be treated as suspicious. Most receivers send these to spam. Use this after confirming all legitimate mail passes authentication.
p=reject
Failing messages should be rejected entirely. This provides maximum protection against spoofing. Only implement after thorough testing.
The Path to p=reject
Moving directly to p=reject without proper preparation can block legitimate email. Follow this path: Start with p=none for 2-4 weeks, analyze reports, fix authentication issues, move to p=quarantine for 2-4 weeks, then finally p=reject.
Why DMARC Is Required
Major mailbox providers now require DMARC for bulk senders:
- Gmail: Required for senders of 5,000+ messages/day since February 2024
- Yahoo: Required for bulk senders since February 2024
- Microsoft: Required for high-volume senders since May 2025
Without DMARC, your emails face increased spam filtering or outright rejection. The minimum acceptable policy is p=none, but providers have signaled they may require stricter policies in the future.
DMARC Alignment
Alignment is the key concept that makes DMARC effective. Without alignment requirements, attackers could pass SPF or DKIM with their own infrastructure while spoofing your domain in the visible From address.
Relaxed vs. Strict Alignment
- Relaxed (default): Domains must share the same organizational domain.
mail.example.comaligns withexample.com - Strict: Domains must match exactly.
mail.example.comdoes not align withexample.com
Most organizations use relaxed alignment, which provides protection while allowing legitimate use of subdomains.
DMARC Reporting
DMARC reports provide visibility into who is sending email using your domain. This is invaluable for identifying unauthorized senders and authentication problems.
Aggregate Reports (rua)
Daily summaries of authentication results from all receiving servers. Shows volume, pass/fail rates, and sending IP addresses. Use these to monitor your email ecosystem.
Forensic Reports (ruf)
Individual message details when authentication fails. Contains more information but raises privacy concerns. Many receivers do not send forensic reports.
Processing DMARC Reports
Raw DMARC reports are XML files that can be difficult to read. Use a DMARC reporting service or tool to aggregate and visualize the data. This makes it much easier to identify issues and track authentication trends.
Implementing DMARC
Step 1: Audit Your Email Sources
List every system that sends email as your domain. This includes marketing platforms, transactional services, CRM systems, and any other tools that send email.
Step 2: Verify SPF and DKIM
Ensure all sending sources pass SPF and DKIM with proper alignment. DMARC cannot pass without at least one aligned authentication method.
Step 3: Publish a p=none Record
v=DMARC1; p=none; rua=mailto:[email protected]Start monitoring without affecting delivery. Collect reports for at least 2-4 weeks.
Step 4: Analyze Reports
Review aggregate reports to identify authentication failures. Fix any legitimate sources that fail SPF or DKIM alignment.
Step 5: Increase Policy Strength
Once all legitimate email passes, move to p=quarantine, then p=reject. Use the pct tag to gradually increase the percentage of mail affected.
Common DMARC Mistakes
Forgetting Third-Party Senders
Marketing platforms, support systems, and other tools often send email as your domain. If they are not properly authenticated, they fail DMARC. Audit all sending sources before tightening your policy.
Ignoring Subdomains
Without an sp= tag, subdomains inherit your main domain policy. Attackers may spoof unprotected subdomains. Use sp=reject to protect all subdomains, or publish separate DMARC records for subdomains that need different policies.
Not Monitoring Reports
DMARC reports reveal authentication problems and unauthorized senders. Without monitoring, you cannot know if your authentication is working or if someone is spoofing your domain.
Moving to Reject Too Quickly
Implementing p=reject without thorough testing blocks legitimate email. Always start with p=none, analyze reports, and gradually increase policy strength.