A DMARC TXT record can be visible in DNS and still fail to express the policy its owner intended. Correct evaluation depends on the publishing name, record set, tag grammar, active registry and the receiver's implementation.
This guide uses RFC 9989 for the core protocol. Reporting formats and transport are specified separately in RFC 9990 and RFC 9991.
Publish at the correct owner name
For an ordinary domain, receivers discover DMARC policy under an applicable _dmarc name. A TXT value placed only at the domain root is not a substitute. Policy discovery can also involve fallback rules and domain-boundary processing, so do not derive the organisational domain by simply taking the last two labels.
At the selected owner name, validate the complete TXT record set. Do not assume receivers will merge two DMARC policy records. Correct duplicate or competing candidates rather than adding another record.
Start with the version tag
The record is a semicolon-separated list of tag-value pairs. The version tag is:
| Tag | Purpose | Current value rule |
|---|---|---|
| v | Identifies the DMARC record | v=DMARC1 and first in the record |
RFC 9989 retains DMARC1. Do not publish v=DMARC2.
Use the registered lower-case tag names, the exact version value DMARC1 and each tag's defined value rules. Do not rely on changing the case of a registered name to produce an equivalent recognised tag.
Understand the policy tags
| Tag | Purpose | Values or form | Default or fallback |
|---|---|---|---|
| p | Requested handling for the policy domain | none, quarantine, reject | See the conditional discovery fallback below |
| sp | Policy for applicable subdomains | none, quarantine, reject | Falls back to p when absent |
| np | Policy for non-existent subdomains in its defined scope | none, quarantine, reject | Falls back to sp, then p |
| t | Testing flag | y or n | n |
| adkim | DKIM alignment mode | r or s | r |
| aspf | SPF alignment mode | r or s | r |
| rua | Aggregate report destination list | URI list | No aggregate destination when absent |
| ruf | Failure report destination list | URI list | No failure destination when absent |
| fo | Failure-report request options | 0, 1, d or s, combined as permitted by the grammar | 0; ignored without ruf |
| psd | Public-suffix-domain indicator | u, y or n | u |
This table summarises RFC 9989 section 4.7; it is not a recommendation to publish every tag. Omit optional tags when their defined default matches the intended policy and the omission has been tested against the receivers that matter.
Read policy defaults precisely
RFC 9989 recommends p but does not make its presence mandatory. Its policy-discovery rules in section 4.10.1 specify the fallback precisely: if p is missing or invalid, or sp or np has an invalid value, the receiver continues as if p=none was retrieved only when rua contains at least one syntactically valid reporting URI. Otherwise, no DMARC processing is applied to that message.
For operational change control, make the intended policy explicit unless a reviewed use case requires otherwise. Test legacy and current fixtures if your environment depends on receivers with different implementations. Record which specification assumption supports the expected result.
These are synthetic parsing fixtures, not published records:
| Single candidate value | Current discovery interpretation |
|---|---|
| v=DMARC1; p=none; rua=mailto:reports@example.com | Explicit none policy with an aggregate reporting request |
| v=DMARC1; p=invalid; rua=mailto:reports@example.com | Invalid p with a syntactically valid rua URI: continue as p=none |
| v=DMARC1; p=invalid | Invalid p without a qualifying rua URI: no DMARC processing for the message |
The presence of a syntactically valid URI establishes the fallback condition. It does not prove that the destination is authorised where required, reachable or collecting reports.
sp applies to relevant subdomain policy discovery. np addresses non-existent subdomains under the updated specification. A domain with no MX record is not automatically a non-existent domain; DNS existence is a separate question.
The default psd=u means the domain is not a public suffix, while its organisational-domain status is determined through the DNS tree walk. An explicit psd=n states that it is the organisational domain for itself and its subdomains. psd=y identifies a public suffix domain. Omitting psd is therefore not equivalent to explicitly publishing psd=n.
The default fo=0 requests a DMARC failure report when every underlying authentication mechanism fails to produce an aligned pass. Without ruf, fo is ignored; the request also does not guarantee that a receiver will generate a report.
Use the testing flag as defined
The t tag is not a percentage. With t=y, the declared p, sp or np policy assessment is reduced by one level: reject becomes quarantine and quarantine becomes none. A declared none assessment is unchanged. The tag does not disable validation or reporting.
Receiver support must still be observed. Do not promise a uniform delivery outcome based only on the presence of t=y.
Treat alignment tags as trust decisions
adkim=s requires exact DKIM-domain alignment. adkim=r permits the applicable organisational-domain relationship. aspf works similarly for the authenticated SPF domain.
Relaxed alignment is not a textual suffix comparison and does not allow an arbitrary service domain. Strict alignment can narrow the accepted relationship, but it can also expose legitimate subdomain variation. Choose the mode from actual identity architecture rather than from a preference for stricter-looking syntax.
Configure reporting destinations deliberately
rua and ruf contain report destination URIs, commonly mailto addresses. An external destination can require destination-side authorisation. Publishing an address does not guarantee that every receiver will send a report or that the destination can safely ingest it.
Aggregate and failure reporting have distinct privacy, operational and format considerations. Validate size, access, retention, parsing and escalation. A mailbox that silently discards reports does not make the policy invalid, but it defeats the intended evidence workflow.
Avoid obsolete copy-and-paste tags
The current IANA registry is the operational reference for active parameters. pct, rf and ri are historical rather than active RFC 9989 policy controls. Do not carry them into a new record merely because they appear in an old example.
Removing an obsolete tag does not replace a deployment plan. Compare receiver behaviour, record the change and verify that current tags express the intended outcome.
Validate four layers
A dependable review checks:
- DNS owner: Is the record published at the exact applicable _dmarc name?
- Record set: Is there one coherent DMARC policy record rather than competing candidates?
- Grammar: Is v=DMARC1 first, with valid separators, names and values?
- Semantics: Do p, sp, np, t, alignment and reporting destinations represent the approved decision?
Then send representative messages. A DNS lookup proves only what was observed in DNS at that time. It does not prove that outbound mail receives an aligned pass.
Work through a synthetic record
Consider this fictional record:
| Tag | Value | Intended decision |
|---|---|---|
| v | DMARC1 | Identify the record |
| p | quarantine | Request quarantine assessment for failure |
| sp | reject | Use a different requested policy for applicable subdomains |
| np | reject | Address non-existent subdomains in scope |
| t | y | Reduce each declared assessment by one level for testing |
| adkim | s | Require exact DKIM alignment |
| aspf | r | Use relaxed SPF alignment |
| rua | mailto:dmarc-agg@example.com | Request aggregate reports |
With t=y, the declared quarantine assessment is reduced to none and each declared reject assessment is reduced to quarantine when a compliant receiver applies the tag. This is a testing interpretation, not a prediction of final placement.
Before publication, verify that the reporting mailbox and any external authorisation work, that exact DKIM alignment is realistic for legitimate signatures, and that subdomain ownership supports the requested policies.
Keep a versioned policy record
Store the approved record, owner name, resolver observations, evidence date, owner and rollback value. Recheck after DNS propagation and after material sender or specification changes.
Syntax is only the first gate. A record is operationally sound when its semantics match the identity architecture, reporting destinations are governed and representative mail confirms the intended aligned paths.