I too support the idea of language that says "the DKIM2 signing domain MUST match the RFC5322.From domain whenever the domain is introduced or changed in a message" being in the DKIM2 spec.
I believe that adding DKIM2 as an authentication mechanism for DMARC will slow, rather than accelerate, adoption of DKIM2, because a DMARC pass will still be achievable with just SPF, or just DKIM. I believe the only way to avoid that slowdown would be to more significantly update RFC 9989 to state that a DMARC pass is achievable with either an aligned DKIM2 pass OR (an aligned DKIM pass or an aligned SPF pass), and I believe that would be a much more protracted effort, one for which this working group isn't currently chartered. While I understand that adding DKIM2 as an authentication mechanism for DMARC could produce a future state where receivers declare that they will only award a DMARC pass to messages with an aligned DKIM2 signature, that would be a bastardized version of DMARC, unless the DMARC RFCs were modified at that time to remove SPF and DKIM. On Thu, Sep 17, 2026 at 1:06 PM Emanuel Schorsch <[email protected]> wrote: > I agree completely. This fixes a gap that I was worried about and prevents > attackers from taking advantage of body recipes to introduce unrelated > fromHeaders like irs.gov if they can’t back them up with authentication. > I also think this belongs in the dkim2 spec itself. > > Best, > Emanuel > > On Thu, Sep 17, 2026 at 12:57 PM Tobias Herkula <tobias.herkula= > [email protected]> wrote: > >> Sorry for the slight necro-bump here. Richard's original mail arrived >> while I was on vacation, and I only came across it this week. >> >> I support Richard's approach and would very much like to see this added >> directly to the DKIM2 specification. >> >> For me, this is not primarily a DMARC interaction or policy question. It >> is a property DKIM2 itself should provide: whenever an RFC5322.From field >> is introduced or changed, there should be a required domain match between >> the domain in that field and the d= domain of the DKIM2 signature added at >> that point. >> >> So for the initial message, the RFC5322.From domain would need to match >> the d= domain of the i=1 signature. If an intermediary later changes the >> RFC5322.From field, the new domain would need to match the d= domain of the >> DKIM2 signature added by that intermediary. If the From field is not >> changed, there is no need to establish that match again at every subsequent >> hop. >> >> I would also prefer to avoid the term "alignment" here, simply because it >> already carries a lot of DMARC-specific meaning. "Domain match" seems to >> describe what we need without importing terminology from another protocol. >> >> I would prefer this to be a normative part of the DKIM2 specification >> rather than something defined in a separate DMARC-related document. >> Otherwise DKIM2 can authenticate the handling chain while still leaving the >> relationship between the visible author domain and the signer responsible >> for introducing or changing that author identity undefined. >> >> In practice this relationship is already expected by the major mailbox >> providers through today's DKIM and DMARC requirements. Making the domain >> match an explicit DKIM2 property therefore seems both useful and consistent >> with current deployment reality. >> >> -- >> >> Best regards, >> Tobias Herkula >> >> Head of Mail Transfer Development >> Mail Backend Development >> >> 1&1 Mail & Media Development & Technology GmbH >> www.mail-and-media.com >> >> Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 5452 >> >> Geschäftsführer: Alexander Charles, Dr. Michael Hagenau, Thomas Ludwig, >> Dr. Verena Patzelt >> >> Member of United Internet >> >> This e-mail may contain confidential and/or privileged information. If >> you are not the intended recipient of this e-mail, you are hereby notified >> that saving, distribution or use of the content of this e-mail in any way >> is prohibited. If you have received this e-mail in error, please notify the >> sender and delete the e-mail. >> ------------------------------ >> *From:* Wei Chuang <[email protected]> >> *Sent:* 02 September 2026 15:55 >> *To:* Richard Clayton <[email protected]> >> *Cc:* [email protected] <[email protected]> >> *Subject:* [Ietf-dkim] Re: Insisting that From is authentic >> >> I propose that defining DKIM2 interactions for the RFC5322 From header >> field become a separate document along with defining DMARC interactions. I >> do like the current draft-ietf-dkim-dkim2-spec's intentional separation of >> policy from authentication. In fact a separate document can better make >> that separation more distinct and clear. >> -Wei >> >> On Mon, Aug 31, 2026 at 7:34 AM Richard Clayton <[email protected]> >> wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> >> Several people have spoken up about the interaction between DMARC and >> DKIM2 -- and the issues that arise when the RFC5322 From header field is >> changed by an intermediary. >> >> There is a straightforward way to address this -- which I would commend >> to the working group. >> >> We update the spec to say that when a From field is first placed into a >> message (ie it sits alongside an i=1 DKIM2-Signature) or when it is >> changed by an intermediary (there is a recipe that shows that it has >> been changed at a particular hop) then DKIM2 will insist that there is >> match between the d= domain being used to sign and the domain in the >> RFC5322 From header field. >> >> The appropriate match would seem to be the "relaxed" match described in >> #9.4 .. viz if d= and the domain in the RFC5322 From header field are >> not identical then remove labels until the values are identical or until >> there are no labels remaining in which case there is no match. >> >> Since in the real world no-one can sign for .com (or whatever your >> publicly used TLD may be) this is just as safe as the MAIL FROM match >> already required (and we don't need to wander into the world of tree- >> walks or the PSL). >> >> Since this fits with what a number of people have been asking for, >> unless there is outrage (or an important use case where this would be >> impossible) I will put appropriate text into spec-07 so that the detail >> of the wording (rather than just the concept) can be considered by the >> Working Group. >> >> - -- >> richard @ highwayman . com "Nothing seems the same >> Still you never see the change from day to day >> And no-one notices the customs slip away" >> >> -----BEGIN PGP SIGNATURE----- >> Version: PGPsdk version 1.7.1 >> >> iQA/AwUBapWQgmHfC/FfW545EQIf0wCgjNlZqZ19T/R52pHjBh5PXsXeBSQAn1ya >> ypqXc1AYxPSFiM+YIThRE5Dq >> =iOeT >> -----END PGP SIGNATURE----- >> >> _______________________________________________ >> Ietf-dkim mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> >> _______________________________________________ >> Ietf-dkim mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> > _______________________________________________ > Ietf-dkim mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- Todd
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
