Domain-Based Message Authentication, Reporting, and Conformance (DMARC)
obsoletes
Extracted elements (33)
DMARC focuses on the RFC5322.From header field because it is the only header field required to be present in a valid email message (RFC 5322) and is the identifier end users see as the apparent sender, making it the primary target for phishing and spoofing despite being trivially forgeable historically.
The 'pct' tag (present in RFC 7489 to allow gradual rollout of policy enforcement by applying the policy to only a percentage of failing messages) was removed in this document. Its use created unpredictable behavior and is replaced by the 't' tag, which signals test mode and applies a policy one level below the published policy to all failing messages.
This document replaces the RFC 7489 approach of using a Public Suffix List (PSL) to determine Organizational Domains with a 'DNS Tree Walk' that discovers Organizational Domain boundaries from DMARC Policy Records themselves via the 'psd' tag. This eliminates reliance on an external, unauthenticated list and allows large organizations with decentralized DNS management to declare their own Organizational Domain boundaries.
DMARC creates significant interoperability problems for indirect mail flows such as mailing lists, forwarders, and alias services, where the RFC5322.From domain is preserved but SPF and DKIM alignment may break. Mail Receivers SHOULD NOT reject solely on 'p=reject' to avoid rejecting legitimate forwarded mail.
SPF with a hard-fail ('-all') suffix can cause message rejection early in the SMTP transaction before DMARC processing occurs, preventing a DKIM-aligned pass from saving the message and causing those rejections to be invisible to DMARC aggregate reports since the DATA phase is never reached.
A Mail Receiver sending aggregate or failure reports MUST implement support for a 'mailto:' URI (i.e., ability to send reports via email). If the 'rua' tag is absent, Mail Receivers MUST NOT generate aggregate reports; if 'ruf' is absent, MUST NOT generate failure reports. URIs using unsupported schemes MUST be ignored.
A PSO that publishes a DMARC Policy Record MUST include the 'psd' tag with a value of 'y' ('psd=y') to indicate that the domain is a Public Suffix Domain.
Discovered policies of 'p=none' MUST NOT modify existing mail handling processes, enabling Domain Owners to receive DMARC feedback without impacting mail flow during the monitoring phase.
Future extensions to DMARC that add new authentication mechanisms MUST allow for the assignment of a domain as an Authenticated Identifier, so that alignment with the Author Domain can be validated.
If a retrieved DMARC Policy Record lacks a valid 'p' tag but contains a 'rua' tag with at least one syntactically valid reporting URI, the Mail Receiver MUST treat the record as if it specified 'p=none' and continue processing; otherwise no DMARC processing applies.
If no valid DMARC Policy Record is discovered via the DNS Tree Walk (i.e., an explicit negative result rather than a transient DNS error), Mail Receivers MUST NOT apply the DMARC mechanism to the message.
It is RECOMMENDED that Domain Owners use both DKIM and SPF as underlying authentication mechanisms for DMARC, rather than relying on only one of the two.
Mail Receivers SHOULD NOT reject messages solely because of a published Domain Owner Assessment Policy of 'reject'; they should apply other knowledge and analysis to avoid rejecting legitimate messages, harming mailing list operation, and similar side effects.
The 'v' tag MUST be the first tag in a DMARC Policy Record, its value is case-sensitive, and the only valid value is 'DMARC1'. If the tag is not first, absent, or has any other value, the entire record MUST be ignored.
To maximize usefulness of DMARC feedback, Mail Receivers SHOULD generate and send aggregate reports with a frequency of at least once every 24 hours.
To prevent denial-of-service attacks via deeply nested Author Domains, the DNS Tree Walk MUST NOT result in more than eight DNS queries for any Author Domain. For domains with more than eight labels, queries skip intermediate labels so that at most eight queries are issued.
Unknown tags in a DMARC Policy Record MUST be ignored. Syntax errors in the remainder of the record MUST be discarded in favor of default values or ignored outright. This allows forward-compatible extension without requiring a new 'v' tag value.
When delivering messages that fail DMARC validation, Mail Receivers SHOULD add the Authentication-Results header field (RFC 8601). When deviating from a published Domain Owner Assessment Policy, Mail Receivers SHOULD report the fact and reason via the 'PolicyOverride' feature of the aggregate report.
When extracting the Author Domain from RFC5322.From, if the domain is a U-label, the Mail Receiver MUST convert it to an A-label as described in RFC 5890 Section 2.3 before further processing.
Where a DNS TXT record comprises multiple character-string objects, the module performing DMARC evaluation MUST concatenate these strings by joining them in order and parsing the result as a single string.
Aggregate reports contain information about all senders using the Author Domain, including potentially sensitive data about mail volumes and sources. Domain Owners and PSOs should consider who receives these reports, since third-party Report Consumers can learn about an organization's internal mail streams.
Failure reports contain per-message data and can expose the contents of email headers and message metadata about individual users. Mail Receivers concerned about user privacy may heavily redact or suppress failure reports entirely; RFC 9991 discusses these considerations in detail.
A DMARC Policy Record is a DNS TXT record published at the name formed by prepending '_dmarc' to a domain name (e.g., '_dmarc.example.com'). It encodes the domain owner's handling preference for DMARC failures and optional reporting URIs using a tag-value syntax inherited from DKIM.
Identifier Alignment requires that the Author Domain share its Organizational Domain with an Authenticated Identifier (relaxed alignment) or be identical to it (strict alignment). The alignment mode for DKIM and SPF is independently configurable via the 'adkim' and 'aspf' tags, defaulting to relaxed.
The DNS Tree Walk is the algorithm for discovering an Organizational Domain or applicable DMARC Policy Record. Starting from the Author Domain, it queries for '_dmarc.<domain>' TXT records, removing one label at a time, stopping when a record with 'psd=n' or 'psd=y' is found or labels are exhausted. Author Domains with more than eight labels trigger a shortcut limiting the walk to eight total queries.
Section 9.1 updates the Email Authentication Methods Registry (RFC 8601) and Section 9.2 updates the Email Authentication Result Names Registry to reflect DMARC as a Standards Track mechanism. Section 9.4 updates the DMARC Report Formats Registry and Section 9.5 updates the Underscored and Globally Scoped DNS Node Names Registry with the '_dmarc' label.
Section 9.3 updates the DMARC Tags Registry (originally created by RFC 7489) with the set of valid DMARC Policy Record tags defined in this document, including the newly added 'np', 'psd', and 't' tags and the removal of the 'pct' tag.
DMARC explicitly does not address display name attacks, where an abuser uses a visually convincing human-readable display name in RFC5322.From while using a different actual domain. Mail Receivers and end users cannot rely on DMARC to detect this class of attack.
DMARC policy discovery relies on DNS, which is susceptible to cache poisoning and other attacks. Mail Receivers should use DNSSEC where possible. A transient DNS failure during policy lookup cannot produce a definitive DMARC result; Mail Receivers may 'fail open' (deliver) or 'fail closed' (issue a 4xx SMTP reply) depending on local policy.
Relaxed alignment mode, while more practical, allows subdomains and sibling domains under the same Organizational Domain to pass DMARC. Strict alignment should be considered when the Domain Owner needs to prevent any subdomain from being able to authenticate as the parent domain.
Reporting URIs in DMARC Policy Records can be abused: a Domain Owner could specify a URI belonging to a third party without consent, causing that party to receive unsolicited reports. Implementations should verify that external reporting addresses have opted in via the mechanism described in RFC 9990 before sending reports to them.
DMARC produces a 'pass' result if at least one Authenticated Identifier (from DKIM or SPF) aligns with the Author Domain; otherwise it produces 'fail'. If zero or more than one RFC5322.From domain is present, DMARC validation terminates. DNS errors during validation prevent a definitive pass or fail, leaving handling to Mail Receiver discretion.
DMARC Policy Records use an ABNF tag-value format. The record begins with 'v=DMARC1', tags are separated by semicolons, and values are plain ASCII. Key tags include p (policy: none/quarantine/reject), sp (subdomain policy), np (non-existent subdomain policy), adkim/aspf (alignment mode: r/s), rua/ruf (reporting URIs), fo (failure options), psd (PSD flag: y/n/u), and t (test mode: y/n).