DMARC Record Syntax and Tags Explained

A DMARC record is a DNS TXT record published at _dmarc. plus your domain, made of tag=value pairs separated by semicolons. Only v=DMARC1 is strictly required, and it must come first. In practice you'll set p (your policy) and rua (where aggregate reports go), and leave most of the other tags at their defaults.

A typical record for example.com, published at _dmarc.example.com:

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com

If you want the background on what DMARC does before getting into syntax, start with what DMARC is.

The rules of the format

• Where it lives: a TXT record at _dmarc.example.com. Not on the domain itself, not at dmarc.example.com.
• v=DMARC1 first, exactly. If it isn't the first tag, is missing, or is spelled differently, receivers ignore the whole record.
• One record per name. If a receiver finds more than one DMARC record at the same name, it discards them all and treats the domain as having none.
• Unknown tags are ignored. A tag the receiver doesn't recognize doesn't break the record; it's skipped.
• Semicolons separate tags. A trailing semicolon is fine. Spaces around them are fine.
• Long records can be split into multiple quoted strings in one TXT record. Receivers join them in order before parsing.

Every tag, explained

The DMARC standard was revised in May 2026. RFC 9989 replaced RFC 7489, added some tags and retired others. The table reflects the current IANA tag registry.

p: the policy

The tag that matters most. none means monitor only, quarantine asks receivers to treat failing mail as suspicious (usually the spam folder), and reject asks them to refuse it. Choosing between them, and moving from one to the next safely, is its own topic: see DMARC policy: none vs quarantine vs reject.

Under RFC 9989, p is "recommended" rather than required, and a valid record without it is treated as p=none. Don't rely on that. Always set p explicitly. Gmail and Yahoo require bulk senders to publish a DMARC record, and p=none meets that requirement.

sp and np: subdomains

If news.example.com has no DMARC record of its own, receivers fall back to the record on example.com. sp sets the policy they apply to subdomains like that. If you leave it out, they use p.

np is narrower: it covers subdomains that don't exist in DNS at all, like invoices-secure.example.com invented by a phisher. Setting np=reject lets you lock down made-up subdomains even while your real ones are still at none.

rua and ruf: reports

rua is where receivers send aggregate reports: daily XML summaries of every IP sending with your domain in the From line and whether it passed. This is the most useful thing DMARC gives you. You can list more than one address, separated by commas.

ruf asks for failure reports, which are per-message and can include message content. Fewer receivers send them. Reading both kinds is covered in how to read DMARC reports.

Sending reports to another domain. If your rua points outside your own domain, say to a reporting service at reports.example.net, receivers check that the other domain agreed to accept them. That domain must publish a TXT record at example.com._report._dmarc.reports.example.net containing v=DMARC1. Reporting services usually do this for you, but if reports never arrive, it's one of the first things to check.

You may still see a size suffix on old records, like mailto:dmarc@example.com!10m. RFC 9989 treats it as obsolete and tells reporters to ignore it. It's harmless but does nothing.

adkim and aspf: alignment

Alignment is how DMARC ties SPF and DKIM to the visible From domain.

• Relaxed (r, the default): the domains need to share an organizational domain. mail.example.com aligns with example.com.
• Strict (s): the domains must match exactly.

Leave these at relaxed unless you have a specific reason. Strict alignment breaks common setups like an ESP signing as em.example.com for mail from example.com, and buys little extra protection. If alignment is why mail is failing, see DMARC fail.

fo: failure reporting options

Only matters if you set ruf.

• 0 (default): report when all mechanisms fail to produce an aligned pass.
• 1: report when any mechanism fails to produce an aligned pass.
• d: report when DKIM fails, aligned or not.
• s: report when SPF fails, aligned or not.

You can combine them with colons (fo=1:d), except 0 and 1, which are mutually exclusive.

t: test mode

New in RFC 9989. With t=y, receivers apply your policy one level lower: p=reject; t=y is treated like quarantine, and p=quarantine; t=y like none. It doesn't change reporting. It's meant for the step before full enforcement, when you want reports to reflect the real policy but aren't ready for its full effect.

psd

Used by public suffix operators (registries for things like country-code domains) and for the DNS tree walk that finds a domain's organizational domain. Unless you run a registry, you won't set it.

Retired tags

The IANA registry now marks three RFC 7489 tags as historic:

• pct asked receivers to apply the policy to only a percentage of failing mail. t replaces its main use, a staged step toward enforcement.
• rf set the failure report format. RFC 7489 only ever defined one (afrf).
• ri requested a reporting interval in seconds. Aggregate reports typically cover one UTC day regardless.

Receivers ignore unknown tags, so a record with pct=100 won't break. But when you next edit it, take them out, and use t=y instead of a low pct for a test phase. Receivers that haven't updated to RFC 9989 may not act on t or np yet.

Example records

Monitoring, with reports:

v=DMARC1; p=none; rua=mailto:dmarc@example.com

Enforcement on the main domain, with made-up subdomains rejected:

v=DMARC1; p=quarantine; np=reject; rua=mailto:dmarc@example.com

Full enforcement, reports to a third-party service:

v=DMARC1; p=reject; rua=mailto:dmarc@example.com,mailto:a1b2@reports.example.net

Domain that never sends mail:

v=DMARC1; p=reject

Pair that last one with an SPF record of v=spf1 -all. See what an SPF record is.

How to check yours

The DMARC record generator builds a valid record from a few choices, and the SPF, DKIM and DMARC checker shows whether the one you've published parses and what policy receivers will see. After publishing, send a test to a mailbox you control and look for dmarc=pass in the Authentication-Results header with the header analyzer.

When to get help

If you're about to move to quarantine or reject and aren't sure every legitimate sender passes, or your reports show failures you can't place, it's worth a second look before you tighten the policy.

FAQ

What's the minimum valid DMARC record?

v=DMARC1; p=none is valid, but without rua you get no reports, which defeats the purpose. Add a rua address.

Do I still need pct=100 in my record?

No. pct is retired under RFC 9989, and 100 was always the default anyway. Removing it changes nothing.

Why aren't I receiving DMARC reports?

Usually one of three things: no rua tag, a typo in the address, or a rua pointing to another domain that hasn't published the _report._dmarc authorization record. It can also take a day or two for the first reports to arrive.

Can I put DMARC on a subdomain?

Yes. Publish a record at _dmarc.sub.example.com and it applies to that subdomain instead of the parent's sp policy.