DMARC (Domain-based Message Authentication, Reporting, and Conformance) is an email security protocol. It protects your domain from spoofing and phishing and gives visibility into your email traffic.
What is DMARC?
DMARC builds on two email checks: SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail). It lets you publish a policy that tells receivers how to handle email that fails these checks.
When a message arrives, the receiving server checks SPF and DKIM. It then applies your DMARC policy to decide what to do with failed emails.
DMARC is defined in RFC 7489 (2015). The next spec, DMARCbis, is in IETF Last Call and expected as a Proposed Standard in 2025.
Why DMARC Matters
Email spoofing is a common attack. With DMARC, you can:
- Block exact-domain spoofing - Stop emails that pretend to be your domain (95%+ at p=reject)
- Protect brand trust - Maintain trust with customers and partners
- Improve deliverability - Authenticated emails land in inbox more often
- Gain visibility - Get XML aggregate reports for all sources using your domain
- Meet sender rules - Google and Yahoo require DMARC for bulk senders (5,000+/day) in 2024
How DMARC Works
DMARC works in four steps:
1. Authentication Check
The server runs SPF and DKIM checks to verify the message.
2. Alignment Verification
DMARC checks if the From domain aligns with the domains that passed SPF or DKIM.
3. Policy Application
Based on your DNS policy, the server decides how to handle failed emails:
- None (p=none) - Take no action, but send reports
- Quarantine (p=quarantine) - Send suspicious messages to spam folder
- Reject (p=reject) - Reject suspicious messages completely
4. Reporting
Receivers send aggregate and sometimes forensic reports back to you. Aggregate reports (RUA) are daily stats. Forensic reports (RUF) include details about individual failed messages.
DMARC Record Structure
A DMARC record is a DNS TXT record at _dmarc.yourdomain.com. It uses tags to define your policy:
For all fields and rules, see our DMARC DNS Specifications reference guide.
Key DMARC Tags
- v - Version (always DMARC1)
- p - Policy for the domain (none, quarantine, reject)
- rua - Email address for aggregate reports (XML format, daily frequency)
- ruf - Email address for forensic reports (message samples for failed auth)
- sp - Policy for subdomains (inherits parent domain policy if not specified)
- adkim - DKIM alignment (r=relaxed allows org-domain match; s=strict needs exact match)
- aspf - SPF alignment (r=relaxed allows org-domain match; s=strict needs exact match)
- pct - Percentage of messages to apply policy (0-100, being replaced by t=y/n flag in DMARCbis)
- rf - Reporting format (afrf for authentication failure reports)
- ri - Reporting interval in seconds (86400 = daily default)
Infrastructure Considerations
Use secure, well‑configured mail servers. For hardened VPS hosting, consider VPSArmor.
Getting Started with DMARC
Roll out DMARC step by step. Use this simple plan:
Phase 1: Monitor (p=none)
Start with monitoring (no impact on delivery). Collect data first:
Review reports for 1–2 weeks (simple) or 4+ weeks (complex) to find all legitimate senders. Use fo=1 to request forensic reports on failure. Note: Gmail, Yahoo, and Microsoft rarely send RUF due to privacy.
Phase 2: Quarantine (p=quarantine)
After SPF/DKIM are set for all legitimate sources, move to quarantine:
Start with pct=25. Increase to 100% as confidence grows.
Phase 3: Reject (p=reject)
Block failed emails completely:
Use strict alignment (adkim=s; aspf=s) for stronger security. Set sp=reject to protect subdomains.
Common DMARC Challenges
DMARC is powerful, but teams often face these issues:
Email Source Discovery
Many teams discover more legitimate senders than expected, including third‑party tools, marketing platforms, and legacy systems.
Authentication Setup
Setting SPF and DKIM for every sender can be complex, especially at scale.
Report Analysis
Aggregate reports are XML files with pass/fail stats, source IPs, and auth results. They are usually compressed (GZIP/ZIP) and sent daily. Forensic reports (ARF) include headers but are rare due to privacy rules.
DMARC Validation & Testing
Validate your DMARC setup with these checks:
Check DMARC Record
Test Email Authentication
Monitor Implementation
Advanced DMARC Configuration
Alignment Modes Explained
Alignment sets how closely the From domain must match authenticated domains:
Relaxed Alignment (default)
- DKIM: mail.example.com signing for example.com ✅
- SPF: subdomain.example.com Return-Path for example.com ✅
Strict Alignment
- DKIM: Must match exactly: example.com ↔ example.com ✅
- SPF: Must match exactly: example.com ↔ example.com ✅
Subdomain Policy Inheritance
Troubleshooting Common Issues
DMARC Pass but Delivery Issues
- Check reputation: Domain/IP may be on blocklists
- Content filters: Message content may trigger spam filters
- Rate limiting: Sending too many emails too fast
Authentication Failures
- SPF failures: Missing IPs in SPF, over 10 DNS lookups (RFC 7208), forwarding breaks SPF
- DKIM failures: Wrong selector, weak keys (< 1024‑bit, RFC 8301), body changes, mailing list footers
- Alignment failures: Domain mismatch in relaxed/strict mode, org‑domain vs subdomain issues
- ARC help: RFC 8617 (Authenticated Received Chain) preserves auth through forwarding (Gmail, Outlook, Yahoo support it)
Report Delivery Problems
- RUA/RUF not received: Check mail server, spam filters, mailbox size
- XML parsing errors: Use a DMARC analyzer, validate XML
- Too many reports: Rate‑limit, or use an external service
Performance & Security Considerations
DNS Performance
- TTL: Use a sensible TTL (3600s is a good default)
- Record size: Keep DMARC records under 512 bytes for UDP
- One record only: Only one DMARC record per domain
- Tree Walk: DMARCbis replaces Public Suffix List with DNS Tree Walk (7‑label limit)
Security Best Practices
- Monitor often: Review reports weekly; alert on auth failures
- Rotate keys: Rotate DKIM keys yearly; use 2048‑bit RSA or Ed25519‑SHA256 (RFC 8463)
- Access control: Restrict DNS record modification access
- Backup reporting: Add multiple RUA addresses
- External reports: Authorize third‑party services with _report._dmarc records
- Stay patched: Keep validators updated (e.g., CVE‑2020‑12272, CVE‑2024‑7208/7209)
Next Steps
Ready to protect your domain? Follow this plan:
- Assessment - Audit senders and current auth
- Prerequisites - Set SPF and DKIM for all sources
- Monitoring - Deploy p=none; collect 2–4 weeks of data
- Analysis - Review RUA/RUF; find all senders
- Enforcement - Ramp from quarantine to reject
- Maintenance - Keep monitoring and responding
For official resources, visit DMARC.org, an initiative of the Trusted Domain Project.
Learn More
Want to go deeper? Explore these guides:
- Free DMARC Generator - Create your first DMARC record
- Why DMARC Was Created: Closing SPF & DKIM Gaps
- SPF Explained: Strengths, Weaknesses & Role in DMARC
- DKIM Deep Dive: Pros, Cons & Alignment with DMARC
Critical: Do not skip monitoring. Jumping to p=reject without analysis can block legitimate emails. Validate SPF and DKIM for 100% of your volume before enforcing reject.
Warning: Avoid these errors: multiple DMARC records, too many SPF lookups, enforcing p=reject without tests, and missing subdomain policies. These cause delivery failures.