Practical email authentication

DMARC Record Reference — Tags, Defaults & RFC 9989

Understand every DMARC tag, receiver defaults, external reporting authorization and RFC 9989 changes including np, psd, t and legacy pct behavior.

Standards baseline: RFC 9989 and RFC 9990, with RFC 7489 compatibility notes. A DNS policy is not a delivery, protection or compliance guarantee.

Publish one policy at the right DNS name.

For mail.example, publish TXT at _dmarc.mail.example. If your DNS panel appends the zone name automatically, enter only _dmarc. Replace an existing DMARC record instead of adding a second one. Split strings within one TXT record are concatenated; separate TXT records remain separate policies.

v=DMARC1; p=none; rua=mailto:reports@mail.example; adkim=r; aspf=r

This example uses a reserved domain and a mailbox that is not active. Substitute a verified report destination. A valid record requests reports but does not ensure receipt.

Tag reference with current and legacy defaults.

RFC 9989 guidance; legacy tags are labeled.
TagDefaultMeaning
vRequiredVersion. DMARC1 is case-sensitive and must be the first tag.
pnone (RFC 9989)Requested treatment: none, quarantine or reject. Publish explicitly for older receiver compatibility.
sppPolicy for existing subdomains when an inherited organizational or public-suffix policy applies.
npsp, then pPolicy for non-existent subdomains under RFC 9989. Domain existence requires a separate DNS check.
adkimrDKIM alignment: relaxed organizational-domain match or strict exact domain match. A valid signature must also pass.
aspfrSPF alignment: relaxed or strict. SPF success on an unrelated return-path does not satisfy DMARC.
ruaNot requestedAggregate-report destinations. mailto: is widely supported; external destinations may need authorization.
rufNot requestedMessage-specific failure reports. Limited provider support; assess personal-data handling before enabling.
fo0Failure-report triggers: 0, 1, d, s. 0 and 1 are mutually exclusive. Ignored without ruf.
psduDNS tree-walk boundary: y identifies a public suffix, n an organizational domain, u leaves discovery open.
tnRFC 9989 testing: y requests one lower treatment level; older receivers may ignore it. Not a safe substitute for p=none.
pctLegacy: 100Removed by RFC 9989. Older receivers may honor percentages; current receivers ignore this tag.
riLegacy: 86400Legacy report interval. Removed by RFC 9989; report cadence remains receiver-dependent.
rfLegacy: afrfLegacy failure-report format. Removed by RFC 9989.

Explicit and inherited policies.

The inspector first checks the exact domain. Without a usable explicit policy, it uses the bounded RFC 9989 tree walk, with psd boundaries, to locate the organizational or public-suffix policy. Existing subdomains use sp when applicable; non-existent subdomains can use np. If a DNS query fails, the tool reports uncertainty instead of asserting that no policy exists.

RFC 7489 receivers can use PSL-based organizational domains and different inheritance. We do not claim identical behavior across receivers. Publish explicit policies for every sending domain when compatibility matters.

See your discovery trace

External reporting authorization.

For a policy at mail.example reporting to reports@provider.example, an external receiver may need TXT authorization at mail.example._report._dmarc.provider.example starting with v=DMARC1. A wildcard may also answer that query.

The inspector shows exact DNS evidence. It does not prove that the mailbox accepts reports, fully resolve organizational equivalence for reporting domains, or follow destination overrides. An absent authorization TXT can be harmless within the same organizational domain; consult the report provider rather than blindly adding records.

The 2026 compatibility changes matter.

RFC 9989 obsoletes RFC 7489 and RFC 9091. It introduces np, psd and t, changes organizational-domain discovery and removes pct, ri and rf. A record without p defaults to none in the current standard, but older receivers may not treat it the same way.

Keep p explicit. Do not rely on t=y or a low pct for a risk-free rollout: older and current receivers differ. Start with p=none while you verify legitimate senders. Legacy !size suffixes on reporting URIs are obsolete and ignored by current receivers.

Standards and further reading.

Maail’s tools are diagnostic aids, not cryptographic message validators or a universal receiver simulator. Review their data boundaries.

Go from explanation to evidence

Inspect, observe, then decide.