Free DMARC generator tool. Create custom DMARC DNS records with monitoring and enforcement policies to prevent email spoofing.
DMARC is the final layer of email authentication that protects your domain from being used in phishing attacks.
• none: Monitor mode - collect reports only
• quarantine: Send suspicious emails to spam
• reject: Block unauthenticated emails entirely
• Start with "none" and gradually increase strictness
• Use subdomain policy (sp) for different policies
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.
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:dmarc@example.com |
| ruf | No | Forensic report destination | ruf=mailto:forensic@example.com |
| 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:dmarc-reports@example.com; ruf=mailto:dmarc-forensic@example.com; adkim=s; aspf=r; pct=100
DMARC policy progression:
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:reports@example.com". 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:dmarc@example.com". 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 newsletter@example.com 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:forensic@example.com in DMARC record. Use for: debugging specific failures, investigating spoofing attempts, validating authentication setup. Format: ruf=mailto:forensic@example.com; 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.