Yes, auth= on the DMARC record would do the trick. This is an explicit record change which would be needed for any site which wanted full protection, but there's no way to avoid that.
Even without the additional DNS record, once 'B' supports DKIM2, good email will be fully DKIM2 all the way through. Bron. On Thu, Oct 1, 2026, at 10:30, David Conradie wrote: > I like this. > > I was not keen on the prospect of making the sender do dns lookups. > > As you say, the receiver is already doing a ton of work/lookups. > > There was a proposal floating around to add an “auth=“ clause to the DMARC > record; wouldn’t that fit with this proposal, rather than another record name > (_dkim2…) > > > > On Thu 1 Oct 2026 at 02:37, Bron Gondwana > <[email protected]> wrote: >> __ >> This came up in the interim call last week, and I promised to write this up. >> >> Consider this basic case: >> >> A = sender (supports DKIM2) >> B = intermediate which doesn't support DKIM2 (forwarder or mailing list) >> C = recipient (supports DKIM2) >> >> The proposal I disagreed with in the meeting, I would characterise as: >> >> "A looks up a DNS record, sees that B doesn't support DKIM2, writes `rt=` >> (blank recipient list) showing that the message was departing DKIM2 at this >> point, so C knows it went to somewhere that doesn't support DKIM2." >> >> I propose an alternative method. >> >> A does nothing special, just sends with rt=address@B. >> >> C receives the messages with rt=address@B still on the top (broken) DKIM2 >> header, and does a DNS lookup on B's domain, for e.g.. `TXT >> _dkim2.domain.com` which says that this domain supports DKIM2. If that >> record is present, then the message MUST be a replay, because it doesn't >> have Domain B's signature. If it's not present, then it's just a naive >> domain, and the message needs to be treated as "not yet DKIM2 enabled". >> >> This has multiple advantages. >> >> 1) no forward lookup. Domain A doesn't need to care about whether domain B >> supports DKIM2, so there's no caching issues at this point. >> >> 2) destination data is present - C can still introspect the message to see >> what domain it was intended for, and where it came from on the way into C's >> MX, so it has more data to catch replays. >> >> 3) C has to do the analysis anyway, so it's already loading a ton of DNS >> records and can do some of this work asynchronously. >> >> Bron. >> >> -- >> Bron Gondwana, CEO, Fastmail Pty Ltd / Fastmail US LLC >> [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] > -- Bron Gondwana, CEO, Fastmail Pty Ltd / Fastmail US LLC [email protected]
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
