A DMARC record is a DNS TXT entry published at _dmarc.yourdomain.com that defines how receiving mail servers should handle messages failing SPF and DKIM authentication. Writing this record manually requires understanding multiple interrelated tags and their implications. The InboxTooling DMARC Record Generator builds a correctly formatted, RFC 7489-compliant record based on your specific requirements.
How the Generator Works
The tool presents each DMARC tag as a configurable option and assembles the final TXT record value.
Configurable Tags
Policy (p=) -- Required. Controls how receiving servers treat messages that fail both SPF and DKIM alignment:
none: Take no action. Messages are delivered normally, but aggregate reports are generated. Use this during the monitoring phase.quarantine: Route failing messages to the recipient's spam or junk folder.reject: Instruct the receiving server to reject failing messages at the SMTP level. This is the strongest protection against domain spoofing.
Subdomain Policy (sp=) -- Optional. Applies a separate policy to subdomains. If omitted, subdomains inherit the p= value. Organizations that send mail from subdomains (e.g., marketing.example.com) should set this explicitly.
DKIM Alignment (adkim=) -- Choose r (relaxed) or s (strict). Relaxed allows a subdomain of the d= domain in the DKIM signature to align with the From: header domain. Strict requires an exact match. Default is relaxed.
SPF Alignment (aspf=) -- Choose r (relaxed) or s (strict). Relaxed allows the RFC5321.MailFrom domain to be a subdomain of the From: header domain. Strict requires an exact match. Default is relaxed.
Percentage (pct=) -- A value from 1 to 100 specifying what fraction of failing messages the policy applies to. Start low (e.g., pct=10) when transitioning from none to quarantine or reject, then increase as you gain confidence.
Aggregate Reports (rua=) -- One or more mailto: URIs that receive daily XML aggregate reports. These reports show which IPs are sending mail using your domain, whether authentication passed, and how many messages were processed. This is your primary visibility mechanism.
Forensic Reports (ruf=) -- One or more mailto: URIs for failure reports on individual messages. Not all providers send forensic reports (Gmail does not), but they can be useful for debugging specific authentication failures.
Report Format (rf=) -- Specifies the forensic report format. The default and most common value is afrf (Authentication Failure Reporting Format, RFC 6591).
Failure Reporting Options (fo=) -- Controls when forensic reports are generated:
0: Report if both SPF and DKIM fail (default).1: Report if either SPF or DKIM fails. Recommended for comprehensive monitoring.d: Report on DKIM failure only.s: Report on SPF failure only.
Generated Output
The tool produces a record like:
v=DMARC1; p=quarantine; sp=none; adkim=r; aspf=r; pct=25; rua=mailto:[email protected]; fo=1
Publish this as a TXT record at _dmarc.yourdomain.com in your DNS zone.
Recommended Deployment Strategy
Phase 1: Monitor
Start with p=none and a valid rua= address. Collect reports for at least two weeks to identify all legitimate sending sources. Review the reports to confirm that SPF and DKIM pass and align for every authorized sender.
Phase 2: Quarantine
Move to p=quarantine; pct=10 and increase the percentage over several weeks. Monitor aggregate reports for any legitimate mail being quarantined.
Phase 3: Reject
Once you are confident all legitimate senders authenticate correctly, set p=reject; pct=100. This provides full protection against exact-domain spoofing and is a prerequisite for BIMI adoption.
After Publishing
Validate your record immediately using the DMARC Analyze tool. Confirm that the record resolves correctly and all tags parse without errors. Continue to monitor aggregate reports, particularly after adding new sending services or making DNS changes.
FAQ
How do I create a DMARC record for my domain?
Use the DMARC Generator to build a valid record. Select your desired policy, configure alignment and reporting options, and the tool produces a TXT record value ready to publish. Add this value as a TXT record at _dmarc.yourdomain.com in your DNS zone. Make sure you already have SPF and DKIM configured before deploying DMARC.
What DMARC policy should I start with?
Start with p=none. This policy tells receiving servers to deliver all mail normally regardless of authentication results, while still generating aggregate reports sent to your rua address. The monitoring phase lets you identify all legitimate sending sources and fix any SPF or DKIM misalignment before enforcing a stricter policy. The DMARC Generator makes it easy to set p=none with reporting enabled as your initial configuration.
What is a DMARC rua address and why do I need one?
The rua tag specifies one or more email addresses (in mailto: URI format) that receive daily XML aggregate reports from receiving mail servers. These reports show which IP addresses are sending mail using your domain, whether SPF and DKIM authentication passed, and how the DMARC policy was applied. Without a rua address, you have no visibility into your domain's email traffic, making it impossible to identify unauthorized senders or diagnose authentication failures.
How do I move from p=none to p=reject?
Transition gradually using the pct tag. After monitoring with p=none for at least two weeks and confirming all legitimate senders pass authentication, move to p=quarantine; pct=10 to apply the policy to only 10% of failing messages. Increase the percentage over several weeks while watching your aggregate reports for any legitimate mail being quarantined. Once you reach pct=100 with no issues, switch to p=reject for full spoofing protection. Use the DMARC Generator to rebuild your record at each stage.
Do I need separate DMARC records for subdomains?
No, subdomains inherit the parent domain's DMARC policy by default. However, if your subdomains have different sending requirements, you can use the sp= tag to set a separate subdomain policy, or publish individual DMARC records at _dmarc.subdomain.yourdomain.com. For example, you might enforce p=reject on your root domain while setting sp=none for subdomains that are still being configured.
Stay on top of your email authentication. Sign up for the InboxTooling newsletter for deliverability tips, tool updates, and best practices.