DMARC

Stands for: Domain-based Message Authentication, Reporting, and Conformance

An email policy in DNS under which mail passes only if an SPF or DKIM pass is aligned with the domain in the visible From.

SPF and DKIM authenticate domains the reader never sees; DMARC ties them to the From domain the reader does see and lets that domain ask for reports. Since May 2026 it is Standards Track: RFC 9989, with aggregate and failure reporting in RFC 9990 and RFC 9991, which together obsolete the Informational RFC 7489.

The policy is a TXT record at _dmarc under the domain, such as _dmarc.example.com, with p=none, quarantine or reject (none if absent), sp and np for subdomains and non-existent ones, and rua and ruf for reports. A message passes when its From domain aligns with a DKIM d= domain or an SPF-validated MAIL FROM, never HELO: relaxed alignment needs the same Organizational Domain, strict needs identical names, and relaxed is the default.

Against RFC 7489, RFC 9989 replaces the Public Suffix List with a DNS Tree Walk of at most eight queries, which also absorbs public suffix policy from RFC 9091, now obsolete. It adds np, psd and t and removes pct, rf and ri: t=y asks receivers to apply one level below the stated policy, the role pct=0 had taken on. Aggregate reports, XML documents, moved to RFC 9990, and failure reports to RFC 9991.

A pass says only that the use of the domain was authorised, not that the mail is safe. Receivers MUST NOT reject on p=reject alone and, without other analysis, treat it as quarantine. Forwarding breaks SPF, so a p=reject domain MUST sign with DKIM, and domains whose users post to mailing lists SHOULD NOT publish p=reject; the advised path is p=none for at least a month, then quarantine as long.

Also known as: dmarc, identifier alignment, _dmarc, p=none, p=reject, aggregate reports

Sources

← All glossary entries