Tech-invite   World Map
3GPPspecs     Glossaries     IETF     RFCs     Groups     SIP     ABNFs

RFC 7601


Message Header Field for Indicating Message Authentication Status

Part 3 of 3, p. 42 to 53
Prev RFC Part


prevText      Top      Up      ToC       Page 42 
Appendix A.  Legacy MUAs

   Implementers of this protocol should be aware that many MUAs are
   unlikely to be retrofitted to support the new header field and its
   semantics.  In the interests of convenience and quicker adoption, a
   delivery MTA might want to consider adding things that are processed
   by existing MUAs in addition to the Authentication-Results header
   field.  One suggestion is to include a Priority header field, on
   messages that don't already have such a header field, containing a
   value that reflects the strength of the authentication that was
   accomplished, e.g., "low" for weak or no authentication, "normal" or
   "high" for good or strong authentication.

   Some modern MUAs can already filter based on the content of this
   header field.  However, there is keen interest in having MUAs make
   some kind of graphical representation of this header field's meaning
   to end users.  Until this capability is added (i.e., while this
   proposal and its successors are being adopted), other interim means
   of conveying authentication results may be necessary.

Appendix B.  Authentication-Results Examples

   This section presents some examples of the use of this header field
   to indicate authentication results.

B.1.  Trivial Case; Header Field Not Present

   The trivial case:

        Received: from
                      ( [])
                  by (8.11.6/8.11.6)
                      with ESMTP id g1G0r1kA003489;
                  Fri, Feb 15 2002 17:19:07 -0800
        Date: Fri, Feb 15 2002 16:54:30 -0800
        Message-Id: <>
        Subject: here's a sample

        Hello!  Goodbye!

                          Example 1: Trivial Case

Top      Up      ToC       Page 43 
   The Authentication-Results header field is completely absent.  The
   MUA may make no conclusion about the validity of the message.  This
   could be the case because the message authentication services were
   not available at the time of delivery, or no service is provided, or
   the MTA is not in compliance with this specification.

B.2.  Nearly Trivial Case; Service Provided, but No Authentication Done

   A message that was delivered by an MTA that conforms to this
   specification but provides no actual message authentication service:

        Authentication-Results: 1; none
        Received: from
                      ( [])
                  by (8.11.6/8.11.6)
                      with ESMTP id g1G0r1kA003489;
                  Fri, Feb 15 2002 17:19:07 -0800
        Date: Fri, Feb 15 2002 16:54:30 -0800
        Message-Id: <>
        Subject: here's a sample

        Hello!  Goodbye!

           Example 2: Header Present but No Authentication Done

   The Authentication-Results header field is present, showing that the
   delivering MTA conforms to this specification.  It used its DNS
   domain name as the authserv-id.  The presence of "none" (and the
   absence of any method or result tokens) indicates that no message
   authentication was done.  The version number of the specification to
   which the field's content conforms is explicitly provided.

Top      Up      ToC       Page 44 
B.3.  Service Provided, Authentication Done

   A message that was delivered by an MTA that conforms to this
   specification and applied some message authentication:

        Received: from
                      ( [])
                  by (8.11.6/8.11.6)
                      with ESMTP id g1G0r1kA003489;
                  Fri, Feb 15 2002 17:19:07 -0800
        Date: Fri, Feb 15 2002 16:54:30 -0800
        Message-Id: <>
        Subject: here's a sample

        Hello!  Goodbye!

                    Example 3: Header Reporting Results

   The Authentication-Results header field is present, indicating that
   the border MTA conforms to this specification.  The authserv-id is
   once again the DNS domain name.  Furthermore, the message was
   authenticated by that MTA via the method specified in [SPF].  Note
   that since that method cannot authenticate the local-part, it has
   been omitted from the result's value.  The MUA could extract and
   relay this extra information if desired.

