Message Header Field for Indicating Message Authentication Status
Extracted elements (31)
Rather than creating separate header fields for each authentication class (e.g., SPF's Received-SPF, DomainKeys' DomainKey-Status), this specification groups all methods into a single Authentication-Results header field to provide a common location and an extensible framework for reporting new authentication methods as they emerge.
The authserv-id SHOULD use a hierarchical, globally unique ADMD identifier (e.g., a DNS domain name) rather than a flat hostname. A hierarchical identifier permits aggregating related trusted systems under a single parent identifier, avoiding the administrative burden of individually listing each trusted system in consumer configurations.
The 'iprev' method is included not as an endorsement but merely as acknowledgment that reverse DNS mapping remains common and provides a means to relay results. Extensive caveats note that in some regions the test cannot reliably pass, and [DNSOP-REVERSE] recommends against using it for authentication or security.
Version tokens are included in the grammar for both the header field (attached to authserv-id) and individual methods to avoid misinterpretation of results. A parser encountering an unknown authserv-id version can immediately stop parsing; for unknown method versions, the parser SHOULD ignore the result in case the semantics differ from the expected version.
Experimental method identifiers and result codes MUST only be used within ADMDs that have explicitly consented to their use. Any MTA, MUA, or downstream filter intended for production use SHOULD ignore or delete any Authentication-Results header field that includes an experimental or unknown method identifier or extension result.
Agents performing 'iprev' DNS queries MUST be implemented to limit the number of names evaluated by corresponding A or AAAA queries so as not to be unduly taxing to the DNS infrastructure; this limit MAY be configurable by an administrator. SPF's example limit of 10 is cited.
An MTA MUST remove any Authentication-Results header field bearing a version it does not support if the SMTP connection relaying the message is not from a trusted internal MTA. This ensures consumers do not act on header fields with semantics they cannot correctly interpret.
Any MTA conforming to this specification MUST delete any discovered instance of the Authentication-Results header field that claims to have been added within its trust boundary but did not come directly from another trusted MTA. This prevents forgery of authentication results by external parties.
Each 'method' MUST refer to an authentication method declared in the IANA registry or an extension method, and each 'result' MUST refer to a result code declared in the IANA registry or an extension result code. An MTA MUST NOT add a result to an existing Authentication-Results header field; each MTA adds its own.
If the pvalue of an SPF or Sender ID result does not include authenticated local-part information, the pvalue SHOULD NOT include the local-part or the following '@' character, to avoid implying that the local-part was authenticated when it was not.
MUAs and downstream filters MUST ignore any result reported using a 'result' not specified in the IANA Result Code registry or a 'ptype' not listed in the Email Authentication Property Types registry. Such agents MUST also ignore a result for any 'method' they do not specifically support.
MUAs and downstream filters SHOULD NOT interpret the Authentication-Results header field unless specifically configured to do so by the user or administrator, and SHOULD NOT interpret it unless the authserv-id appears to be one used within their own ADMD. Interpretation should not be on by default.
The Authentication-Results header field MUST be treated as a trace header field per RFC 5322 Section 3.6.7, and thus MUST NOT be reordered and MUST be prepended to the message. It SHOULD be inserted above any other trace header fields such as Received.
The uniqueness of the authserv-id 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 the data in an Authentication-Results header field ought to be used or ignored.
DKIM ('dkim' method) and DomainKeys ('domainkeys' method) share a common result set: none (not signed), pass (signed and verified), fail (signed but verification failed), policy (signature not acceptable to ADMD), neutral (signature had syntax errors or processing failure), temperror (transient verification error), permerror (unrecoverable verification error).
Property types (ptypes) classify the source of evaluated message properties: 'body' for content extracted from the message body, 'header' for data from header fields, 'policy' for local policy decisions augmenting or overriding authentication results, and 'smtp' for values extracted from SMTP command parameters.
SMTP AUTH ('auth' method) result values are: none (auth not attempted), pass (client authenticated successfully), fail (authentication attempted but unsuccessful), temperror (transient error during authentication), permerror (permanent error during authentication). Reported with ptype 'smtp' and property 'auth' (AUTH command identity) or 'mailfrom' (AUTH parameter on MAIL FROM).
SPF uses the 'spf' method with ptype 'smtp' and property 'mailfrom' or 'helo'. Sender ID uses 'sender-id' with ptype 'header' and property being the header field name from which the Purported Responsible Address was extracted. Both share result codes: none, pass, fail, softfail, policy, neutral, temperror, permerror.
The Authentication-Results header field carries results of message authentication checks in a machine-readable format. Its value consists of an authserv-id, an optional version, and a series of 'method=result' statements with supporting 'ptype.property=value' data. It is defined as both a structured header field and a trace field per RFC 5322.
The authserv-id is a string identifying the authentication service within the ADMD that performed the checks. It is intended to be machine-readable. Common practice is to use the DNS organizational domain name of the ADMD, though any unique token pertaining to that ADMD is permitted.
The 'iprev' authentication method verifies that a client IP address has consistent forward and reverse DNS mappings. Results are: pass (PTR and A/AAAA queries agree), fail (lookups disagree or forward query returned no result), temperror (transient DNS error), permerror (no PTR data published for the IP). Reported using ptype 'policy' and property 'iprev'.
The 'policy' ptype indicates a local policy mechanism was applied that augments or overrides the result from the authentication mechanism. The property and value identify the local policy applied and its result, using arbitrary names selected by the ADMD. For example, a DKIM 'pass' could be overridden to 'fail' with 'policy.dkim-rules=unsigned-subject'.
The 'Email Authentication Methods' registry records method names, their ptypes, properties, values, status (active/deprecated), and version. New entries require Expert Review. No two entries may share the same method, ptype, and property combination. RFC 7601 updates the registry to add an 'auth'/'smtp'/'auth' entry and deprecate 'dkim-adsp' and 'domainkeys' entries.
The 'Email Authentication Property Types' registry (created by RFC 7410) records ptype names with their definitions and descriptions. Entries require Expert Review. RFC 7601 updates it to reference Section 2.3 of this document as the current definition for the 'body', 'header', 'policy', and 'smtp' entries.
The 'Email Authentication Result Names' registry records method-code pairs and their specifications/status. New entries require Expert Review; no two entries may share the same method and code. RFC 7601 updates all 'dkim', 'domainkeys', 'spf', 'sender-id', 'auth', and 'iprev' specification references and deprecates 'dkim-adsp' and 'domainkeys' entries.
A malicious sender can forge an Authentication-Results header field using a target ADMD's authserv-id, claiming valid authentication. A non-conformant MTA that fails to strip this forged field allows an MUA to inappropriately trust it. Mitigation requires border MTA compliance with Section 5 stripping and disabling interpretation by default.
A 'pass' result in the Authentication-Results header field does not render a message trustworthy. Spam can pass DKIM, SPF, and other checks while still being undesirable mail. MUAs and downstream filters must exercise care even after stripping possibly malicious headers.
Authentication-Results header fields found within message/rfc822 MIME attachments SHOULD be ignored by MUAs, and SHOULD be removed when extracting encapsulated messages to separate mail stores, to prevent improper interpretation outside the original trust context.
Implementers must thoroughly verify all Authentication-Results header fields and be robust against intentionally malformed ones, including extraordinarily large values, that could be used to discover or exploit weaknesses in header field parsing code.
Sites should issue SMTP-level rejection (per Section 4.2) rather than adding the Authentication-Results header field and allowing a message to proceed when local policy treats authentication failure as grounds for rejection. Allowing the message to proceed risks generating backscatter DSN messages to forged originator addresses.
The header field is formally specified in ABNF as: 'Authentication-Results:' authserv-id [authres-version] (no-result / 1*resinfo). Each resinfo contains a semicolon-delimited methodspec ('method=result'), an optional reasonspec ('reason=value'), and zero or more propspec entries ('ptype.property=pvalue'). Method and result values are constrained to IANA-registered keywords.