DKIM2 Message Examples

1.3.1. Direct delivery

This is the common case for email. The initial ADMD has a message to be delivered somewhere, and the ADMD that is on the receiving end of that SMTP transaction is that message's final destination.¶

Transaction: Origin to destination¶

====
MAIL FROM: <a@origin.example>
RCPT TO: <b@destination.example>
DATA
DKIM2-Signature: i=1; d=origin.example; s=key1; mf=a@origin.example;
    rt=b@destination.example; b=PASS
From: <a@origin.example>

A Message!
====

In the initial transaction of a DKIM2 signed message, the signing domain must be aligned with the domain in 5322.From. Note that the mf= and 5321.MailFrom are equal, but they do not need to be equal to the 5322.From.¶

In every DKIM2 transaction, it is required that the topmost (highest i=) DKIM2-Signature's signing domain be aligned with the domain in that signature's mf= tag, and that the mf= tag be equal to the 5321.MailFrom for that transaction. Alignment of these domains is a mitigation for backscatter, and it is left to the system operator to prevent local backscatter (ex. acct1@example.com misusing 5321.MailFrom of acct2@example.com).¶

In every DKIM2 transaction, it is required that the topmost DKIM2-Signature's rt= be equal to the 5321.RcptTo for that transaction. This equality is a mitigation for message replay, by making delivery to any other mailbox (even at the same host) be not authenticated by DKIM2. Acceptance of messages that don't authenticate with DKIM2 is a matter of local policy.¶

1.3.2. Autoforwarding (no alteration)

This is often called the "alumni forwarder" scenario, but many other forwarding services exist. An ADMD has a message to send, and the destination is an address at another ADMD acting as a forwarding service. The forwarding service resends the message to another ADMD, which is the final destination for the message.¶

In this scenario, it is assumed that the forwarding service does not alter the message at all.¶

Transaction: Origin to forwarder¶

====
MAIL FROM: <a@origin.example>
RCPT TO: <b@alias.example>
DATA
DKIM2-Signature: i=1; d=origin.example; s=key1; mf=a@origin.example;
    rt=b@alias.example; b=PASS
From: <a@origin.example>

A Message!
====

Transaction: Forwarder to destination¶

====
MAIL FROM: <b@alias.example>
RCPT TO: <c@destination.example>
DATA
DKIM2-Signature: i=2; d=alias.example; s=key4321; mf=b@alias.example;
    rt=c@destination.example; b=PASS
DKIM2-Signature: i=1; d=origin.example; s=key1; mf=a@origin.example;
    rt=b@alias.example; b=PASS
From: <a@origin.example>

A Message!
====

In the forwarding transaction, the i=2 signing domain is aligned to the 5321.MailFrom and the domain in i=1 rt=. There is no requirement that i=2 signing be aligned with 5322.From.¶

DMARC requirements can be satisfied in both transactions, because there is a passing signature aligned with the 5322.From.¶

1.3.3. Mailing list (no alteration)

This operates like an autoforwarder. The only difference is that these systems are expected to re-deliver to multiple destinations instead of just one.¶

Transaction: Origin to mailing list¶

====
MAIL FROM: <a@origin.example>
RCPT TO: <m@list.example>
DATA
DKIM2-Signature: i=1; d=origin.example; s=key1; mf=a@origin.example;
    rt=m@list.example; b=PASS
From: <a@origin.example>

A Message!
====

Transaction: Mailing list to destination¶

====
MAIL FROM: <m@list.example>
RCPT TO: <b@subscriber.example>
DATA
DKIM2-Signature: i=2; d=list.example; s=key50; mf=m@list.example;
    rt=b@subscriber.example; b=PASS
DKIM2-Signature: i=1; d=origin.example; s=key1; mf=a@origin.example;
    rt=m@list.example; b=PASS
From: <a@origin.example>

A Message!
====

1.3.4. Mailing list (with alteration)

Similar to the non-modifying mailing list case, but with modifications of the message (body, 5322.Subject, etc.) that invalidate the signature in i=1.¶

