Skip to content
AdminKit
Live Updated

DMARC record generator: build a _dmarc TXT record in your browser

How does this check work, and what does the result tell you?

AdminKit's DMARC record generator builds the exact _dmarc TXT record string for your chosen policy, subdomain policy, report addresses, percentage and alignment settings — entirely in your browser, with nothing sent to any server. You still need to publish the result in your DNS and confirm it there with AdminKit's live DMARC check.

Part of the Email authentication cluster — more tools, guides and terms on email authentication.

What receivers should do with mail that fails SPF/DKIM alignment.

Leave blank to let subdomains inherit p.

One or more email addresses, comma-separated. mailto: is added automatically.

Optional; less widely supported by receivers than rua.

Share of failing mail the policy applies to. Omitted from the record at 100.

Leave blank to use RFC 7489's relaxed default.

Leave blank to use RFC 7489's relaxed default.

Only affects per-message forensic reports (ruf).

TXT record for _dmarc.<your domain>
v=DMARC1; p=none

This record is built in your browser only — nothing here is sent to AdminKit or anywhere else. Publish it as a TXT record at _dmarc.<your domain>, then verify it with the live DMARC check.

What the result means

This is the record text built from the values you entered — it says nothing about what your domain currently publishes. To see what is actually live in DNS today, run AdminKit's DMARC check.

Next step

Publish the record above as a TXT record at _dmarc.<your domain>, then confirm it with the live DMARC check once DNS has propagated.

Keep this result

Copy a link to this check so you can share it or run it again later. Want a heads-up if something changes? That's early access, not a live feature yet — tell us and we'll set it up by hand.

Get alerted — early access

How it works and limits

Fill in a policy, report addresses and the other tags below and this tool assembles the exact _dmarc.<your domain> TXT record string as you type, entirely in your browser — nothing you enter is sent to AdminKit or anywhere else. Once you are happy with the result, publish it as a TXT record in your own DNS, then confirm it took effect with AdminKit’s live DMARC check, which queries DNS for real and reports back what it actually found.

What does a DMARC record actually tell receivers?

A DMARC record, published as defined in RFC 7489, tells a receiving mail server two things: what to do with a message that fails SPF or DKIM alignment (p, and optionally a separate sp for subdomains), and where to send reports about what it saw (rua for daily aggregate summaries, ruf for per-message forensic detail). DMARC.org’s overview walks through the same three pieces — policy, alignment and reporting — in plainer language than the RFC itself.

The tags this tool builds

  • p — the headline policy for the domain itself: none (monitor only), quarantine (send to spam) or reject (refuse the message outright).
  • sp — an optional separate policy for subdomains; left blank, subdomains inherit p.
  • rua / ruf — reporting addresses. rua collects aggregate (daily, summarized) reports; ruf collects forensic (individual, per-message) reports and is less widely supported by receivers.
  • pct — the percentage of failing mail the policy applies to, for a gradual rollout. Omitted from the record at its RFC-default value of 100 (see the FAQ below).
  • adkim / aspf — relaxed (r, the default) or strict (s) alignment between the visible From: domain and the domain that actually passed DKIM or SPF.
  • fo — which SPF/DKIM failure combinations trigger a forensic report, when ruf is set.

Limits

  • This tool only builds the record text. It never queries DNS and never publishes anything — you still have to add the record to your own DNS and confirm it with a live check.
  • It validates the values you enter (policy keywords, address syntax, numeric ranges) but has no way to know whether the report addresses you give it actually exist or belong to you.

For a plain-language walkthrough of what each tag means and a sensible rollout order, see the DMARC check’s own guide to reading the tags, or SPF, DKIM and DMARC explained for how DMARC fits together with the other two records. Once your record is live, AdminKit’s SPF check and DKIM check confirm the two records DMARC actually aligns against.

Frequently asked questions

Does this tool send anything to AdminKit's servers?

No — every field you fill in is read directly by your browser, and the record string is built there with plain JavaScript. Nothing you type is sent to AdminKit or anywhere else. That also means it cannot check what your domain currently publishes; for that, use AdminKit's live DMARC check, which does query DNS.

I built a record here — do I still need to do anything else?

Yes: this tool only builds the text of the record. You still have to publish it yourself as a TXT record at _dmarc.<your domain> in your DNS provider's control panel, then confirm it actually resolved correctly with AdminKit's DMARC check, which queries DNS for real.

Why is pct left out of the record when I set it to 100?

RFC 7489 §6.3 defines 100 as pct's own default when the tag is absent, so a record that applies its policy to all failing mail means exactly the same thing with or without pct=100 written out. This tool omits it at 100 to keep the record shorter; setting any value below 100 adds the tag.

What's the difference between adkim/aspf's relaxed and strict modes?

Relaxed alignment (the RFC 7489 default) accepts any subdomain match between the visible From: domain and the domain that passed SPF or DKIM — for example mail.example.com aligning with example.com. Strict alignment requires an exact match between the two domains, with no subdomain allowed either way.