DMARC Tags and Record Syntax
A DMARC record is one DNS TXT record, published at _dmarc.yourdomain.com, made of tag=value pairs separated by semicolons. This reference explains what every tag does, its allowed values and defaults, what changed in DMARCbis, and gives six complete records you can copy.
By Stephen Williams · Updated
Anatomy of a DMARC record
Here is a typical record, broken down tag by tag:
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; adkim=r; aspf=rv=DMARC1identifies the record as DMARC. It must be the first tag, exactly as written.p=quarantineasks receivers to treat mail that fails DMARC as suspicious (usually the spam folder).rua=mailto:dmarc-reports@example.comis where receivers send daily aggregate reports.adkim=randaspf=rrequest relaxed alignment for DKIM and SPF (the default, so they can be omitted).
Tags are separated by semicolons; spaces around them are allowed. The record name is always _dmarc under the domain it protects, and a domain must have exactly one DMARC record. Receivers ignore tags they don't recognize, which is why newer tags can be added without breaking older software.
DMARC tag reference
The tags below are defined in RFC 7489, the DMARC specification most receivers implement today. The last three rows are additions from DMARCbis (RFC 9989).
| Tag | Values | Default | What it does |
|---|---|---|---|
v | DMARC1 | Required | Version. Must be the first tag in the record. |
p | none, quarantine, reject | Required | Policy for mail that fails DMARC on this domain: monitor only, treat as suspicious, or refuse. |
sp | none, quarantine, reject | Same as p | Policy for subdomains (for example news.example.com) that don't publish their own DMARC record. |
rua | mailto: URIs, comma-separated | None | Where to send aggregate reports: daily XML summaries of who sent mail as your domain and whether it passed. |
ruf | mailto: URIs, comma-separated | None | Where to send failure (forensic) reports about individual failing messages. Many large receivers don't send them. |
adkim | r (relaxed), s (strict) | r | How closely the DKIM signing domain (d=) must match the From domain. |
aspf | r (relaxed), s (strict) | r | How closely the SPF-authenticated envelope domain must match the From domain. |
pct | 0-100 | 100 | Percentage of failing mail the policy applies to. Removed in DMARCbis; see below. |
fo | 0, 1, d, s (colon-separated) | 0 | When to send failure reports: 0 = SPF and DKIM both failed to align, 1 = either failed, d = DKIM failed, s = SPF failed. Only matters with ruf. |
ri | Seconds | 86400 | Requested interval between aggregate reports. Receivers generally send daily regardless. Removed in DMARCbis. |
rf | afrf | afrf | Format for failure reports. afrf is the only defined value. Removed in DMARCbis. |
np | none, quarantine, reject | Subdomain policy | DMARCbis: policy for subdomains that don't exist in DNS. |
t | y, n | n | DMARCbis: t=y marks the policy as being tested (replaces pct=0). |
psd | y, n, u | u | DMARCbis: marks a Public Suffix Domain. Only registries and similar operators use it. |
Alignment: adkim and aspf
DMARC passes when SPF or DKIM passes and the domain it authenticated aligns with the domain in the visible From address. Relaxed alignment (the default) only requires the same organizational domain; strict alignment requires an exact match.
| From address domain | Authenticated domain | Relaxed (r) | Strict (s) |
|---|---|---|---|
| example.com | example.com | Aligned | Aligned |
| example.com | mail.example.com | Aligned | Not aligned |
| news.example.com | example.com | Aligned | Not aligned |
| example.com | example.net | Not aligned | Not aligned |
Keep relaxed alignment unless you have a specific reason to tighten it: strict alignment breaks common setups such as an email platform using a bounce subdomain like bounce.example.com.
Six DMARC records you can copy
Replace example.com and the report address with your own, then publish the record as a TXT record with the host name _dmarc. Check it with the DMARC checker once it's live.
1. Start monitoring (p=none)
Collects reports without changing how your mail is handled. Every new DMARC deployment should start here.
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com2. Quarantine failing mail
The first enforcement step, once reports show your legitimate senders pass DMARC.
v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com3. Full enforcement (p=reject)
The end goal: receivers are asked to refuse mail that fails DMARC.
v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com4. Reject on the main domain, quarantine subdomains
Useful while you finish fixing senders that use subdomains of your main domain.
v=DMARC1; p=reject; sp=quarantine; rua=mailto:dmarc-reports@example.com5. Parked domain that never sends email
For domains you own but don't send email from. Pair it with the SPF record v=spf1 -all.
v=DMARC1; p=reject;6. Strict alignment with failure reports
For organizations that control every sender and want per-message failure detail from receivers that send it.
v=DMARC1; p=reject; adkim=s; aspf=s; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-failures@example.com; fo=1Prefer not to write it by hand? The DMARC record generator builds a valid record from a few questions, and the Create DMARC Record builder explains each choice as you make it.
Sending reports to another domain
If your rua or ruf address is on a different domain than the one being protected (for example a reporting service), the receiving domain must publish a TXT record authorizing it. Without it, receivers won't send the reports. For reports about example.com sent to an address at reports.example.net:
example.com._report._dmarc.reports.example.net TXT "v=DMARC1;"Most hosted DMARC reporting services publish this record for you.
DMARCbis: what changed in RFC 9989
In May 2026 the IETF published DMARCbis as RFC 9989, a Standards Track update that obsoletes RFC 7489 and RFC 9091. Aggregate and failure reporting moved into companion documents, RFC 9990 and RFC 9991. The record still starts with v=DMARC1, so existing records keep working. The tag-level changes:
- Removed:
pct,rfandri. The RFC notes that pct was usually not applied accurately for values other than 0 and 100. - Added:
np(policy for non-existent subdomains, imported from RFC 9091),t(testing flag) andpsd(public suffix domain flag). - t=y asks receivers not to apply the policy as written but to step it down one level: reject is handled like quarantine, and quarantine like none. It is the equivalent of the old
pct=0. - Organizational domain discovery now uses a DNS tree walk instead of the Public Suffix List.
Practical advice: there's nothing to rush. Drop rf and ri the next time you edit the record, don't depend on pct values between 1 and 99, and consider adding np=reject once your domain is at enforcement. Receivers are adopting RFC 9989 gradually, so a record that works for both looks like this while testing quarantine:
v=DMARC1; p=quarantine; t=y; pct=0; rua=mailto:dmarc-reports@example.comCommon DMARC syntax mistakes
- Publishing the record at the root domain instead of
_dmarc.example.com. - Leaving out
mailto:inruaorruf; the value must be a URI. - Two DMARC records for the same name, often an old one left behind. Receivers then ignore both.
- Putting
por another tag beforev=DMARC1, or misspelling the version (it'sDMARC1, with no space). - Curly "smart" quotes or stray characters pasted from a document or chat app.
- Using commas instead of semicolons between tags. Commas only separate multiple addresses inside
ruaandruf.
Sources
Frequently asked questions
Which DMARC tags are required?
Only v=DMARC1 and a policy (p=none, p=quarantine or p=reject) are needed for a working record, and v must be the first tag. Everything else is optional, but you should almost always add rua so you receive aggregate reports.
What is the difference between sp and np?
sp sets the policy for subdomains that exist, such as mail.example.com. np, added by DMARCbis (RFC 9989), sets the policy for subdomains that don't exist in DNS at all, which attackers sometimes invent for spoofing. If np is absent, the subdomain policy applies.
Is the pct tag still supported?
pct is defined in RFC 7489, which most receivers still implement, but DMARCbis (RFC 9989, May 2026) removes it because values other than 0 and 100 were rarely applied accurately. Use t=y to signal testing instead, and keep pct=0 alongside it if you also want older receivers to treat the record as a test.
Can a domain have more than one DMARC record?
No. If a receiver finds more than one DMARC record at _dmarc.yourdomain.com, it ignores them all and your domain is treated as having no DMARC policy. Combine everything into a single TXT record.