Tech-invite   3GPPspecs   RFCs   SIP   Search in Tech-invite

in Index   Prev   Next
in Index   Prev   Next  Group: DMARC

RFC 8601

Message Header Field for Indicating Message Authentication Status

Pages: 54
Proposed STD
Obsoletes:  7601
Part 4 of 4 – Pages 39 to 54
First   Prev   None

Top   ToC   RFC8601 - Page 39   prevText
8.  References

8.1.  Normative References

   [ABNF]     Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,

              Klyne, G., Nottingham, M., and J. Mogul, "Registration
              Procedures for Message Header Fields", BCP 90, RFC 3864,
              DOI 10.17487/RFC3864, September 2004,

   [MAIL]     Resnick, P., Ed., "Internet Message Format", RFC 5322,
              DOI 10.17487/RFC5322, October 2008,

   [MIME]     Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part One: Format of Internet Message
              Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
Top   ToC   RFC8601 - Page 40
   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,

   [RFC6530]  Klensin, J. and Y. Ko, "Overview and Framework for
              Internationalized Email", RFC 6530, DOI 10.17487/RFC6530,
              February 2012, <>.

   [RFC6531]  Yao, J. and W. Mao, "SMTP Extension for Internationalized
              Email", RFC 6531, DOI 10.17487/RFC6531, February 2012,

   [RFC6532]  Yang, A., Steele, S., and N. Freed, "Internationalized
              Email Headers", RFC 6532, DOI 10.17487/RFC6532,
              February 2012, <>.

   [RFC7601]  Kucherawy, M., "Message Header Field for Indicating
              Message Authentication Status", RFC 7601,
              DOI 10.17487/RFC7601, August 2015,

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in
              RFC 2119 Key Words", BCP 14, RFC 8174,
              DOI 10.17487/RFC8174, May 2017,

   [SMTP]     Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              DOI 10.17487/RFC5321, October 2008,

8.2.  Informative References

   [ADSP]     Allman, E., Fenton, J., Delany, M., and J. Levine,
              "DomainKeys Identified Mail (DKIM) Author Domain Signing
              Practices (ADSP)", RFC 5617, DOI 10.17487/RFC5617,
              August 2009, <>.

   [AR-VBR]   Kucherawy, M., "Authentication-Results Registration for
              Vouch by Reference Results", RFC 6212,
              DOI 10.17487/RFC6212, April 2011,

   [ATPS]     Kucherawy, M., "DomainKeys Identified Mail (DKIM)
              Authorized Third-Party Signatures", RFC 6541,
              DOI 10.17487/RFC6541, February 2012,
