DMARC record examples, explained tag by tag

DMARC is a single TXT record, but its tags are easy to get wrong, and the standard changed in May 2026. If you're new to it, start with what DMARC is and how it works. This guide explains every tag in RFC 9989, shows what changed from RFC 7489, and gives copy-paste records for each stage of a rollout.

What does a DMARC record look like?

A DMARC record is a TXT record published at _dmarc. in front of your domain. For example.com, the name is _dmarc.example.com:

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

In most DNS editors you enter only _dmarc as the name; our GoDaddy and Namecheap guides show the exact screens.

The rules are short:

• v=DMARC1 must come first, exactly like that. If it's missing, misspelled or not first, receivers ignore the whole record (RFC 9989, section 4.7).
• Tags are name=value pairs separated by semicolons. Order doesn't matter after v.
• Publish one DMARC record per name. Two records at _dmarc.example.com is an error.
• Unknown tags must be ignored. A typo in a tag name won't break the record, but it won't do anything either.

DMARC itself checks one thing: did SPF or DKIM pass for a domain that aligns with the visible From address? If you need a refresher on how the three fit together, read SPF vs DKIM vs DMARC first.

What does each DMARC tag mean?

This is the full set of tags in RFC 9989. Anything else, including pct, rf and ri, is no longer part of the standard.

p: the policy

p tells receivers what you want done with mail that uses your domain and fails DMARC:

• none: no preference. Receivers deliver as normal and, if you ask, send reports.
• quarantine: the mail is suspicious. In practice, it goes to junk or a quarantine.
• reject: failure is a clear sign the mail isn't yours. Receivers may refuse it during the SMTP conversation.

If a record has no valid p tag, RFC 9989 treats it as p=none only when it also has a valid rua address; otherwise receivers apply no DMARC processing (section 4.10.1). Don't rely on that; write it out.

sp and np: subdomains

sp applies to subdomains that exist, such as news.example.com. np applies to subdomains that don't exist in DNS. Attackers like invented subdomains such as invoices.example.com, because there's no record there to stop them.

The inheritance runs like this: np falls back to sp, and sp falls back to p. So p=reject alone already covers both. The extra tags matter when you want them to differ, for example p=quarantine; np=reject while you're still testing the main domain.

sp is ignored if you put it in a record published on a subdomain.

rua and ruf: reports

rua asks for aggregate reports: daily (or more frequent) XML summaries of who sent mail as your domain and whether it passed. The format is now defined in RFC 9990. Receivers that send reports must support mailto: addresses. You can list several, separated by commas.

If the reporting address is on a different domain, that domain must agree to receive the reports. It does that by publishing a record such as:

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

ruf asks for failure reports about individual messages, now defined in RFC 9991. These can contain message content and personal data, and many large receivers don't send them. Outlook.com, for example, says it sends aggregate reports but has no plans to send failure reports.

fo: failure report options

fo only matters if ruf is present:

• 0 (default): report when SPF and DKIM both fail to give an aligned pass.
• 1: report when either one fails to give an aligned pass.
• d: report any DKIM signature that failed, aligned or not.
• s: report any SPF failure, aligned or not.

Combine with colons, for example fo=1:d. 0 and 1 can't be used together.

adkim and aspf: alignment

Relaxed alignment (r, the default) accepts any domain under the same organizational domain, so a DKIM signature from mail.example.com aligns with From example.com. Strict (s) requires an exact match. Most domains should leave both relaxed. Strict alignment breaks the common pattern of sending tools that sign or bounce from a subdomain.

t: test mode

t=y asks receivers to apply your policy one level down. With p=quarantine; t=y, failing mail is treated as none. With p=reject; t=y, it's treated as quarantine. It doesn't change reporting, and it has no effect when the policy is already none.

psd: public suffix domains

psd=y is for operators of public suffixes, such as a country-code registry. Regular businesses should leave it out. You might set psd=n to state that your domain is the top of its own organizational tree, but the default (u) works for almost everyone.

What changed in RFC 9989?

