]> Google, Inc.

1600 Amphitheatre Parkway Mountain View California 94043 United States of America weihaw@google.com

Fastmail Pty Ltd

Level 2, 114 William Street Melbourne Victoria 3000 Australia +61 457 416 436 brong@fastmailteam.com

DKIM Working Group DKIM2 DMARC This document updates DMARC RFC 9989 for DKIM2. In particular DKIM2 verification supports MTA relay forwarding with message modifications through multiple MTAs, so this updates DMARC to support those scenarios as well. While DMARC defines a RFC 5322 From alignment constraint with an enforcement policy if validation fails, this generalizes and separates enforcement policy from constraint validation policies. This provides a mechanism for MTAs to declare support for DKIM2 through the DMARC DNS policy record that helps secure DKIM2 from downgrade attacks.

Introduction DKIM2 draft-ietf-dkim-dkim2-spec defines a new way to authenticate email with a focus to support SMTP MTA relay forwarding and message mutation. It records the relay mutation as "recipes" and envelope identities as part of its digital signature, and those "recipes" can be reversed to recover prior signatures. Signature header fields may carry flags "donotmodify" and "donotexplode" which are sender defined constraints requested of forwarders. DMARC combines a domain owner's enforcement policy published via DNS plus the concept of what is to be validated which is around From alignment. To authenticate the email, DMARC uses DKIM and SPF but not DKIM2. This document updates DMARC to permit the use of DKIM2. DMARC focused on originating senders but really didn't consider intermediary relaying forwarders to the Mail Receiver. As DKIM2 explicitly supports relaying forwarders with mutations, this document updates DMARC to support those scenarios as well. In addition, this calls for distinguishing domain owner's constraint policies from the enforcement policy, and defining an explicit separation of specification behavior to make consistent where to read policies. DMARC will be defined to manage and publish domain level sender policies in its DNS policy. This includes enforcement and authentication policies. DKIM2 will define per message constraints by publishing signature flags. These are declarations by the DKIM2 signer of their sender policies. Certain constraints can be validated by the Mail Receiver, and when they fail, the Mail Receiver can use the published enforcement behavior to determine the disposition of the email message. This document updates these sender constraint policies and defines the interactions between each other, taking into account the sender domain level enforcement policies. Besides consistency, this normative explicit specification of DKIM2 and DMARC behavior will help improve the security of email authentication. As not all behavior need be normative, this also describes updates to the DKIM2 best current practices draft-ietf-dkim-dkim2-bcp document with recommendations that follow this document especially in regards to DKIM2 and DMARC interactions. As such this provides illustrative and non-normative example scenarios.

Terminology and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in . These words take their normative meanings only when they are presented in ALL UPPERCASE. Email message transport and message format are defined in SMTP and Internet Message Format . The parties to email transport are defined in Email Architecture . That document notes that SMTP MTAs are SMTP relays that take on different roles when serving as the mail handling service agent. The first mail handling service that introduces the message is the message "Originator" while the last mail handling service that no longer relays the message onwards is the "Final Receiver". There are intermediary relays that are neither Originator nor Final Receiver. While that document never uses the term "forwarder", this document adopts the commonly used "forwarding relay" to describe those MTA intermediaries that are neither Originator nor Final Receiver. DMARC defines the role of a "Mail Receiver" that is an "entity or organization that receives and processes email" which this document uses for processing DMARC policy. As such, this document also acknowledges that SMTP MTAs may perform the dual role of sending and receiving email i.e. SMTP delivery of an outbound message or perform delivery of an inbound message. Unfortunately receiver and receiving have overlapping but different meanings. This document clarifies by using "Final Receiver" to describe the mail handling service that takes the final delivery of the message i.e. without further relaying as well as a "Mail Receiver" that evaluates DMARC policy. DKIM2 draft-ietf-dkim-dkim2-spec defines a chain of custody to indicate DKIM2 signatures in a relayed message. Email Architecture observed that SMTP MTA relays are coupled to ADministrative Management Domains (ADMDs) where each ADMD is defined by a different set of policies. ADMDs can choose to publish a DMARC sender policy. Each ADMD can have one or more relays and add one or more DKIM2 signatures along with sender constraints and validations.

Modification to DMARC This document updates DMARC to support DKIM2 draft-ietf-dkim-dkim2-spec with the following considerations for compatibility and security. Specifically, this modifies DMARC Section 4.3 to add DKIM2 as an authentication mechanism for determining authenticated identifiers. As noted earlier, this document separates domain owner's constraint and validation policies from the enforcement and authentication policies. This Section specifies the latter domain level policies through DNS to act as a side-channel outside of the message such that it cannot be downgraded.

