Want to learn more?
Understand DMARC policies, alignment modes, and how to protect your domain from email spoofing.
Read the guideBuild your DMARC record step by step
DMARC Deployment Overwhelming?
We implement DMARC with monitoring, gradual enforcement, and reporting analysis.
What Is DMARC
DMARC (Domain-based Message Authentication, Reporting and Conformance) is an email authentication protocol that builds on SPF and DKIM to give domain owners control over how receiving mail servers handle unauthenticated messages. Published as a DNS TXT record at _dmarc.yourdomain.com, DMARC specifies a policy (none, quarantine, or reject) and enables aggregate and forensic reporting—giving organizations visibility into who is sending email using their domain.
DMARC addresses the fundamental gap left by SPF and DKIM alone: neither protocol tells receivers what to do when authentication fails. Without DMARC, a spoofed email that fails SPF might still be delivered to the recipient's inbox. DMARC closes this gap by explicitly instructing receivers to monitor, quarantine, or reject unauthenticated messages—making it the most critical email security protocol for preventing domain spoofing and phishing.
How DMARC Works
DMARC validates that at least one of SPF or DKIM passes AND aligns with the From: header domain:
Alignment check: DMARC requires that the domain in the From: header matches (or is a subdomain of) the domain that passed SPF or DKIM. This prevents attackers from passing SPF on their own domain while spoofing the From: address.
DMARC record syntax:
| Tag | Required | Purpose | Example |
|---|---|---|---|
| v | Yes | Version | v=DMARC1 |
| p | Yes | Policy for domain | p=reject |
| sp | No | Policy for subdomains | sp=quarantine |
| rua | No | Aggregate report destination | rua=mailto:[email protected] |
| ruf | No | Forensic report destination | ruf=mailto:[email protected] |
| pct | No | Percentage of messages to apply policy | pct=50 |
| adkim | No | DKIM alignment mode | adkim=s (strict) |
| aspf | No | SPF alignment mode | aspf=r (relaxed) |
Example DMARC record:
v=DMARC1; p=reject; sp=reject; rua=mailto:[email protected]; ruf=mailto:[email protected]; adkim=s; aspf=r; pct=100
DMARC policy progression:
- p=none — Monitor mode; collect reports without affecting delivery (start here)
- p=quarantine — Failed messages go to spam/junk folder
- p=reject — Failed messages are blocked entirely (target state)
Common Use Cases
- Phishing prevention: Stop attackers from sending spoofed emails that appear to come from your domain
- Brand protection: Ensure only authorized services send email using your organization's domain
- Compliance: DMARC enforcement is required by NIST 800-177, FedRAMP, CMMC, and many industry standards
- Deliverability improvement: Domains with DMARC p=reject have higher inbox placement rates at major providers
- Visibility: DMARC aggregate reports reveal every IP address sending email using your domain
Best Practices
- Start with p=none and monitor — Deploy DMARC in monitor mode first to identify all legitimate email sources before enforcing
- Analyze aggregate reports weekly — RUA reports show which IPs are passing and failing authentication; use tools like DMARCian, Valimail, or Postmark to parse XML reports
- Progress to p=reject within 3-6 months — Remaining on p=none provides no protection; set a timeline for enforcement
- Apply the same policy to subdomains — Use sp=reject to prevent subdomain spoofing (attackers target unprotected subdomains)
- Require strict DKIM alignment — adkim=s ensures the DKIM signing domain exactly matches the From: domain, preventing subdomain-based bypass
References & Citations
- Internet Engineering Task Force (IETF). (2015). Domain-based Message Authentication, Reporting, and Conformance (DMARC) - RFC 7489. Retrieved from https://datatracker.ietf.org/doc/html/rfc7489 (accessed January 2025)
- DMARC.org. (2024). DMARC Overview. Retrieved from https://dmarc.org/overview/ (accessed January 2025)
- Google. (2024). Email sender guidelines. Retrieved from https://support.google.com/mail/answer/81126 (accessed January 2025)
Note: These citations are provided for informational and educational purposes. Always verify information with the original sources and consult with qualified professionals for specific advice related to your situation.
Key Security Terms
Understand the essential concepts behind this tool
DMARC (Domain-based Message Authentication, Reporting, and Conformance)
Email validation system that builds on SPF and DKIM to prevent email spoofing and provide reporting on email authentication failures.
SPF (Sender Policy Framework)
Email authentication method that specifies which mail servers are authorized to send email on behalf of your domain.
DKIM (DomainKeys Identified Mail)
Email authentication method that uses cryptographic signatures to verify that email content has not been tampered with in transit.
Frequently Asked Questions
Common questions about the DMARC Generator
DMARC (Domain-based Message Authentication, Reporting and Conformance) DNS TXT record defines how to handle emails failing SPF/DKIM authentication. Format: _dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:[email protected]". Tags: p (policy), rua (aggregate reports), ruf (forensic reports), pct (percentage), adkim/aspf (alignment). Protects against spoofing, provides visibility into email authentication failures.
Start with p=none (monitor only) for 2-4 weeks. Review aggregate reports to identify legitimate senders and authentication issues. Fix issues, then upgrade to p=quarantine (spam folder) for another month. Finally, set p=reject (block) for maximum protection. Aggressive timeline: p=reject immediately if confident in SPF/DKIM setup. Use pct=10 to test policies on 10% of email before full rollout. Monitor continuously.
DMARC aggregate reports (rua) are daily XML files showing authentication results for your domain. Contains: sending IPs, SPF/DKIM/DMARC results, message volume, alignment status. Sent to rua= email addresses. Use parsers (dmarcian, Postmark, PowerDMARC) to analyze. Identifies: legitimate servers needing SPF includes, spoofing attempts, misconfigured authentication. Essential for policy enforcement. Enable reports before enforcing strict policies.
Create TXT record at _dmarc.yourdomain.com with generated DMARC policy. Example: _dmarc.example.com TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]". DNS propagation takes 1-48 hours. Verify: dig TXT _dmarc.example.com or use online validators. Subdomain policy: use sp= tag or separate _dmarc record per subdomain. Update TTL to 300 for testing, increase to 3600+ for production. Monitor reports after deployment.
DMARC alignment ensures From: header domain matches authenticated domain. Two types: SPF alignment (From vs Return-Path domain), DKIM alignment (From vs DKIM d= domain). Modes: relaxed (subdomains allowed) or strict (exact match). Example: email from [email protected] with SPF authenticated @mail.example.com - relaxed passes, strict fails. Set with aspf=/adkim= tags. Strict mode prevents subdomain spoofing but requires careful configuration.
Forensic reports (ruf) provide individual email samples failing authentication. Contains full headers and redacted body. Privacy concerns: often disabled by receivers. Enable: ruf=mailto:[email protected] in DMARC record. Use for: debugging specific failures, investigating spoofing attempts, validating authentication setup. Format: ruf=mailto:[email protected]; fo=1:d:s (failure options). Store securely - contains email metadata. Consider data protection regulations (GDPR).
Percentage tag (pct) applies DMARC policy to percentage of failing emails. Example: pct=25 applies policy to 25% of failures, rest get p=none treatment. Use for: gradual policy rollout, testing p=reject impact, limiting false positives. Range: 0-100. Default: 100 (all emails). Strategy: start pct=10 with p=quarantine, monitor impact, increase gradually to pct=100. Remove pct tag once at 100. No effect on reporting - all failures reported.
Subdomain policy: add sp= tag for subdomain default policy. Example: v=DMARC1; p=reject; sp=quarantine (strict for root, quarantine for subdomains). Or create specific _dmarc records per subdomain. Wildcard: create _dmarc.*.example.com if DNS provider supports. Unused subdomains: set sp=reject to prevent abuse. Organizational domain policy applies if no subdomain DMARC record exists. Test with email from subdomain before enforcing.