DMARC Record Generator
Built on the 2026 Tag Set, With Reports That Arrive

What This Generator Builds, and What It Checks

It produces one TXT record for the host name _dmarc.yourdomain.com, using only the eleven tags RFC 9989 defines. If you enter your domain it also does three things no form alone can do: it reads the record you already publish, it checks live whether the domain receiving your reports has authorised you to send them, and before it hands you an enforcing policy it confirms the domain has something to authenticate with.

The thing worth knowing before you start is that the standard changed recently. RFC 9989 was published in May 2026 and obsoletes RFC 7489, which had governed DMARC since 2015. Three tags were removed outright — pct, rf and ri — and three were added: np, psd and t. Most generators have not caught up, which means a record built this month can arrive already out of date.

Why a mailbox provider told you to publish one

Most people arrive at a page like this because Google, Microsoft or Yahoo asked them to, and their published requirements differ enough to be worth reading once. Google asks every sender for SPF or DKIM, and for senders above 5,000 messages a day to Gmail it asks for SPF and DKIM, a DMARC record, and a From address aligned with one of them — in force since 1 February 2024. Microsoft is stricter on the same threshold to its consumer services: both checks must pass, not either. Its enforcement moved from junk-foldering in May 2025 to outright rejection, with a documented 550 5.7.515 bounce. Yahoo asks bulk senders for both plus a DMARC record at p=none, and deliberately publishes no volume number at all — so treat any threshold you see quoted for Yahoo as somebody’s guess.

The practical consequence is that the record this page produces by default — p=none with a report address — already satisfies the DMARC half of all three. Nothing about enforcement is required to clear the gate.

DMARC itself is the layer that tells receivers what to do when a message claiming to be from your domain fails authentication, and where to send the evidence. If you want the mechanics — how alignment is evaluated, what the tree walk replaced, what a receiver does with each result — that is a different job from building the record, and it lives on our DMARC checker rather than here. This page assumes you know roughly what you want and need the string. Deliverability sits downstream of sender reputation more broadly, which the guide to IP reputation scores covers end to end.

How to Use the DMARC Record Generator

1. Enter your domain. The name your mail comes from — example.com, not _dmarc.example.com and not a URL. This is optional, but without it nothing can be checked against real DNS.
2. Import what you publish. If you already have a record, the Import button reads _dmarc.yourdomain.com and loads it into the form, naming any tag the current standard has removed so you can see exactly what changed.
3. Choose a policy. If this is your first record, leave it on none. It is not a weak setting; it is the monitoring setting, and skipping it is how legitimate mail disappears.
4. Add a report address. Aggregate reports are the ones that matter. Use a mailbox somebody actually opens, or a reporting service if the raw XML is not something you want to read.
5. Check the second record. If your report address is on another domain, the builder prints the authorisation record that domain has to publish. Get it added before you publish yours, not after.
6. Copy and publish. Host _dmarc, type TXT, the whole string as the value.

If SPF is not sorted yet, do it first — the SPF record generator will also tell you whether your record is inside the ten-lookup limit, which is the single most common reason SPF silently stops working after a provider change.

Where Your Reports Go, and the Second Record Almost Nobody Publishes

This is the part that costs people months. You publish a correct DMARC record, you point rua at your reporting vendor, and nothing ever arrives. The record validates on every checker you try. Nothing bounces. There is no error anywhere to search for.

The cause is a rule that lives in a different document from the one most people read. RFC 9990 §4, “Verifying External Destinations”, says that when a report address sits on a domain other than the one publishing the policy, the receiving domain has to consent — and it consents by publishing a TXT record of its own:

Without it, the specification does not say reports are unreliable. Its wording is that the URI “MUST be ignored by the Mail Receiver generating the report”. A wildcard at *._report._dmarc.vendor.example is allowed and authorises every domain at once, though in practice it is rare: in the 239 external report destinations we checked, every single authorisation we found was an exact per-domain record and none was a wildcard.

Two reasons this matters more than its obscurity suggests. First, it is not an edge case — 150 of the 195 domains in that survey sent reports to at least one outside domain, which is most people who have set DMARC up at all. Second, none of the eight page-1 DMARC generators we could read mentions it. They will all hand you a record with an external rua and say nothing.

You can list more than one address, and plenty of people do: send a copy to your reporting vendor and a copy to a mailbox you control, so you are not locked out of your own data if the vendor relationship ends. Of the domains we surveyed, 48 used two destinations and six used three or four. Each one is a separate URI in the same rua value, separated by commas — and each one on an outside domain needs its own authorisation record.

The reports themselves are worth the trouble. An aggregate report is an XML summary — RFC 9990 describes the feedback as “daily (or more frequent)” — of every IP that sent mail claiming to be your domain, what passed, and what did not — which is how you find the ticketing system nobody remembered was sending invoices. If the wider picture of why your mail lands where it lands is the actual question, the guide to improving a bad IP reputation score sits alongside this one.

Choosing p, sp and np: What Each One Does to Your Mail