DMARC Domain Owner Policy DMARC Section 5.3.1 defines the From header address as supplying the apparent author domain. That domain is then used to look up the domain owner's DMARC policy record. Because DKIM2 supports one or more intermediate relay forwarders that can modify messages including the From header field, potentially there may be multiple addresses that can supply the author domains. author differs from the DMARC author in that it is the agent that introduces the message to be SMTP relayed starting at the Originator's MTA relay. Because From header fields can be rewritten, the DMARC apparent author domain potentially does not represent the author and instead represents identities of relay forwarders that presumably work in service of the author. When possible, the author's sender policy SHOULD be used instead, using the From header field that was recovered at DKIM2 signature i=1 using the description in draft-ietf-dkim-dkim2-spec in Section 10.2. If so, the entire chain of custody SHOULD be successfully validated for the DMARC evaluation of DKIM2. Once the author domain is found, the domain owner's DMARC policy record is fetched and interpreted using the procedures in Section 4.10 of DMARC including DMARC reporting. The domain owner's policy comes from DNS policy because it acts as a side-channel outside of the content of the message (besides the identity of the RFC5322.From). DMARC defines a domain owner's enforcement policy to be used when RFC5322.From alignment fails. These come from the DMARC policy record DNS policy tags "p" and "sp" with the value and behavior as defined by :

• reject
• quarantine
• none

This document generalizes DMARC enforcement sender policies to be used for any failing domain owner's constraint/validation subject to local policy, and not just for alignment. Other DNS policy record tags are specified for DKIM2 without further interpretation.

DMARC Authentication with DKIM2

DMARC Policy Auth Tag This modifies DMARC to allow an SMTP MTA to declare which authentication method it supports to prevent authentication downgrade or spoofing attacks. Threat actors can become Man-In-The-Middle (MitM) relays that maliciously modify emails and strip the DKIM2 or DKIM signatures. Alternatively the threat actor can take advantage of receivers that support alternate vulnerable authentication methods and spoof victim senders. To prevent downgrade or spoofing attacks, this defines a method for MTAs to publish what authentication methods it supports as a DMARC Section 4.7 DNS policy record tag "auth=". This flag provides a declaration of authentication methods supported as both an SMTP MTA sender and receiver, meaning what authentication methods are potentially present in the messages when sent, and what authentication methods it will process as a receiver. "auth=" takes a comma separated list of supported authentication methods:

dkim:

DomainKeys Identified Mail .

dkim2:

DomainKeys Identified Mail v2 draft-ietf-dkim-dkim2-spec.

spf:

Sender Policy Framework .

Usage of "auth=" tag is completely optional. If not specified, relying parties MAY assume that both DKIM and SPF are supported. Because this declaration is optional, MTAs may choose not to use this tag but still support an authentication method such as DKIM2 during the bring-up period. Notably, DKIM2 is not specified by default. DKIM2 is meant to be explicitly declared so that it can be used as a capability declaration mechanism. Senders may declare with the "auth=" tag a set of specified authentication methods. If a message purportedly from the sender arrives using the methods in , the mail receiver can evaluate that the expected authentication methods are present. If the expected authentication is missing, the mail receiver SHOULD apply the sender's enforcement policy. Relaying may, in the course of normal operation, hide evidence of authentication, so the following should be taken into account.

dkim:

DKIM signature is present. Because a given signature may be rewritten (i.e. deleted and replaced by another) by intermediate relays, the signature may contain a different domain than expected.

dkim2:

DKIM2 signatures are present and the chain of custody verifies. The expected domain should be present.

spf:

Cannot be verified unless the immediate sender is the expected domain. The message does not contain independently verifiable evidence of SPF authentication.

An explicit "auth=" tag can also declare that an MTA does not support some authentication method, and a mail receiver SHOULD NOT evaluate the expected authentication method when the authentication method is not present nor use that method for other applications.

DKIM2 Alignment DMARC alignment non-normatively implies "ownership" of the message though this becomes potentially muddled with DKIM2. Relay forwarding intermediaries may rewrite the From header field. DKIM2 draft-ietf-dkim-dkim2-spec chain of custody evaluation can recover prior versions of the From header all the way back to the Originator (i=1). The motivation for using the From header and the DKIM2 signature d= domain at the Originator and not other versions, is described earlier in . Mail Receivers that evaluate DKIM2 for DMARC validate the DKIM2 signatures that form the chain of custody as described in draft-ietf-dkim-dkim2-spec Section 11 to protect any policy evaluation or enforcement from being spoofed. If the chain of custody validates, then this is considered a DKIM2 authentication "pass" as input to the alignment test in the next paragraph. Otherwise if the chain of custody does not validate, and if DKIM2 header fields are present, the result is "fail", otherwise without header fields, the result is "neutral". Next, Mail Receivers check the Identifier Alignment as described in Section 3.2.10 between the From header field Author domain and the DKIM2 signature d= domain at the Originator (i=1). For Identifier Alignment, this document uses relaxed domain matching between the DKIM2 signature d= and Author domain as described in draft-ietf-dkim-dkim2-spec Section 9.4 and Section 3.2.10.1 and Section 4.4. Policy evaluation MUST proceed only after this alignment check. There may be multiple DKIM2 signatures per ADMD as described in draft-ietf-dkim-dkim2-spec Section 9.3, and the alignment check is meant to be processed on the SMTP transaction boundary. More specifically the alignment check SHOULD only be performed on signatures with the "rt=" and "mf=" tags, and exclude signatures with the "nd=" tag.

