Message Header Field for Indicating Message Authentication Status
obsoleted by
- rfc-7601 — Message Header Field for Indicating Message Authentication Status
obsoletes
- rfc-5451 — Message Header Field for Indicating Message Authentication Status
- rfc-6577 — Authentication-Results Registration Update for Sender Policy Framework (SPF) Results
updated by
- rfc-7410 — A Property Types Registry for the Authentication-Results Header Field
Extracted elements (31)
A single Authentication-Results header field was chosen to unify results from multiple authentication schemes (SPF, DKIM, iprev, AUTH, etc.) rather than defining a separate header field for each method. Method-specific fields like Received-SPF and DomainKey-Status proved insufficient for conveying results from multiple coexisting authentication systems.
The 'iprev' method is included not as an endorsement but as acknowledgement that reverse DNS validation remains common practice and there should be a standard way to report its results. The RFC explicitly notes that RFC DNSOP-REVERSE recommends against using this test for authentication or security purposes.
Many existing MUAs are unlikely to be retrofitted to consume Authentication-Results. Delivery MTAs may wish to add complementary signals understood by legacy MUAs (e.g., a Priority header field reflecting authentication strength) alongside the Authentication-Results header field to aid adoption during the transition period.
Agents performing 'iprev' DNS queries MUST limit the number of names evaluated via A/AAAA queries so as not to unduly tax the DNS infrastructure; this limit MAY be administrator-configurable. Section 5.5 of RFC 4408 (SPF) chose a limit of 10 as an example.
An MTA adding the Authentication-Results header field SHOULD NOT include any data that has not been authenticated by the method(s) being applied. MUAs SHOULD NOT render unauthenticated data to users if presented by a method known not to authenticate it.
An MTA MUST NOT add a result to an existing Authentication-Results header field; each MTA performing authentication must add its own new header field instance. Each method and result referenced MUST be declared in the IANA registry or qualify as an extension method/result per Sections 2.6.6–2.6.7.
An MTA SHOULD remove any instance of this header field bearing a version it does not support, but MUST remove such a header field if the SMTP connection relaying the message is not from a trusted internal MTA. This requires MTAs to understand all header field versions used by consumers within their ADMD.
Any MTA conforming to this specification MUST delete any discovered instance of the Authentication-Results header field that claims, by virtue of its authserv-id, to have been added within its trust boundary but did not arrive from a trusted internal MTA. This prevents injection of forged authentication assertions by external senders.
Experimental extension method identifiers MUST only be used within ADMDs that have explicitly consented to use them. Any MTA, MUA, or downstream filter intended for production use SHOULD ignore or delete any Authentication-Results header field that includes an experimental (unknown) method identifier or extension result.
MUAs and downstream filters MUST ignore any result reported using an unregistered 'result' value or unregistered 'ptype', and MUST ignore results for any 'method' they do not specifically support. Consumers SHOULD NOT interpret the header field unless specifically configured to do so by the user or administrator.
The Authentication-Results header field MUST be treated as a trace header field: it MUST NOT be reordered and MUST be prepended to the message. It SHOULD be inserted above any other trace header fields (such as Received) that MTAs prepend.
The authserv-id uniqueness MUST be guaranteed by the ADMD that generates it and MUST pertain to that ADMD. MUAs or downstream filters SHOULD use this identifier to determine whether to trust the header field's contents.
DKIM (method 'dkim') and DomainKeys (method 'domainkeys') share a common result set: none, pass, fail, policy, neutral, temperror, and permerror. A 'fail' result means the signature was present and acceptable but failed verification; 'neutral' means syntax errors or processing failures; 'policy' means the signature did not meet local ADMD policy.
SMTP AUTH (method 'auth') result values are none (not attempted), pass (successfully authenticated), fail (authentication attempted but unsuccessful), temperror, and permerror. Agents SHOULD treat 'fail' and 'temperror' as equivalent for the purpose of message authentication decisions.
SPF (method 'spf') and Sender ID (method 'sender-id') use result codes none, pass, fail, softfail, policy, neutral, temperror, and permerror, derived from RFC 4408. An additional 'policy' result is defined for when the authentication passed but local policy deems the result unacceptable (e.g., domain is on a blocklist). If sender policies do not authenticate the local-part, it SHOULD NOT be included in the pvalue.
The Authentication-Results header field is a structured trace header field added by MTAs to report the results of message authentication checks (e.g., DKIM, SPF, iprev, SMTP AUTH). It contains an authserv-id identifying the ADMD that performed the checks, followed by one or more method=result statements with optional supporting property data.
The authserv-id is a string identifying the authentication service within the ADMD that conducted the checks. It is machine-readable and is used by consumers to determine whether the header field contents are trustworthy. Common practice is to use the ADMD's organizational DNS domain name.
The 'iprev' method performs a reverse DNS lookup (PTR query) on the client IP address, then forward lookups (A/AAAA) on the returned names, and reports 'pass' if the original IP appears in the forward lookup results. Result values are pass, fail, temperror, and permerror; there is no 'none' since every TCP connection has an IP address.
The 'policy' ptype indicates that a local policy mechanism was applied that augments or overrides the result returned by the authentication mechanism. The property and value identify the local policy applied and its result; these names are arbitrary and ADMD-local, not IANA-registered.
Version tokens may optionally appear after the authserv-id (indicating the version of this specification) and after each method name (indicating the method's own version as registered in the IANA 'Email Authentication Methods' registry). Absence of a version implies version 1.
The Authentication-Results header field is registered in the IANA 'Permanent Message Header Field Names' registry (originally registered by RFC 5451). The entry references RFC 7001, is applicable to the 'mail' protocol, and has status 'Standard'.
The 'Email Authentication Methods' registry (originally created by RFC 5451, updated by this document) lists recognized authentication method names. New entries require Expert Review. Each entry records the method name, specification, version number, applicable ptype values, the properties to report, and descriptions of the property values.
The 'Email Authentication Result Names' registry (originally created by RFC 5451, updated by this document) lists recognized result codes. New entries require Expert Review. Experimental result codes MUST NOT be used in production and are not registered.
A compromised internal MTA or MUA could generate forged Authentication-Results header fields endorsing fraudulent From addresses. Mitigation requires that internal MTAs strip this header field from any message claiming a trusted authserv-id that did not arrive via a known-authorized internal SMTP connection.
A 'pass' result does not render a message trustworthy: spam or phishing can legitimately pass authentication checks (e.g., a spammer signing with DKIM from their own domain). MUAs and filters must apply additional reputation or content analysis even after header field scrubbing.
Authentication-Results header fields found within message/rfc822 MIME attachments (encapsulated messages) MUST be ignored by MUAs, since the encapsulated message may have transited outside the trust boundary. When extracting encapsulated messages to separate mail store entries, such header fields should be removed.
Forged Authentication-Results header fields are the primary threat: a malicious sender can forge an authserv-id matching the receiving ADMD and claim authentication passed. A non-conformant MTA that fails to strip such fields will cause MUAs to trust forged results. Mitigation requires border MTA compliance with Section 5 (stripping untrusted instances) and consumer configuration to only process the field from known-trusted producers.
Intentionally malformed Authentication-Results header fields (e.g., extraordinarily large values) may be used to discover or exploit weaknesses in header parsing code. Implementers must robustly validate all such header fields received from MTAs.
Intermediate MTAs may reorder header fields in violation of RFC 5322; the requirement to prepend Authentication-Results is best-effort. Consumers should tolerate headers that were not prepended, particularly from known-limited producers.
Verifiers performing 'iprev' DNS lookups must guard against DNS-based denial-of-service attacks by bounding the number of PTR and A/AAAA queries, as described in Section 5.5 of RFC 4408. Unbounded queries can be induced by crafted PTR records.
The header field is formally defined in ABNF as: 'Authentication-Results:' authserv-id [authres-version] (no-result / 1*resinfo). Each resinfo consists of a semicolon-delimited methodspec ('method=result'), optional reasonspec ('reason=value'), and zero or more propspec elements ('ptype.property=pvalue'). The ptype values are 'smtp', 'header', 'body', or 'policy'.