One record carries up to three policies, and they apply to three different classes of name. The domain itself always uses p. A subdomain that exists uses sp if you set it, otherwise it falls back to p. A subdomain that has never existed uses np if you set it, then sp, then p. The results panel above spells this out for whatever you have built, because the inheritance is the part people get wrong.

Start at none, and stay there until the reports are boring

p=none asks receivers to change nothing and send you reports anyway. RFC 9989 puts a number on how long that should last: a domain intending to reach p=reject should get there “by publishing ‘p=none’ for at least a month, followed by publishing ‘p=quarantine’ for an equally long period of time”. The calendar is less important than the condition: move on when you can name every sender in the reports. Most organisations discover two or three they had forgotten, and those are exactly the ones that break on the day you enforce.

np is free protection, and nobody is using it

Spoofers do not need a subdomain to exist. billing.yourdomain.com resolving to nothing does not stop a message claiming to come from it, and under the old standard that name inherited whatever sp or p said — usually none, during the months you are monitoring. Setting np=reject closes that while the rest of your rollout proceeds at its own pace, and it costs nothing if no such name sends mail. Adoption in our survey was zero out of 195.

Do not publish reject before DKIM signs everything

RFC 9989 §7.4 is unusually direct: a domain publishing p=reject “MUST NOT rely solely on SPF to secure a DMARC pass and MUST apply valid DKIM signatures”. The reason is forwarding. SPF authenticates the server that connected, so a mailing list or a forwarded message fails it by design; a DKIM signature travels with the message and survives. Publishing reject on a domain where only SPF works means every forwarded message is refused. The builder checks for a key before it hands you an enforcing record, but a proper look at what you have signed — and at what key length — belongs on the DKIM record checker.

Domains that send no mail at all

A domain that never sends email is the easiest DMARC decision you will make, and the one most often left undone. Publish v=DMARC1; p=reject; np=reject with a report address and you are finished: there is no legitimate mail to break, so enforcement costs you nothing and every forged message from that name fails outright.

More names qualify than people expect. The domain you registered defensively so a competitor could not have it. The old one you now redirect to the current site. The country variants bought for a launch that never happened. A subdomain that exists for a website rather than for mail. Each of those is a usable From address to anyone who notices it is unprotected, and each is spoofable while the domain you actually care about sits locked down.

Pair it with an SPF record of v=spf1 -all on the same name, which says the same thing about the envelope. DMARC handles the visible From address; SPF handles the connection. Neither covers the other, and a parked domain deserves both.

Every DMARC Tag, and Why Most Records Should Not Use Them

RFC 9989 defines eleven tags in total. A correct record uses two or three of them. In the 195 published records we surveyed, the median carried five and the shortest working ones carried two — there is no prize for filling in every field a form offers you.

Three tags that are no longer valid

pct, rf and ri were removed by RFC 9989, and the IANA DMARC tag registry now lists all three as historic against RFC 7489, while the other eleven are active against RFC 9989. pct is the one you will still see everywhere. It applied your policy to a percentage of mail, and the only value in wide use was the extreme one: of the 77 records carrying it in our survey, every single one said pct=100, which was already the default. The t tag now covers the testing case, and nothing at all covers a partial value like pct=50. Leaving them in an existing record is not urgent, because receivers ignore tags they do not recognise; this builder simply will not write new ones.

Failure reports are not the useful half

RFC 9991, the failure-reporting specification, is blunt about how much of this actually happens: “many large-scale providers limit or entirely disable the generation of failure reports, preferring to rely on aggregate reports”. It is equally blunt about the contents — they “may include PII and non-public information (NPI) … since these reports may contain message content as well as trace header fields”. That is other people’s correspondence arriving in a mailbox you now have to think about. If what you actually want is to read the authentication results on one specific message you already have, paste it into the email header analyzer instead — it is faster and involves nobody else’s data.

Publishing It, and the Host Name That Trips Everyone

Host name _dmarc, type TXT, value the whole string including v=DMARC1. The underscore is part of the name and is correct; panels that reject it are being unhelpful rather than accurate.

Almost every failed first attempt is the host field. Some control panels want just _dmarc and append the domain themselves. Others want the fully qualified _dmarc.example.com. Enter the wrong one and you create _dmarc.example.com.example.com, which resolves to nothing at all — and the panel will show it back to you looking perfectly correct.

1. Publish the record at _dmarc with type TXT.
2. Look it up directly rather than trusting the panel’s preview. A DNS record lookup on _dmarc.yourdomain.com shows you what the world actually sees.
3. Read it back the way a receiver does, with the DMARC record checker, which resolves the policy for the domain, for existing subdomains and for names that do not exist, and verifies the report destinations independently of this page.
4. Wait for reports. Aggregate feedback is daily or thereabouts, so give it a day or two before concluding anything is wrong.

If the record still reads as missing minutes after you published it, the usual culprit is negative caching rather than propagation. RFC 2308 derives how long a resolver keeps a “this name does not exist” answer from your zone’s SOA record — so if anything looked the name up before you published, that absence is cached for a while. It is also why lowering the TTL a day before a change is worth the small amount of planning.

DMARC Record Generator: Frequently Asked Questions