DMARC record builder

What this tool checks

Fill in the form and the tool writes the DMARC record to publish as a TXT record at _dmarc.example.com, following RFC 9989, the current DMARC standard that replaces RFC 7489.

• Policy (p): what receivers should do with mail that fails DMARC: none (report only), quarantine (treat as suspicious, usually the spam folder) or reject (refuse it).
• Subdomain policy (sp): the policy for subdomains without a DMARC record of their own. Left out when it is the same as p.
• Aggregate reports (rua) and failure reports (ruf): one or more addresses, with or without mailto:.
• Alignment (adkim, aspf): relaxed (the default) or strict.
• Test mode (t): t=y asks receivers to apply one policy level lower than p.
• pct: the old percentage tag, kept for older receivers if you need it.

Tags at their default value (adkim=r, aspf=r, t=n) are left out of the record to keep it short; the explanation table still lists them.

The tool then reads the domain's current DMARC record and compares it tag by tag. For report addresses in another domain, it checks that domain has published the record that authorises your reports.

What it can't see: whether your mail passes SPF or DKIM today. Read your aggregate reports, or paste a message's headers into the email header analyser.

Reading the results

The first finding is the record, ready to copy. In most DNS panels the host name is _dmarc. A domain must have only one DMARC record; with two, receivers ignore DMARC.

The What each tag means table explains every tag in your record, and marks the defaults that are not written out.

The comparison shows each tag that would change between the live record and the new one. Weakening the policy, for example from reject to none, is flagged.

Common problems and fixes

p=none with no reports

p=none changes nothing about delivery; its value is the reports. Without rua, it does nothing at all. Add an address you read, or one from a DMARC report service:

_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

When the reports show all your legitimate mail passing, move to quarantine and then reject. The guide from p=none to p=reject has the full plan.

pct below 100

RFC 9989 removed pct because receivers applied it inconsistently. Receivers that follow the new standard ignore it and apply the full policy. Only two values have a counterpart: pct=0 corresponds to t=y, and pct=100 to t=n (the default). To test a stricter policy, use test mode instead of a percentage:

_dmarc.example.com. TXT "v=DMARC1; p=reject; t=y; rua=mailto:dmarc-reports@example.com"

With t=y, receivers treat reject as quarantine and quarantine as none, and reports arrive as normal. Remove t=y once the reports look clean.

Reports to another domain

Receivers only send reports to an address outside your domain if that domain agrees, by publishing a record named after yours. For reports from example.com to reports.example.net:

example.com._report._dmarc.reports.example.net. TXT "v=DMARC1;"

DMARC report services usually publish this for every customer. The tool checks for it and says when it is missing.

Strict alignment breaks a sending service

With adkim=s or aspf=s, the DKIM or bounce domain must equal the From domain exactly. A service that signs as em.example.com then fails. Relaxed alignment is enough for most domains.

FAQ