Top   ToC   RFC8601 - Page 41
   [AUTH]     Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service
              Extension for Authentication", RFC 4954,
              DOI 10.17487/RFC4954, July 2007,

   [AUTH-ESC] Kucherawy, M., "Email Authentication Status Codes",
              RFC 7372, DOI 10.17487/RFC7372, September 2014,

   [DKIM]     Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
              "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
              RFC 6376, DOI 10.17487/RFC6376, September 2011,

   [DMARC]    Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
              Message Authentication, Reporting, and Conformance
              (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,

   [DNS]      Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <>.

   [DNS-IP6]  Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
              "DNS Extensions to Support IP Version 6", STD 88,
              RFC 3596, DOI 10.17487/RFC3596, October 2003,

              Senie, D. and A. Sullivan, "Considerations for the use
              of DNS Reverse Mapping", Work in Progress,
              March 2008.

              Delany, M., "Domain-Based Email Authentication Using
              Public Keys Advertised in the DNS (DomainKeys)", RFC 4870,
              DOI 10.17487/RFC4870, May 2007,

   [DSN]      Moore, K. and G. Vaudreuil, "An Extensible Message Format
              for Delivery Status Notifications", RFC 3464,
              DOI 10.17487/RFC3464, January 2003,
Top   ToC   RFC8601 - Page 42
              Crocker, D., "Internet Mail Architecture", RFC 5598,
              DOI 10.17487/RFC5598, July 2009,

              Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,

              4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,

   [POP3]     Myers, J. and M. Rose, "Post Office Protocol - Version 3",
              STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996,

   [RFC5451]  Kucherawy, M., "Message Header Field for Indicating
              Message Authentication Status", RFC 5451,
              DOI 10.17487/RFC5451, April 2009,

   [RFC6008]  Kucherawy, M., "Authentication-Results Registration for
              Differentiating among Cryptographic Results", RFC 6008,
              DOI 10.17487/RFC6008, September 2010,

   [RFC6577]  Kucherawy, M., "Authentication-Results Registration Update
              for Sender Policy Framework (SPF) Results", RFC 6577,
              DOI 10.17487/RFC6577, March 2012,

   [RFC7001]  Kucherawy, M., "Message Header Field for Indicating
              Message Authentication Status", RFC 7001,
              DOI 10.17487/RFC7001, September 2013,

   [RFC7410]  Kucherawy, M., "A Property Types Registry for the
              Authentication-Results Header Field", RFC 7410,
              DOI 10.17487/RFC7410, December 2014,

   [RFC8301]  Kitterman, S., "Cryptographic Algorithm and Key Usage
              Update to DomainKeys Identified Mail (DKIM)", RFC 8301,
              DOI 10.17487/RFC8301, January 2018,
Top   ToC   RFC8601 - Page 43
   [RRVS]     Mills, W. and M. Kucherawy, "The Require-Recipient-Valid-
              Since Header Field and SMTP Service Extension", RFC 7293,
              DOI 10.17487/RFC7293, July 2014,

   [SECURITY] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              DOI 10.17487/RFC3552, July 2003,

   [SENDERID] Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail",
              RFC 4406, DOI 10.17487/RFC4406, April 2006,

              Melnikov, A., "Authentication-Results Registration for
              S/MIME Signature Verification", RFC 7281,
              DOI 10.17487/RFC7281, June 2014,

   [SPF]      Kitterman, S., "Sender Policy Framework (SPF) for
              Authorizing Use of Domains in Email, Version 1", RFC 7208,
              DOI 10.17487/RFC7208, April 2014,

   [VBR]      Hoffman, P., Levine, J., and A. Hathcock, "Vouch By
              Reference", RFC 5518, DOI 10.17487/RFC5518, April 2009,
Top   ToC   RFC8601 - Page 44
Appendix A.  Legacy MUAs

   Implementers of this specification should be aware that many MUAs are
   unlikely to be retrofitted to support the Authentication-Results
   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
   specification and its successors continue to be 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: Header Field Not Present
Top   ToC   RFC8601 - Page 45
   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 (1) the message authentication services
   were not available at the time of delivery, (2) no service is
   provided, or (3) the MTA is not in compliance with this

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   ToC   RFC8601 - Page 46
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   ToC   RFC8601 - Page 47
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);
        Authentication-Results:; iprev=pass
        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 themselves to the MTA via a method specified
   in [AUTH], and both SPF and "iprev" checks were done and passed.  The
   MUA could extract and relay this extra information if desired.

   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 a "pass" result from the SPF check.
Top   ToC   RFC8601 - Page 48
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   ToC   RFC8601 - Page 49
   The second MTA,, reports that it did a DKIM
   test (which passed).  Again, additional data about one of the tests
   are 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 a message into from a user on a dial-up connection  The
   user appears to be legitimate, as they had a valid password allowing
   authentication at the border MTA using SMTP AUTH.  The SPF test
   failed, since has not granted's dial-up
   network authority to relay mail on its behalf.  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   ToC   RFC8601 - Page 50
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   ToC   RFC8601 - Page 51
   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 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   ToC   RFC8601 - Page 52
Appendix C.  Operational Considerations about Message Authentication

   Implementation of the Authentication-Results header field 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
   header field and its deployment to date are based on that model.  The
   assumption satisfies several common ADMD requirements:

   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 inside of an ADMD 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 cryptographic
       verification (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
Top   ToC   RFC8601 - Page 53
   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, 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 7601

   o  Added IANA registration for DKIM "a" and "s" properties.

   o  Included EAI guidance.

   o  Adjusted some ABNF tokens and names for easier inclusion by other

   o  Made minor editorial adjustments.

   o  Deprecated entries from RFCs that are now Historic.

   o  Erratum 4671 resolved.

   o  Erratum 5435 resolved.
Top   ToC   RFC8601 - Page 54

   The author wishes to acknowledge the following individuals for their
   review and constructive criticism of this document: Kurt Andersen,
   Seth Blank, Tim Draegen, Scott Kitterman, John Levine, and Alessandro

Author's Address

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