Modification to DKIM2 This document proposes that all domain owner's constraint and validation policies be controllable by DKIM2 signature flags. This permits per message control which is useful in a number of different contexts such as policy rollout or for differentiating message applications such as between transactional and promotional emails. With this flexibility comes extra coordination between different sender constraint and validation policies and between different signers in a DKIM2 chain. To reduce that burden, this provides sensible defaults when the DKIM2 signature flag is not present.

DKIM2 Flag Evaluation DKIM2 supports the flags described in draft-ietf-dkim-dkim2-spec Section 8.10. This Section describes the policy behavior of these flags, their interactions with other flags, and across prior and successive flags. The presence of a flag on a signature can indicate that the signer MTA relay makes a "constraint" request to subsequent Mail Receivers. Mail Receivers SHOULD respect the "constraint". If it does not due to local policy, that Mail Receiver MUST NOT relay the message outside of its control meaning its ADMD. Presence of a flag on a signature can also indicate that the Mail Receivers SHOULD perform "validation" to see if prior relaying MTAs respected the requested "constraint". If the validation fails, then the Mail Receiver SHOULD apply the enforcement policy described in subject to local policy.

exploded This flag reports that this message is being sent to more than one email address.

constraint:

Mail Receivers MAY use this report to suppress replay as the message has been sent to multiple email addresses.

validation:

N/A

flag interaction:

donotexplode

donotexplode This flag requests that this message not be sent to more than one recipient.

constraint:

Requests that MTA relays not send the message to more than one recipient.

validation:

Mail Receivers SHOULD validate whether the message was sent to more than one recipient, and examine signatures to see if the "exploded" flag was set after the "donotexplode" flag. If so, then validation has failed.

flag interaction:

exploded

donotmodify This flag requests that this message not be modified. More specifically this requests no body changes or header fields be modified with the exception of From to support maintaining DMARC alignment.

constraint:

Requests that MTA relays not modify the message.

validation:

Mail Receivers SHOULD check if the message was modified after the "donotmodify" flag. This MAY be done by checking if the corresponding Message-Instance recipes indicate any body changes or unexplained header field changes. If so, then validation has failed.

flag interaction:

N/A

feedback This flag requests that the signature signer get a DMARC report. The details of this flag are TBD.

feedhere This flag requests feedback about how this message is handled during delivery and thereafter is relayed via this hop. The details of this flag are TBD.

Support for DKIM2 Unaware Relays Because the "auth=" tag can serve as a DKIM2 capabilities mechanism, a DKIM2 aware SMTP receiver MAY check if the sender supports DKIM2 when authentication fails if it wishes to support interoperability with DKIM intermediaries. The problem is that traffic that passes through a DKIM intermediary, but originates at a DKIM2 sender and comes back to a DKIM2 receiver, may not authenticate. This occurs when the intermediary does not add a DKIM2 signature header field that maintains the chain of custody. The DKIM intermediary may even modify the message which would not be explained by DKIM2 Message-Instance header fields. A DKIM2 receiver MAY choose to evaluate DKIM2 signatures to look for such DKIM intermediaries, and use local policy, to override the DKIM2 authentication failure. The receiver can look at the DKIM2 signature header fields and find the most recent signature. There it will find the "rt=" tag recipients' addresses. The receiver looks up the DMARC policies for those recipients to see if any do not support DKIM2 via the "auth=" capability tag, which could explain the DKIM2 authentication failure. If explained, it overrides the DKIM2 chain of custody authentication failures, and reports the override as an "policy" result. While the specification permits multiple recipients, we expect the common case will be a single recipient. If the DKIM2 receiver wishes to relay forward a message that did not DKIM2 authenticate because of some DKIM intermediary, it MUST NOT append a new DKIM2 signature over the existing broken chain. If it insists on adding a new signature, then it MUST restart the chain by deleting all prior DKIM2 signature header fields. Alternatively it may relay forward without adding a new DKIM2 signature. This preserves the earlier DKIM2 signature header fields to propagate DKIM2 policy, even if broken, to subsequent DKIM2 relays and also provide delivery forensics value to Mail Receivers.

Modification to Best Current Practices This document calls for the update to the DKIM2 best current practices draft-ietf-dkim-dkim2-bcp document in the following way. The BCPs are non-normative recommendations.

