Message Header Field for Indicating Message Authentication Status
obsoletes
- rfc-7601 — Message Header Field for Indicating Message Authentication Status
Extracted elements (32)
Rather than defining a separate header field per authentication method (as SPF's Received-SPF and DomainKeys' DomainKey-Status did), this specification consolidates all authentication results into a single extensible header field. This creates a common location and a common framework for current and future methods.
The authserv-id SHOULD be a hierarchical, globally unique identifier such as a DNS domain name rather than a flat hostname. A hierarchical identifier allows aggregating related trusted systems under a single parent token, avoiding the administrative burden of maintaining a per-host allowlist that must be continuously updated.
The iprev method's reliability varies significantly by region and operator practice; in some regions forward/reverse DNS matching is rarely maintained, making the test unlikely ever to pass. The precise implementation details of iprev are intentionally unspecified, and consumers must understand what a given verifier's iprev result actually means.
Agents performing iprev PTR and A/AAAA queries MUST limit the number of names evaluated to avoid unduly taxing DNS infrastructure; the limit MAY be administrator-configurable. SPF's limit of 10 is cited as an example.
An MTA adding this header field SHOULD NOT include any data that have not been authenticated by the method(s) being applied, and MUAs SHOULD NOT render such unauthenticated information to users.
An MTA MUST NOT add a result to an existing Authentication-Results header field; each authentication test must produce a new header field or be combined only by the same MTA in a single operation.
Any MTA conforming to this specification MUST delete any discovered instance of this header field that claims, via its authserv-id, to have been added within its trust boundary but did not arrive from a trusted internal MTA. This prevents forged authentication assertions from reaching consumers.
Experimental method identifiers and result codes MUST only be used within ADMDs that have explicitly consented to use them. Any MTA, MUA, or downstream filter for production use SHOULD ignore or delete any Authentication-Results header field containing an experimental (unknown) method identifier.
MUAs and downstream filters MUST ignore any result reported using a 'result' not in the IANA Result Code registry or a 'ptype' not in the Email Authentication Property Types registry, and MUST ignore results for methods they do not specifically support.
MUAs and downstream filters SHOULD NOT interpret this header field unless specifically configured to do so; interpretation should not be on by default. They SHOULD also verify that the authserv-id is one used within their ADMD.
The Authentication-Results header field MUST be treated as a trace header field as defined in RFC 5321, and hence MUST NOT be reordered and MUST be prepended to the message so that the chain of authentication handling is visible.
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 decide whether to use or ignore the data in an Authentication-Results header field.
When local policy produces a non-recoverable authentication failure, the border MTA SHOULD issue an SMTP rejection rather than adding the header field and allowing the message to proceed, to avoid generating DSN backscatter to forged originators.
DKIM result values are: none (not signed), pass (signed and verified), fail (signed but failed verification), policy (signature unacceptable per ADMD policy), neutral (syntax errors or processing failure), temperror (transient verification failure), permerror (unrecoverable verification failure).
Property types (ptypes) define the general category of message property evaluated: 'body' (message body content), 'header' (header field or portion), 'policy' (local policy decision), 'smtp' (SMTP command parameter). Results with unknown ptypes MUST NOT be used in handling decisions.
SMTP AUTH (method 'auth') result values are none, pass, fail, temperror, permerror. Results use ptype 'smtp' with property 'auth' (authorization identity) and/or 'mailfrom' (AUTH= parameter). All non-pass cases indicate an unauthenticated client.
SPF result values are: none, pass, fail, softfail, policy, neutral, temperror, permerror — imported from RFC 7208 Section 2.6. SPF uses ptype 'smtp' with property 'mailfrom' or 'helo'.
The authserv-id token identifies the authentication service within the ADMD that performed the checks. It is machine-readable, may be expressed in UTF-8 in EAI messages, and is used by consumers to decide whether header field contents are trustworthy.
The 'iprev' method verifies that a connecting IP address maps via PTR to one or more names that in turn map back to that IP via A/AAAA queries. Result values are pass, fail, temperror, and permerror; there is no 'none' since every TCP connection has an IP address. Results use ptype 'policy' and property 'iprev'.
The 'policy' ptype indicates that a local policy mechanism augmented or overrode the result of an authentication method. The property and value identify the local policy applied and its outcome, and are not normally registered with IANA.
Version tokens may appear after the authserv-id and after each method name. The authserv-id version refers to the header field syntax version (current: 1); the method version refers to the authentication method's specification version. Parsers SHOULD ignore method results with unsupported versions.
RFC 8601 adds two new entries to the Email Authentication Methods registry: 'header.a' (DKIM signature algorithm tag 'a') and 'header.s' (DKIM selector tag 's'), both with method 'dkim', ptype 'header', status 'active', version 1. These support post-verification processing, notably identifying deprecated rsa-sha1 signatures.
The Authentication-Results header field is registered in the IANA Permanent Message Header Field Names registry with status 'standard', applicable protocol 'mail', referencing RFC 8601.
The 'Email Authentication Methods' registry (within the Email Authentication Parameters group) records authentication methods, their ptype/property/value tuples, status (active/deprecated), and version. New entries require Expert Review. No two entries may share the same method/ptype/property combination.
The 'Email Authentication Property Types' registry records valid ptype values. Current entries are body, header, policy, and smtp. New entries require Expert Review. RFC 8601 updates all entries to reference this document.
The 'Email Authentication Result Names' registry records result codes per authentication method. New entries require Expert Review; no two entries may share the same method/code combination. RFC 8601 updates result codes for auth, dkim, iprev, and spf methods and deprecates domainkeys and sender-id entries.
A compromised internal MTA or MUA can generate mail with forged From and Authentication-Results header fields. This risk is mitigated by configuring internal MTAs to remove any Authentication-Results header field claiming to be from a trusted border MTA when the SMTP connection is not from a known authorized internal host.
A malicious agent can forge an Authentication-Results header field using a legitimate ADMD's authserv-id to falsely claim authentication success. Non-conformant MTAs that do not strip such headers expose downstream consumers to false trust conclusions. Mitigation requires strict removal of inbound header fields claiming internal origin.
An authentication 'pass' result does not render a message trustworthy. Spam or malicious mail may legitimately pass DKIM or SPF checks if sent by a compromised or spam-originating domain. MUAs and filters must apply additional reputation or policy judgements beyond raw authentication results.
Attackers may inject intentionally malformed or extraordinarily large Authentication-Results header fields to exploit weaknesses in parsing code. Implementers must thoroughly validate all received instances and be robust against both intentional and accidental malformation.
Authentication-Results header fields inside message/rfc822 MIME attachments reflect historical authentication checks and MUST NOT be trusted. MUAs MUST ignore such encapsulated instances, and agents extracting messages to other media should strip these header fields.
The Authentication-Results header field is defined by an ABNF grammar with an authserv-id, optional version, and one or more 'method=result' statements. Each result may include a 'reason' string and 'ptype.property=pvalue' tuples indicating which message properties were evaluated.