DKIM2 Sender Policy

1.1. Terminology and Definitions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].¶

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 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 a "entity or organization that receives and processes email" which 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 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 relay and add one or more DKIM2 signature along with sender constraints and validations.¶

2.1. DMARC Domain Owner Policy

DMARC [RFC9989] section 5.3.1 defines the RFC5322 From header address as supplying the apparent author domain. That domain is then used to lookup 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. Section 10 of draft-ietf-dkim-dkim2-spec calls for the most recent signature (highest i=) to be validated, which implies usage of the RFC5322 From header field apparent at that i=. That signature and From can be sufficient for authentication and replay prevention, but does not recover the Originator's intent if there is relay forwarding. [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 represent 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 MUST be successfully validated for the DMARC evaluation of DKIM2. Alternatively, based on local policy, the apparent RFC5322 From header field at the most recent signature (highest i=) MAY be used instead. 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]:¶

• reject¶

• quarantine¶

• none¶

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.¶

2.2. DMARC Authentication with DKIM2

This modifies DMARC to add DKIM2 as as authentication mechanism for determining authenticated identifiers in DMARC [RFC9989] section 4.3 and to allow 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 a SMTP MTA sender and receiver, meaning what authentication methods 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 [RFC6376].¶

dkim2:

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

spf:

Sender Policy Framework [RFC7208].¶

Usage of "auth=" tag is completely optional. If not specified, relying parties MAY assume that both DKIM and SPF are supported. Notably by default DKIM2 is not specified by default. If "auth=" is supplied, then DKIM2 is meant to be explicitly declared so that it can be used as a capability declaration mechanism. "auth=" can also be used to declare that a MTA does not support some authentication method. 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.¶

Mail Receivers that evaluate DKIM2 for DMARC MUST only use validated DKIM2 signatures to protect any policy evaluation or enforcement from being spoofed. More specifically, receivers that process DKIM2 for DMARC MUST validate all DKIM2 signature header fields that form the chain of custody as described in draft-ietf-dkim-dkim2-spec section 11. If the chain of custody validates, then this is considered a DKIM2 authentication "pass" for DMARC. Policy evaluation MUST proceed only after this. Otherwise if it does not validate, and if DKIM2 header fields are present, the result is "fail", otherwise without header fields, the result is "neutral".¶

Next such Mail Receivers checks 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. As described earlier in Section 2.1 this From and signature signature at either Originator (i=1) or the most recent (i=n). 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.¶

3.1. DMARC Alignment With DKIM2

This introduces a DKIM2 signature flag "unaligned" to control the DMARC RFC9989 Author Domain alignment behavior with the Authenticated Identifier. By default the Mail Receiver expects relaxed alignment between the Author Domain and the DKIM2 signature d= domain as noted that earlier in Section 2.2. Because there may be multiple DKIM2 signatures per domain as described in draft-ietf-dkim-dkim2-spec section 9.3, the d= can be found on the signature with the "rt=" and "mf=" tags for alignment checks, corresponding to the SMTP transaction boundary. Other signatures are excluded from alignment checks. If the "unaligned" flag is published on the boundary signature, then no DMARC alignment validation is expected and DMARC alignment validation for that signature will indicate "pass". Alignment non-normatively implies "ownership" of the message. For compatibility with RFC9989, SMTP MTA relays SHOULD modify RFC5322 From address to support relaxed alignment with DKIM2 signer d= domain to support non-DKIM2 (DKIM and/or SPF) Mail Receivers. Alternatively when the Mail Receiver supports DKIM2, the relay MAY instead publish an "unaligned" flag. The Mail Receiver MAY fetch the DMARC DNS policy from RFC5322 From provided by the Originator and associated with the DKIM signature.¶

When "unaligned" is set on the i=1 DKIM2 signature, this MAY be used to indicate that a message originated elsewhere, and the i=1 signer declines to take "ownership" of that message. This MUST only be done when the original message entering DKIM2 relay is DMARC aligned with passing DKIM signature meaning the original authenticated message can be verified by some other DKIM2 Mail Receiver.¶

3.2. DKIM2 Flag Evaluation

Besides the "unaligned" flag described earlier, DKIM2 supports the flags described in draft-ietf-dkim-dkim2-spec section 8.10. This section describes the policy behavior of these flags, its 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 it's 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.¶

3.3. Support for DKIM2 Unaware Relays

Because the DMARC RFC9989 "auth=" tag can serve as a DKIM2 capabilities mechanism, a DKIM2 aware SMTP relay sender can check if the receiver supports DKIM2. If the receiver does not, the sender can choose to bounce the message, or continue to relay onwards. If relaying, the relay sender MAY choose to delete all DKIM2 signature header fields, or terminate the DKIM2 chain of custody by declaring DKIM2 signature header field "rt=" tag without envelope recipient addresses. Subsequent DKIM2 receivers can see that a message was intentionally sent to a non DKIM2 domain via the terminated chain of custody, and that address membership comparison between "rt" against RCPT TO is unnecessary. Participants of this approach essentially allows all DKIM2 receivers to more deterministically apply anti-replay enforcements without solely relying on local policy to suppress flagging benign DKIM2 to DKIM traffic. Moreover preserving the DKIM2 signature header fields propagate DKIM2 policy to subsequent DKIM2 relays even after traversing a DKIM-only relay, such as "donotmodify", "donotexplode" and "feedback" policies. The DKIM2 signature header fields also provide delivery forensics value to Mail Receivers.¶

4.1. 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 restrain 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.¶

When "unaligned" is set on the i=1 DKIM2 signature to indicate introduction of a DKIM message to DKIM2, the DKIM2 relay can validate and provide evidence that the message was not replayed. This is in addition to the DMARC evidence described in Section 3.1. The relay can check that one of the RFC5322 To or Cc header field addresses, which are the signed recipients, matches one of the SMTP RCPT TO addresses which are the envelope recipients. It can check that one of the signed recipient domains relaxed matches the i=1 DKIM2 d= domain. Subsequent Mail Receivers can similarly check the signed recipient domains match the i=1 DKIM2 domain.¶

Alternatively a DKIM2 relay may instead rewrite RFC5322 From with alignment. The relay however takes "ownership" of the message, and any prior authentication will be ignored by subsequent DKIM2 Mail Receivers.¶

4.2. Examples

The following are non-normative examples meant to illustrate the earlier specification.¶

_dmarc.originator.example:
    v=DMARC1; p=quarantine; auth=dkim2,dkim,spf

_dmarc.destination.example:
    v=DMARC1; p=reject; auth=dkim2,dkim,spf

    From: user@originator.example
    DKIM-Signature: d=originator.example
    DKIM2-Signature: i=1; d=forwarder.example; mf=user@forwarder.example; rt=user@destination.example;

_dmarc.originator.example:
    v=DMARC1; p=quarantine; auth=dkim2,dkim,spf; rua=report@originator.example

_dmarc.forwarder.example:
    v=DMARC1; p=reject; auth=dkim2,dkim,spf; rua=report@forwarder.example

_dmarc.destination.example:
    v=DMARC1; p=quarantine; auth=dkim2,dkim,spf

    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=reporting; mf=user@forwarder.example; rt=user@destination.example;

_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

    From: user@originator.example
    DKIM-Signature: d=originator.example
    DKIM2-Signature: i=1; d=forwarder.example; f=unaligned; mf=user@forwarder.example; rt=user@destination.example;

_dmarc.forwarder.example:
    p=quarantine; auth=dkim2,dkim,spf

    From: user@originator.example
    DKIM2-Signature: i=1; d=originator.example; mf=user@originator.example; rt=