| Internet-Draft | DKIM2 Sender Policy | October 2026 |
| Chuang & Gondwana | Expires 22 April 2027 | [Page] |
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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 22 April 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
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 [RFC9989] combines a domain owner's enforcement policy published via DNS plus the concept of what is to be validated which is around [RFC5322] From alignment. To authenticate the email, DMARC uses DKIM [RFC6376] and SPF [RFC7208] 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.¶
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 [RFC2119]. These words take their normative meanings only when they are presented in ALL UPPERCASE.¶
Email message transport and message format are defined in SMTP [RFC5321] and Internet Message Format [RFC5322]. The parties to email transport are defined in Email Architecture [RFC5598]. 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 [RFC9989] 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 [RFC5598] 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.¶
This document updates DMARC [RFC9989] to support DKIM2 draft-ietf-dkim-dkim2-spec with the following considerations for compatibility and security. Specifically, this modifies DMARC [RFC9989] 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 [RFC9989] Section 5.3.1 defines the [RFC5322] 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 [RFC5322] From header field, potentially there may be multiple addresses that can supply the author domains. [RFC5598] 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 [RFC5598] author and instead represents identities of relay forwarders that presumably work in service of the [RFC5598] author. When possible, the [RFC5598] author's sender policy SHOULD be used instead, using the [RFC5322] 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 [RFC9989] 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 [RFC9989] 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 [RFC9989]:¶
This document generalizes DMARC [RFC9989] enforcement sender policies to be used for any failing domain owner's constraint/validation subject to local policy, and not just for alignment. Other [RFC9989] DNS policy record tags are specified for DKIM2 without further interpretation.¶
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 [RFC9989] 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:¶
DomainKeys Identified Mail v2 draft-ietf-dkim-dkim2-spec.¶
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 Section 2.2.2, 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 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 signatures are present and the chain of custody verifies. The expected domain should be present.¶
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.¶
DMARC alignment non-normatively implies "ownership" of the message though this becomes potentially muddled with DKIM2. Relay forwarding intermediaries may rewrite the [RFC5322] 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 Section 2.1.¶
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 [RFC9989] Section 3.2.10 between the [RFC5322] 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 [RFC9989] 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.¶
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 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 Section 2.1 subject to local policy.¶
This flag requests that this message not be sent to more than one recipient.¶
Requests that MTA relays not send the message to more than one recipient.¶
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.¶
exploded¶
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 [RFC5322] From to support maintaining DMARC alignment.¶
Requests that MTA relays not modify the message.¶
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.¶
N/A¶
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 [RFC8601] "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.¶
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 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.¶
The following are non-normative examples meant to illustrate this specification.¶
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:¶
_dmarc.originator.example:
v=DMARC1; p=quarantine; auth=dkim2,dkim,spf
_dmarc.destination.example:
v=DMARC1; p=reject; auth=dkim2,dkim,spf
¶
Header fields before destination.example:¶
From: user@originator.example
DKIM2-Signature: i=1; d=originator.example; mf=user@originator.example;
rt=user@destination.example;
¶
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 [RFC5322] 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:¶
_dmarc.originator.example:
v=DMARC1; p=quarantine; auth=dkim2,dkim,spf; rua=mailto:report@originator.example
_dmarc.forwarder.example:
v=DMARC1; p=reject; auth=dkim2,dkim,spf; rua=mailto:report@forwarder.example
_dmarc.destination.example:
v=DMARC1; p=quarantine; auth=dkim2,dkim,spf
¶
Header fields before destination.example:¶
DKIM2-Signature: i=1; d=originator.example;
mf=user@originator.example; rt=user@forwarder.example
From: user@forwarder.example
DKIM2-Signature: i=2; d=forwarder.example; f=feedback;
mf=user@forwarder.example; rt=user@destination.example;
¶
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:¶
_dmarc.originator.example:
v=DMARC1; p=quarantine;
_dmarc.forwarder.example:
v=DMARC1; p=quarantine; auth=dkim2,dkim,spf
_dmarc.destination.example:
v=DMARC1; p=quarantine; auth=dkim2,dkim,spf
¶
Header fields before destination.example:¶
From: user@originator.example
DKIM-Signature: d=originator.example
DKIM2-Signature: i=1; d=forwarder.example;
mf=user@forwarder.example; rt=user@destination.example;
¶
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:¶
_dmarc.originator.example:
v=DMARC1; p=quarantine
_dmarc.forwarder.example:
v=DMARC1; p=reject
¶
Header fields:¶
From: user@originator.example
DKIM2-Signature: i=1; d=originator.example;
mf=user@originator.example; rt=user@forwarder.example
¶
Thanks go to Todd Herr for clarifying how to update [RFC9989]. Many thanks go to Richard Clayton for feedback on the authenticated identifier selection.¶