dotvitals

DMARC Record Generator

Build a DMARC record step by step, from monitoring to full enforcement, with reporting addresses included.

The policy is published under `_dmarc` at this exact name and applies to mail claiming to be from it. Subdomains only inherit through the subdomain policy, so a domain that sends its own mail usually wants its own record.

Fix it here

This builds the change the checks above ask for, and validates it against the same rules.

DMARC report authorisation record

The TXT record the domain receiving your DMARC reports has to publish before any report is sent — with the exact name, and a message to send whoever owns that domain.

This is the domain publishing the DMARC policy — the one the reports are about, not the one receiving them. It is the name that has to appear in the authorisation record, and the wrong name here means the reports are still refused.

About the dmarc record generator

This generator walks through every DMARC tag one decision at a time instead of requiring you to remember the record syntax from scratch: the policy level, whether subdomains should follow a different policy, alignment mode for SPF and DKIM, and where aggregate and forensic reports should be sent. It recommends p=quarantine with a reporting address rather than the p=none that older guides start with, because a record telling receivers to take no action protects nothing and is reported as a failure by this site's own DMARC checker. Where the generator has been reached from a scan, it justifies that recommendation from the domain's actual records, quoting the SPF record and the DKIM key it read back to you.

If your senders cannot be verified, or you do not yet know every service that sends as you, the monitoring stage is still available as a deliberate choice, clearly labelled as a stage that provides no protection and exists only to collect reports. A reporting address is required: without one the policy runs with no feedback, and you would never learn that a legitimate sender had started failing. The generator also produces the authorization record needed when reports go to a different domain than the one being protected, since DMARC requires that receiving domain to opt in via its own DNS record, and omitting it is a common reason external reporting silently fails.

The generator also explains what each output line actually means in plain language next to the record itself, so publishing it does not require separately looking up RFC 9989 to understand what was just created and why each tag was set the way it was. Reading that explanation alongside the record before publishing it is a good habit even for a domain owner who already understands DMARC, since it doubles as a final sanity check on exactly what is about to go live.

Common questions

Which policy should I start with?
p=quarantine with a rua reporting address, then reject once the reports confirm every legitimate sender authenticates in alignment. Start at p=none only if you cannot yet name your senders, and treat it as a dated step: it blocks nothing while it is published.
What is alignment mode?
adkim and aspf control whether a subdomain counts as aligned with the visible From domain under a relaxed match, the default, or must match it exactly under strict mode.
Can I send reports to another domain?
Yes, but that domain must publish an authorization record of its own, in the form yourdomain.com._report._dmarc.otherdomain.com, or receivers will refuse to send reports there.
Do I need a separate subdomain policy?
Only if your subdomains should be treated differently from the root domain, for example a stricter policy on a subdomain that never sends mail. Otherwise sp can be left to inherit the root policy.