Top      Up      ToC       Page 45 
B.4.  Service Provided, Several Authentications Done, Single MTA

   A message that was relayed inbound via a single MTA that conforms to
   this specification and applied three different message authentication

                  auth=pass (cram-md5);
        Received: from (8.11.6/8.11.6)
                      ( [])
                  by (8.11.6/8.11.6)
                      with ESMTPA id g1G0r1kA003489;
                  Fri, Feb 15 2002 17:19:07 -0800
        Date: Fri, Feb 15 2002 16:54:30 -0800
        Message-Id: <>
        Subject: here's a sample

        Hello!  Goodbye!

             Example 4: Headers Reporting Results from One MTA

   The Authentication-Results header field is present, indicating that
   the delivering MTA conforms to this specification.  Once again, the
   receiving DNS domain name is used as the authserv-id.  Furthermore,
   the sender authenticated herself/himself to the MTA via a method
   specified in [AUTH], and both SPF and Sender ID checks were done and
   passed.  The MUA could extract and relay this extra information if

   Two Authentication-Results header fields are not required since the
   same host did all of the checking.  The authenticating agent could
   have consolidated all the results into one header field.

   This example illustrates a scenario in which a remote user on a dial-
   up connection ( sends mail to a border MTA (
   using SMTP authentication to prove identity.  The dial-up provider
   has been explicitly authorized to relay mail as,
   producing "pass" results from the SPF and Sender ID checks.

Top      Up      ToC       Page 46 
B.5.  Service Provided, Several Authentications Done, Different MTAs

   A message that was relayed inbound by two different MTAs that conform
   to this specification and applied multiple message authentication

                  dkim=pass (good signature)
        Received: from
                      ( [])
                  by (8.11.6/8.11.6)
                      with ESMTP id i7PK0sH7021929;
                  Fri, Feb 15 2002 17:19:22 -0800
        DKIM-Signature:  v=1; a=rsa-sha256; s=gatsby;;
                  t=1188964191; c=simple/simple; h=From:Date:To:Subject:
                  b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM=
                  auth=pass (cram-md5);
        Received: from
                      ( [])
                  by (8.11.6/8.11.6)
                      with ESMTPA id g1G0r1kA003489;
                  Fri, Feb 15 2002 17:19:07 -0800
        Date: Fri, Feb 15 2002 16:54:30 -0800
        Message-Id: <>
        Subject: here's a sample

        Hello!  Goodbye!

          Example 5: Headers Reporting Results from Multiple MTAs

   The Authentication-Results header field is present, indicating
   conformance to this specification.  Once again, the authserv-id used
   is the recipient's DNS domain name.  The header field is present
   twice because two different MTAs in the chain of delivery did
   authentication tests.  The first MTA,,
   reports that SMTP AUTH and SPF were both used and that the former
   passed while the latter failed.  In the SMTP AUTH case, additional
   information is provided in the comment field, which the MUA can
   choose to render if desired.

Top      Up      ToC       Page 47 
   The second MTA,, reports that it did a
   Sender ID test (which failed) and a DKIM test (which passed).  Again,
   additional data about one of the tests is provided as a comment,
   which the MUA may choose to render.  Also noteworthy here is the fact
   that there is a DKIM signature added by that assured the
   integrity of the lower Authentication-Results field.

   Since different hosts did the two sets of authentication checks, the
   header fields cannot be consolidated in this example.

   This example illustrates more typical transmission of mail into from a user on a dial-up connection  The
   user appears to be legitimate as he/she had a valid password allowing
   authentication at the border MTA using SMTP AUTH.  The SPF and Sender
   ID tests failed since has not granted
   authority to relay mail on its behalf.  However, the DKIM test passed
   because the sending user had a private key matching one of's published public keys and used it to sign the message.

Top      Up      ToC       Page 48 
B.6.  Service Provided, Multi-tiered Authentication Done

   A message that had authentication done at various stages, one of
   which was outside the receiving ADMD:

              dkim=pass reason="good signature"
              dkim=fail reason="bad signature"
        Received: from
                  ( [])
              by (8.11.6/8.11.6)
                  for <>
                  with ESMTP id i7PK0sH7021929;
              Fri, Feb 15 2002 17:19:22 -0800
        DKIM-Signature: v=1; a=rsa-sha256; s=furble;
    ; t=1188964198; c=relaxed/simple;
              b=oINEO8hgn/gnunsg ... 9n9ODSNFSDij3=
              dkim=pass (good signature)
        Received: from
                  ( [])
              by (8.11.6/8.11.6)
                  with ESMTP id g1G0r1kA003489;
              Fri, Feb 15 2002 17:19:07 -0800
        DKIM-Signature: v=1; a=rsa-sha256; s=gatsby;
              t=1188964191; c=simple/simple;
              b=EToRSuvUfQVP3Bkz ... rTB0t0gYnBVCM=
        Date: Fri, Feb 15 2002 16:54:30 -0800
        Message-Id: <>
        Subject: here's a sample

        Example 6: Headers Reporting Results from Multiple MTAs in
                              Different ADMDs

   In this example, we see multi-tiered authentication with an extended
   trust boundary.

Top      Up      ToC       Page 49 
   The message was sent from someone at's New York office
   ( to a mailing list managed at an intermediary.
   The message was signed at the origin using DKIM.

   The message was sent to a mailing list service provider called, which is used by  There, is expanded to a long list of recipients, one of
   whom is at the Chicago office.  In this example, we will assume that
   the trust boundary for includes the mailing list
   server at

   The mailing list server there first authenticated the message and
   affixed an Authentication-Results header field indicating such using
   its DNS domain name for the authserv-id.  It then altered the message
   by affixing some footer text to the body, including some
   administrivia such as unsubscription instructions.  Finally, the
   mailing list server affixes a second DKIM signature and begins
   distribution of the message.

   The border MTA for explicitly trusts results from, so that header field is not removed.  It
   performs evaluation of both signatures and determines that the first
   (most recent) is a "pass" but, because of the aforementioned
   modifications, the second is a "fail".  However, the first signature
   included the Authentication-Results header added at mail- that validated the second signature.  Thus,
   indirectly, it can be determined that the authentications claimed by
   both signatures are indeed valid.

   Note that two styles of presenting metadata about the result are in
   use here.  In one case, the "reason=" clause is present, which is
   intended for easy extraction by parsers; in the other case, the CFWS
   production of the ABNF is used to include such data as a header field
   comment.  The latter can be harder for parsers to extract given the
   varied supported syntaxes of mail header fields.

B.7.  Comment-Heavy Example

   The formal syntax permits comments within the content in a number of
   places.  For the sake of illustration, this example is also legal:

       Authentication-Results: (foobar) 1 (baz);
           dkim (Because I like it) / 1 (One yay) = (wait for it) fail
             policy (A dot can go here) . (like that) expired
             (this surprised me) = (as I wasn't expecting it) 1362471462

        Example 7: A Very Comment-Heavy but Perfectly Legal Example

Top      Up      ToC       Page 50 
Appendix C.  Operational Considerations about Message Authentication

   This protocol is predicated on the idea that authentication (and
   presumably in the future, reputation) work is typically done by
   border MTAs rather than MUAs or intermediate MTAs; the latter merely
   make use of the results determined by the former.  Certainly this is
   not mandatory for participation in electronic mail or message
   authentication, but this protocol and its deployment to date are
   based on that model.  The assumption satisfies several common ADMD

   1.  Service operators prefer to resolve the handling of problem
       messages as close to the border of the ADMD as possible.  This
       enables, for example, rejection of messages at the SMTP level
       rather than generating a DSN internally.  Thus, doing any of the
       authentication or reputation work exclusively at the MUA or
       intermediate MTA renders this desire unattainable.

   2.  Border MTAs are more likely to have direct access to external
       sources of authentication or reputation information since modern
       MUAs are more likely to be heavily firewalled.  Thus, some MUAs
       might not even be able to complete the task of performing
       authentication or reputation evaluations without complex proxy
       configurations or similar burdens.

   3.  MUAs rely upon the upstream MTAs within their trust boundaries to
       make correct (as much as is possible) evaluations about the
       message's envelope, header, and content.  Thus, MUAs don't need
       to know how to do the work that upstream MTAs do; they only need
       the results of that work.

   4.  Evaluations about the quality of a message, from simple token
       matching (e.g., a list of preferred DNS domains) to cryptanalysis
       (e.g., public/private key work), do have a cost and thus need to
       be minimized.  To that end, performing those tests at the border
       MTA is far preferred to doing that work at each MUA that handles
       a message.  If an ADMD's environment adheres to common messaging
       protocols, a reputation query or an authentication check
       performed by a border MTA would return the same result as the
       same query performed by an MUA.  By contrast, in an environment
       where the MUA does the work, a message arriving for multiple
       recipients would thus cause authentication or reputation
       evaluation to be done more than once for the same message (i.e.,
       at each MUA), causing needless amplification of resource use and
       creating a possible denial-of-service attack vector.

Top      Up      ToC       Page 51 
   5.  Minimizing change is good.  As new authentication and reputation
       methods emerge, the list of methods supported by this header
       field would presumably be extended.  If MUAs simply consume the
       contents of this header field rather than actually attempt to do
       authentication and/or reputation work, then MUAs only need to
       learn to parse this header field once; emergence of new methods
       requires only a configuration change at the MUAs and software
       changes at the MTAs (which are presumably fewer in number).  When
       choosing to implement these functions in MTAs vs. MUAs, the
       issues of individual flexibility, infrastructure inertia, and
       scale of effort must be considered.  It is typically easier to
       change a single MUA than an MTA because the modification affects
       fewer users and can be pursued with less care.  However, changing
       many MUAs is more effort than changing a smaller number of MTAs.

   6.  For decisions affecting message delivery and display, assessment
       based on authentication and reputation is best performed close to
       the time of message transit, as a message makes its journey
       toward a user's inbox, not afterwards.  DKIM keys and IP address
       reputations, etc., can change over time or even become invalid,
       and users can take a long time to read a message once delivered.
       The value of this work thus degrades, perhaps quickly, once the
       delivery process has completed.  This seriously diminishes the
       value of this work when done elsewhere than at MTAs.

   Many operational choices are possible within an ADMD, including the
   venue for performing authentication and/or reputation assessment.
   The current specification does not dictate any of those choices.
   Rather, it facilitates those cases in which information produced by
   one stage of analysis needs to be transported with the message to the
   next stage.

Appendix D.  Changes since RFC 7001

   o  Applied RFC 7410.

   o  Updated all references to RFC 4408 with RFC 7208.

   o  Added section explaining "property" values.  (Addressed Erratum

   o  Did some minor text reorganization.

   o  Gave registry history -- enough that this is now the authoritative
      registry definition.

   o  Added text explaining each of the method-ptype-property tuples
      registered by this document.

Top      Up      ToC       Page 52 
   o  Changed the meaning of the "Defined" column of the methods
      registry to be the place where each entry was created and
      described; it is expected that this will then refer to the
      method's defining document.  Provided IANA with corresponding
      update instructions.

   o  Cleaned up registry structure and content, and replaced all
      references to RFC 7001 with pointers to this document.

   o  Added references: [DMARC], [PRA], [RFC6008], [RFC6577], [RRVS],

   o  Added description of values that can be extracted from SMTP AUTH
      sessions and an example.

   o  Provided much more complete descriptions of reporting DomainKeys

   o  Added more detail about Sender ID.

   o  Marked all ADSP and DomainKeys entries as deprecated since their
      defining documents are as well.

   o  Reworked some text around ignoring unknown ptypes.

   o  Completely described the ptypes registry.

   o  Mentioned that EHLO is mapped to HELO for SPF.

   o  RFC 7208 uses all-lowercase result strings now, so adjusted prose

   o  Updated list of supported methods, and mentioned the registries
      immediately below.

   o  Mentioned that when a local-part is removed, the "@" goes with it.

   o  Referred to RFC 7328 in the "iprev" definition.

   o  Corrected the "smime-part" prose.

   o  Updated examples that use SMTP AUTH to claim "with ESMTPA" in the
      Received fields.

   o  Made minor editorial adjustments.

Top      Up      ToC       Page 53 

   The author wishes to acknowledge the following individuals for their
   review and constructive criticism of this document: Stephane
   Bortzmeyer, Scott Kitterman, John Levine, Tom Petch, and Pete

Author's Address

   Murray S. Kucherawy
   270 Upland Drive
   San Francisco, CA  94127
   United States