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 <brong= [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]