RFC 9989 was published in May 2026. It replaces RFC 7489, which was an Informational document from 2015, and RFC 9091, which defined public suffix domain DMARC as an experiment. DMARC is now a Standards Track protocol. The practical changes are listed in Appendix C:

Why was pct dropped? Appendix A.6 explains that receivers applied values between 1 and 99 inconsistently. Only 0 and 100 worked reliably, and pct=0 had become a signal for mailing lists to rewrite the From header. The new t tag keeps that behavior under a clearer name: t=y corresponds to pct=0, and t=n to pct=100.

Should I remove pct from my record?

You don't have to rush. RFC 9989 receivers ignore unknown tags, so pct=100 does nothing harmful. But a value like pct=25 is now meaningless to updated receivers. They'll apply the full policy to everything.

Not every receiver updates at once. Microsoft's header documentation still lists pct.quarantine and pct.reject actions, which shows that pct-based handling is in use there. Under RFC 7489, mail not selected by pct was handled one level down: reject became quarantine, quarantine became normal handling. That's the same result as t=y. Some domain owners add pct=0 next to t=y so older receivers hold back too. Our staged records below use t=y alone, so treat stage 2 as real enforcement at receivers that haven't updated.

Which DMARC record should you use at each stage?

Replace example.com and the report address with your own. Lower the TTL to a few minutes a day before each change, so you can roll back quickly.

Stage 1: monitoring

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

Nothing changes for your mail. You start receiving aggregate reports. Stay here until every legitimate service passes aligned SPF or DKIM. The staged plan in moving DMARC from p=none to p=reject covers how to read the reports.

Stage 2: quarantine in test mode

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

Updated receivers treat failures as none. Older receivers ignore t and may quarantine, so expect some real enforcement. Stay here at least a month. Use this stage to watch for intermediaries that rewrite your From header. This stage is optional.

Stage 3: quarantine

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

Failing mail goes to junk at receivers that enforce DMARC.

Stage 4: reject, with subdomains covered

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

sp and np are redundant here because they inherit p, but writing them out makes your intent obvious to whoever edits the record next.

Main domain enforcing, one subdomain still testing

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

The subdomain's own record wins for news.example.com.

A domain that never sends email

_dmarc.example.org.  TXT  "v=DMARC1; p=reject"
example.org.         TXT  "v=spf1 -all"
example.org.         MX   0 .

Parked and defensive domains need no rollout. Pair DMARC with an SPF record that authorizes nothing and a Null MX.

Sending reports to an outside service

_dmarc.example.com.                          TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com,mailto:id123@reports.example.net"
example.com._report._dmarc.reports.example.net.  TXT  "v=DMARC1"

The second record is published by the report service, not by you. Without it, receivers following RFC 9990 won't send reports to that address.

What are the most common DMARC record mistakes?

How common is it to stop at monitoring? In our scan of the Tranco top 1,000 domains in October 2026, 26.5% published no DMARC record and another 11.7% published p=none. Counting one invalid record, 38.3% of these large sites don't enforce DMARC.

Next steps

1. Check your current record with the DMARC Checker. It flags a missing or duplicate record, a pct below 100, and outside report addresses that haven't been authorized.
2. If you have no record, publish the stage 1 example today with a mailbox you'll actually read. The DMARC Record Generator builds it for you.
3. Confirm your senders pass: run the SPF Checker and DKIM Checker.
4. Replace any pct value other than 0 or 100 with t=y while you test.
5. If you send in bulk, check the Gmail, Yahoo and Microsoft bulk sender requirements, which set p=none as the minimum.

DMARC protects your domain in other people's inboxes. For mail arriving at yours, an inbound filter such as iBlockSpam screens for spam, phishing and spoofing before delivery; see how it works.

After you publish a record, the Free Domain Watch can watch it for you: it checks your DMARC, SPF, MX and MTA-STS records weekly and alerts you to changes. To have the aggregate reports read for you as well, see iBlockSpam's DMARC monitoring.

Browse our other SPF, DKIM and DMARC guides.