DKIM2 Interop with DKIM DKIM2 participants should be very careful about using these features that enable interop between DKIM-only participants due to the potential of introduced replay risks. This is particularly true when a DKIM2 participant accepts DKIM traffic and signs as a DKIM2 message. It is incumbent on the DKIM2 relay that introduces DKIM traffic that the traffic is free of replay, because downstream receivers cannot use DKIM2 (i.e. validation of the signed "rt=" recipient against envelope recipient) to prevent replay. These DKIM interop features should be limited to DKIM2 bring up and when the DKIM-only participant is well understood such as legacy enterprise services. Relays should refrain from extending the DKIM2 signature chain of custody if it was terminated. Such a message has left DKIM2, traversed a DKIM-only relay and is returning to a DKIM2 relay. If a DKIM-DKIM2 forwarder fails to protect against replay, they are well identified by their DKIM2 signature.

Examples The following are non-normative examples meant to illustrate this specification.

DKIM2 → DKIM2 This represents a directly relayed message i.e. without any intermediaries. The Originator MTA can look up the DMARC DNS policy at _dmarc.destination.example to see that it supports DKIM2. The destination MTA can look up the DMARC policy using the Author Domain of originator.example. DMARC DNS policy: Header fields before destination.example:

DKIM2 → DKIM2 → DKIM2 This represents a message relayed through an intermediate relay forwarder. That forwarder requests reporting via DKIM2 signature flag. The Mail Receiver destination.example follows the recommendation in this document, and uses the recovered From associated with the signature i=1 with the Author Domain originator.example. It fetches p=quarantine policy and finds a request for DMARC aggregate reporting to be sent to report@originator.example. It also fetches the policy at forwarder.example, and finds a request for DMARC aggregate reporting to be sent to report@forwarder.example. DMARC DNS policy: Header fields before destination.example:

DKIM → DKIM2 → DKIM2 This represents a message originating with DKIM only that is then relayed through a DKIM2 aware intermediary to a DKIM2 receiver. The DKIM2 aware intermediary adds a DKIM2 signature, starting the DKIM2 chain of custody, and taking ownership of the message from a DKIM2 perspective. The DKIM2 receiver treats the message as being originated at the DKIM2 intermediary. DMARC DNS policy: Header fields before destination.example:

DKIM2 → DKIM → DKIM2 This represents a message being relayed through a DKIM only intermediate MTA. When the DKIM2 aware receiver sees a verification failure, it looks at the most recent DKIM2 signature "rt=" address. It extracts the forwarder.example from the address, looks up the DMARC policy there, and finds that the intermediary does not support DKIM2. The receiver chooses to override the DKIM2 authentication failure, designating it with a "policy" result. DMARC DNS policy: Header fields:

References Normative References This document describes the Domain-based Message Authentication, Reporting, and Conformance (DMARC) protocol. DMARC permits the owner of an email's Author Domain to enable validation of the domain's use to indicate the Domain Owner's or Public Suffix Operator's message handling preference regarding failed validation and to request reports about the use of the domain name. Mail-receiving organizations can use this information when evaluating handling choices for incoming mail. This document obsoletes RFCs 7489 and 9091. This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. [STANDARDS-TRACK] DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay, or one of their agents. DKIM separates the question of the identity of the Signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature. This memo obsoletes RFC 4871 and RFC 5672. [STANDARDS-TRACK] Email on the Internet can be forged in a number of ways. In particular, existing protocols place no restriction on what a sending host can use as the "MAIL FROM" of a message or the domain given on the SMTP HELO/EHLO commands. This document describes version 1 of the Sender Policy Framework (SPF) protocol, whereby ADministrative Management Domains (ADMDs) can explicitly authorize the hosts that are allowed to use their domain names, and a receiving host can check such authorization. This document obsoletes RFC 4408. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol for "split-UA" (User Agent) mail reading systems and mobile environments. [STANDARDS-TRACK] This document specifies a message header field called "Authentication-Results" for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users or to make sorting and filtering decisions. This document obsoletes RFC 7601. Informative References Over its thirty-five-year history, Internet Mail has changed significantly in scale and complexity, as it has become a global infrastructure service. These changes have been evolutionary, rather than revolutionary, reflecting a strong desire to preserve both its installed base and its usefulness. To collaborate productively on this large and complex system, all participants need to work from a common view of it and use a common language to describe its components and the interactions among them. But the many differences in perspective currently make it difficult to know exactly what another participant means. To serve as the necessary common frame of reference, this document describes the enhanced Internet Mail architecture, reflecting the current service. This memo provides information for the Internet community.

Acknowledgments {#acks numbered="false"} Thanks go to Todd Herr for clarifying how to update . Many thanks go to Richard Clayton for feedback on the authenticated identifier selection.