DMARC Record Generator

Enter the domain you want to protect with DMARC (e.g. example.com).

How should email providers handle messages that fail DMARC checks? Start with "none" to monitor without affecting delivery, then move to "quarantine" or "reject" once you've confirmed all legitimate senders pass.

Separate policy for subdomains (e.g. mail.example.com, app.example.com). If not set, subdomains inherit the main policy. Set this to "reject" if you don't send email from subdomains.

What percentage of failing messages should the policy apply to? Use this for gradual rollout — e.g. set to 10% when first moving to quarantine, then increase over time. 100% means the policy applies to all failing messages.

Aggregate reports are daily XML summaries showing which IPs are sending email as your domain and whether they pass or fail SPF/DKIM/DMARC. These are essential for monitoring your email ecosystem.

Optionally send aggregate reports to your own email address too. Separate multiple addresses with commas. These are in addition to the DMARC Cloud address above.

Forensic reports contain details about individual messages that failed DMARC. Note: most email providers (including Gmail and Yahoo) do not send forensic reports due to privacy concerns. They're still useful if your mail flow includes providers that do support them.

Controls when forensic failure reports are generated. The default "0" generates a report only when both SPF and DKIM fail. Setting "1" generates a report if either check fails, which gives you more visibility but more reports.

The format used for forensic failure reports. AFRF (Authentication Failure Reporting Format) is the standard and widely supported format. IODEF (Incident Object Description Exchange Format) is an alternative XML-based format used by some security tools. In practice, most providers only support AFRF.

How often aggregate reports should be sent, in seconds. The default is 86400 (24 hours). Shorter intervals give faster feedback but most large email providers only send once per day regardless of this setting.

Controls how strictly the DKIM signing domain (d= tag) must match the From header domain. "Relaxed" allows subdomains (e.g. mail.example.com signing for example.com) — this is recommended for most setups. "Strict" requires an exact domain match, which may break legitimate email if your ESP signs with a subdomain.

Controls how strictly the SPF-authenticated domain (Return-Path/envelope sender) must match the From header domain. "Relaxed" allows subdomains — this works well with most email services. "Strict" requires an exact match, which may cause issues with services that use a subdomain for bounce handling.