DMARC record generator

By Jarod Capella · Updated November 14, 2026 · 2 min read

Fill in the fields, copy the result, paste it into a TXT record in your DNS zone. Nothing is sent: the calculation runs in your browser.

Result

Name of the TXT record:

What each tag does

v=DMARC1: required, must come first, followed by p.
p: none, quarantine or reject. Always set it: without a valid p, the receiver acts as if p=none were published when rua holds a valid address, and applies no DMARC treatment otherwise (RFC 9989, section 4.10.1).
sp: policy for subdomains. If absent, the value of p applies.
pct: integer from 0 to 100, default 100, in RFC 7489. RFC 9989 (May 2026) removes it: according to its appendix A.6, values other than 0 and 100 were applied inaccurately and differently from one receiver to another. The generator warns you if you pick another value.
t: test mode, created by RFC 9989. t=y asks the receiver to apply the policy one step lower (reject treated as quarantine, quarantine as none); it replaces pct=0. When you set pct=0, the generator adds t=y: a receiver still on RFC 7489 ignores it, since both texts require unknown tags to be ignored.
rua: mailto: addresses that receive aggregate reports, separated by commas.
adkim, aspf: r (relaxed) or s (strict), default r.

Before you publish

Start with p=none and a rua address, read the reports for a few weeks, then tighten the policy. If the report address is on a domain other than yours, the receiving domain must publish an authorisation record, otherwise receivers ignore the address (RFC 7489, section 7.1).

Caveat: RFC 7489 was declared obsolete and replaced by RFC 9989, 9990 and 9991. Both texts were read in plain-text form on rfc-editor.org on 2026-11-05 (RFC 7489 section 6.3, RFC 9989 sections 4.7, 4.10.1 and appendix A.6). RFC 9989 changes other points than the ones described here: read it before any sensitive deployment.