Transaction: Origin to mailing list¶

====
MAIL FROM: <a@origin.example>
RCPT TO: <m@list.example>
DATA
DKIM2-Signature: i=1; d=origin.example; s=key1; mf=a@origin.example;
    rt=m@list.example; b=PASS
From: <a@origin.example>

A Message!
====

Transaction: Mailing list to destination¶

====
MAIL FROM: <m@list.example>
RCPT TO: <b@subscriber.example>
DATA
DKIM2-Signature: i=2; d=list.example; s=key1; mf=m@list.example;
    rt=b@subscriber.example; b=PASS
DKIM2-Modification: i=2; delta="Appended a line"
DKIM2-Signature: i=1; d=origin.example; s=key50; mf=a@origin.example;
    rt=m@list.example; b=PASS_AFTER_UNDO_MODS
From: <a@origin.example>

A Message!
Click https://list.example/unsubscribe to unsubscribe from this.
====

It is unclear whether the second transaction can be considered to satisfy origin.example's DMARC requirements, as origin.example's signature did not pass on the message as presented.¶

1.3.5. Mailing list (with alteration and From munging)

Further modification, where the mailing list also changes the 5322.From header field to something else. This is done in today's ecosystem to allow for delivery of modified messages sent from domains with DMARC policies.¶

Transaction: Origin to mailing list¶

====
MAIL FROM: <a@origin.example>
RCPT TO: <m@list.example>
DATA
DKIM2-Signature: i=1; d=origin.example; s=key1; mf=a@origin.example;
    rt=m@list.example; b=PASS
From: <a@origin.example>

A Message!
====

Transaction: Mailing list to destination¶

====
MAIL FROM: <m@list.example>
RCPT TO: <b@subscriber.example>
DATA
DKIM2-Signature: i=2; d=list.example; s=key1; mf=m@list.example;
    rt=b@subscriber.example; b=PASS
DKIM2-Modification: i=2;
    delta="Appended a line; From used to be "a@origin.example""
DKIM2-Signature: i=1; d=origin.example; s=key50; mf=a@origin.example;
    rt=m@list.example; b=PASS_AFTER_UNDO_MODS
From: "a via list" <m@list.example>

A Message!
Click https://list.example/unsubscribe to unsubscribe from this.
====

DMARC is satisfied by this message. There is a signature from the domain of 5322.From that passes on the message being presented, and the original 5322.From isn't visible unless the receiving system decides that that's an appropriate thing to do.¶

It should be required that any changes 5322.From be included in a signature where the signing domain aligns with the new 5322.From, similar to how i=1 must align with the message's original 5322.From.¶

1.3.6. Sending on behalf of another domain

There are scenarios in which one ADMD is sending messages on behalf of another ADMD. A common example of this is Email Service Providers (ESPs) that send promotional mail on behalf of their customers.¶

Transaction: Origin to destination¶

====
MAIL FROM: <something@esp.example>
RCPT TO: <abc@destination.example>
DATA
DKIM2-Signature: i=2; d=esp.example; s=espkey;
    mf=something@esp.example; rt=abc@destination.example; b=PASS
DKIM2-SIGNATURE: i=1; d=brand.example; s=brandkey;
    mf=something@brand.example; rt=something@esp.example; b=PASS
From: "Brand coupons" <no-reply@brand.example>

Here are some coupons for our Brand products!
====

Despite being originated from the ESP directly, DKIM2's requirement that the i=1 d= tag have alignment with both the 5321.MailFrom and 5322.From means that scenarios like this will require two signatures at origination. The first satisfies the requirement that the signature be aligned with 5322.From, and the second satisfies the requirement that the topmost signature's mf= tag be equal to the 5321.MailFrom of the transaction.¶

Generation of two signatures is only required when the ESP needs to use a 5321.MailFrom that is not aligned with 5322.From. If this is not required, the mail can be sent using a single signature that aligns with both.¶