I support the receive-time check as a heuristic for distinguishing between replay and non-supporting domains when a message is received with unequal RCPT and rt= values. I think the receiving system is much better positioned to do something useful with this information than a sending system is.
Senders already perform DNS lookups for the recipient domain. Adding one more lookup to determine DKIM2 support doesn't feel that bad, if we can come up with a reason for doing sign-time DKIM2 support checks. A domain-level policy is slightly problematic. For domains involving more than one mail provider (ex. separate mailbox and bulk mail providers), DKIM2 support can only be declared after all of them support DKIM2. However, I don't see a way to make this anything other than a domain-level policy, so those setups are likely stuck with not declaring support during their transition to DKIM2. On _dkim2 vs _dmarc, we've kept RSA signatures in DKIM2 so that service providers don't need to chase down their customers to get new DNS records deployed. Using a new record would require that type of outreach, or leaves the domains in a state of DKIM2 supported but not declared. I don't know how common it is for those types setups to CNAME the _dmarc record to a provider's record, so this might be roughly equivalent either way. On Thu, Oct 1, 2026, 9:54 a.m. Bron Gondwana <brong= [email protected]> wrote: > 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 <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] > > > -- > 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]
