I wanted to make two additional points about DMARC and DKIM2. First, regarding what is the division of labor between DNS policies and signatures, we should ask, who should do what based on what they are best at. DNS policies are inherently domain scoped whereas signatures are per message. Signatures can be deleted by a Threat Actor which is a problem. DNS policy cannot be, at least if the message is to be considered authenticated from that domain.
Bringing back to the higher level discussion of DMARC vs DKIM2 and the division of labor there, those two specifications turn different knobs. DMARC publishes policies via DNS while DKIM2 I-D specifies its policies through signature flags. It might make sense to provide domains for the means to publish message authentication which is in fact what DMARC does. Sending domains may have messages with different characteristics- notifications are intended for a single recipient, vs promotional and personal that may be intended for a recipient or mailing list. Similarly notifications often have stricter security requirements about who ought to be identified with the message i.e. who can modify or extend it. It would make sense for these controls to be per message to permit these different types of messages to be sent from a given domain. And this is what DKIM2 proposes to do. Second, that's not to say there aren't improvements to make with this division of labor between DKIM2 and DMARC. The current DMARC and -bis just ask for SPF or DKIM authentication. It says nothing about DKIM2. Moreover, even if it did, it doesn't say what the sender's policy is around authentication. A sender might want mail broadly deliverable and state that SPF, DKIM, and DKIM2 to be acceptable for its traffic, while another would be more restrictive. That is not expressible today. FWIW I mentioned a proposal around this for DMARC here <https://mailarchive.ietf.org/arch/msg/dmarc/oqcJoGfBCX0C3Y7yZzCga3k6sTs/> back in 2023. Another issue is the DKIM2 chain of custody to authenticate the From header field. As mentioned in the prior email, DKIM2 will authenticate the last signature but not the chain of custody. This implies for DMARC to authenticate the From, it needs to do more work for forwarded emails and validate the chain of custody. Is this the right division of labor? -Wei On Wed, May 13, 2026 at 12:25 PM Wei Chuang <[email protected]> wrote: > > > On Thu, Apr 30, 2026 at 7:29 AM Todd Herr <todd= > [email protected]> wrote: > >> >> >> On Wed, Apr 29, 2026 at 2:13 AM Wei Chuang <weihaw= >> [email protected]> wrote: >> >>> I've been meaning to reply about this exploration of safety with DKIM2 >>> and implicitly DMARC as BIMI is based on DMARC. >>> >>> The point I meant to make was, in the past, we've assumed that DKIM and >>> DMARC authentication pass doesn't mean the message is safe. For example, >>> spammer are pretty adept at authenticating their emails. I would say the >>> same thing applies to DKIM2: just because a message passes doesn't mean >>> it's trustworthy. As others mentioned later in the thread, DKIM2 provides >>> a provable technique to show, for example that the content in the footer >>> came from a forwarder, while the content in the body came from the >>> originator. Safety comes from analyzing the content to find the phishing >>> link appended to the IRS email's footer, and then taking action to protect >>> the user. However, safety also involves ensuring the IRS is not negatively >>> impacted which DKIM2 helps prevent. >>> >>> There is another question. How does DKIM2 interact with DMARC? We >>> could take a narrow view that only DKIM RFC6376 applies to DMARC RFC7489 or >>> DMARCbis. Presumably it means that the From header must align with the >>> DKIM2 d= domain at the most recent (largest i=n) with a passing signature >>> validation. However this precludes making any changes at the forwarder, >>> and I would argue that's too limiting. At the risk of rocking the >>> carefully crafted understanding of DMARC's purpose, it is to encourage >>> authentication and provide a means for the sender to communicate the >>> sender's email address to the receiver through the alignment process. I >>> think DKIM2 can both authenticate and propagate the originating sender's >>> email address via the original From header, as well as any other message >>> that rewrites the From header. In this expansive view of DMARC with DKIM2, >>> if the From header aligns with the DKIM2-Signature d= domain at i=1, it >>> potentially may be DMARC aligned. Then we have to check that all >>> successive DKIM2-Signatures are valid and that the mf= and rt= match >>> between successive instances match. That might be: >>> >>> - DKIM2 signature validate after message algebra for all signatures >>> i=1..n >>> - For i=1..n there exists a well defined forwarding path >>> - mf= at i=m is aligned with DKIM2 signature d= >>> - rt= at i=m, it is aligned with i=m+1 DKIM2 signature d= >>> - Original From header was aligned at i=1 with DKIM2 signature d= >>> domain >>> - From header may be rewritten, but must be recoverable via >>> header algebra >>> >>> If all these are true, then it would be a DMARC pass in this expansive >>> view. >>> >>> This is just a strawman for further discussion at the interim meeting >>> later today. >>> >> >> In the interests of capturing (and expanding on) what I said during the >> interim on electronic paper, here is why I'm pessimistic about a future for >> DMARC in a world where DKIM2 achieves universal deployment... >> >> DMARC does three things for domain owners: >> 1. It allows the domain owner to announce, through a DNS TXT record, that >> it has taken (or is taking) steps to ensure that mail using its domain in >> the RFC5322.From header is authenticated as DMARC defines "authenticated" >> 2. It allows the domain owner to request message handling disposition for >> messages using its domain that fail DMARC validation >> 3. It provides a mechanism for the domain owner or its designee(s) to >> receive reports about DMARC authentication statistics for messages using >> its domain, with those reports providing some clues that can be useful in >> sussing out authentication shortcomings and possible misuse of the domain. >> >> While a message receiving site is free today to impose a policy of "no >> DMARC pass means rejection, regardless of domain owner preference," doing >> so risks rejecting some wanted mail due to the acknowledged shortcomings in >> SPF, DKIM, and DMARC, shortcomings that DKIM2 has a goal of addressing, >> yes? >> >> I will note here that since DKIM2's goal includes, in my words, fixing >> what's broken with DMARC, it does not make sense to me to have DKIM2 as an >> authentication mechanism that underpins DMARC; rather, DKIM2 should stand >> alone in my opinion. >> > > Since it's coming from you, one of the -bis authors, I'll take it as > gospel that these are the actual DMARC's goals. I'll point out your 1. is > the closest to what I mentioned earlier about origination but this is > restricted to an authenticated From header field identity, and lacks any > description around forwarding. But it is important to establish forwarding > as a problem to get at the crux of the argument with DMARC and DKIM2. You > do note that DKIM2 is an attempt to fix what is wrong with DMARC > authentication. My understanding of those DMARC failures is that modified > forwarded email typically breaks both DKIM and SPF. I would posit that > DKIM2, the new kid on the block, potentially may solve that. > > But to make my case that there is a need for DMARC with DKIM2, let's dig > into what DKIM2 does based on the -01 version > https://datatracker.ietf.org/doc/draft-ietf-dkim-dkim2-spec/01/, with the > caveat that just my interpretation even if I'm one of the spec's authors. > Under Section 8. "Signer Actions" is Section 8.2 "Provide a "Chain of > Custody" for the Message" which calls for "a valid "chain of custody" MUST > be apparent when all of the DKIM2-Signature header fields are considered." > This is implemented in Section 8.3 where "checking that the MAIL FROM value > recorded in every DKIM2-Signature header field (except of course the i=1 > instance) can be matched with a RCPT TO value of the next lower numbered > DKIM2-Signature header field". It also calls for "signing domain > (specified in the d= tag) and the MAIL FROM domain". So far so good. I > would argue this does validate a forwarding path. > > Under Section 10. Verifier Actions and specifically Section "10.4. Check > the Chain-of-Custody", it calls for checking " exact match between the MAIL > FROM and RCPT TO parameters used when delivering a message and the values > found in the mf= and rt= tags of the highest numbered DKIM2-Signature". It > also validates "relaxed domain match ... between the signing domain of the > most recently applied DKIM2-Signature header field and the mf=" That > validates the most recent signature. But what about the prior signatures > if they are not checked? > > It's easy to imagine potential mischief if the prior signatures are not > checked. Some forwarder, malicious or gullible, may have signed for a > forwarded message that doesn't have a valid signature. Such a message > makes it easy to hide abuse that spoofs some victim's identity e.g. > conceptually: > > DKIM2-Signature: i=2; d=verifiable.example; mf=; rt=; s=::valid.signature > > DKIM2-Signature: i=1; d=invalid.example; mf=; rt=; s=::invalid.signature > > From: [email protected] > > Is this authenticated? I would argue, yes, it is! When the receiver sees > abusive content, it enables us to say the forwarder verifiable.example > signed for the message containing abuse. However, does the DKIM2 > signatures identify the From identity? I would argue, no, it does not, > because we did not validate that the signature of invalid.example was > correct. Hence, despite From header field alignment with the first > signature, we should not use the From address identity to mean anything > useful. The problem here is similar to when we say DKIM or SPF is > authenticated but lacks RFC7489 From alignment. > > Instead we need to validate that first signature, establish that From > header field relationship for DKIM2 i=1 signature, and follow the Chain of > Custody to i=2. This approach is analogous to saying that there is an > originator identified by the From header field, who chose to send a > message. That message was then forwarded from i=1 to i=2 and onwards. > This is useful information to a receiver, and why I think we need to > distinguish DKIM2 authentication from DMARC with DKIM2 authentication. > > Fast-forward to an ecosystem where DKIM2 is universally deployed (for some >> value of "universally"), and I believe we will be living in an ecosystem >> where receivers will impose a policy of "no DKIM2 pass, no entry." They >> will be safe to do so, because if DKIM2 achieves its goal of fixing the >> shortcomings in authentication that exist in indirect mail flows, then a >> message that fails DKIM2 will be correctly deemed to not meet the standards >> for accountability that DKIM2 has imposed; I know if I were still in a >> position where I was focused on inbound email traffic to a large mailbox >> provider, I would stridently argue for putting such a policy in place at >> that time. Further to this point, I am not saying that the policy will be >> "a DKIM2 pass means the message is accepted"; rather, the policy would be >> "a DKIM2 pass is required as one of several criteria that a message must >> meet in order to be accepted." >> >> Now, if you're going to argue with me here that there may be legitimate >> reasons for accepting a message that fails DKIM2 because of corner cases or >> edge cases or this reason or that reason, then I would counter that DKIM2 >> will not have achieved its goal of addressing existing shortcomings in the >> authentication landscape, or worse, it just introduced new ones in that >> scenario. >> >> So, indulge me and envision a world where DKIM2 is universally deployed, >> issues with authentication and indirect mail flows have been consigned to >> the dustbin of history, and mailbox providers now require DKIM2 to pass in >> order for acceptance of the message to be a possibility; at that point, >> whither DMARC? >> >> 1. In my opinion, there's no need for a DMARC DNS record to announce that >> a domain has taken (or is taking) steps to authenticate with DKIM2; it's >> now a requirement. >> 2. In my opinion, there's certainly no need for a domain owner to request >> message handling disposition for messages that fail DKIM2; that decision is >> made for you by the mailbox providers' "no DKIM2, no entry" policy. >> 3. There *might* be a use case for DMARC reports, but given that as I >> understand DKIM2, it's designed to route bounces back to their origination >> point, notice of DKIM2 failures in the form of bounces will make it back to >> the domain owner (or its designated sender of "legit" mail) much more >> quickly than would DMARC reports. As for messages that were not >> authorized by the domain owner, I know there are some who believe DMARC >> reports to be valuable in identifying takedown candidates and such, but I >> do not share that belief, and I further posit that such forgeries may be >> greatly reduced if the bad guys know that messages that fail DKIM2 will be >> rejected out of hand. >> >> I admit that this is all speculative on my part, and it'll take years to >> prove me right or wrong, but this is where my head's at today regarding >> DKIM2 and DMARC. >> > > Regarding DKIM2 taking away responsibility from DMARC enforcement policy, > I agree there is overlap, that could cause confusion, but I would point out > that there are some properties that distinguish them. One such > differentiating factor is DMARC's policy mechanism is more of a means to > communicate the desired enforcement severity by the sender to the receiver > for the From header alignment. That is different from DKIM2's flag for > whether modifications to the message are permitted. I would propose that > further untangling this, and finding a logical division of labor between > DNS policies and DKIM2 signatures would be helpful. Keep in mind that > sometimes the DKIM2 signer and the DNS owners are different entities. > > As to the bulk sender policy eliminating the need for DMARC, I would just > point out that various bulk sender policies explicitly call for DMARC or > implicitly by requiring alignment (e.g. Gmail > <https://support.google.com/a/answer/81126?hl=en>, Yahoo > <https://senders.yahooinc.com/best-practices/>, Outlook > <https://techcommunity.microsoft.com/blog/microsoftdefenderforoffice365blog/strengthening-email-ecosystem-outlook%E2%80%99s-new-requirements-for-high%E2%80%90volume-senders/4399730>). > The view point I've heard around bulk sender policies was that it was meant > to bring out authentication based on the IETF standards to help fight > abuse. So I don't think those policies have eliminated the need for > DMARC. If anything, I think it calls for evolving DMARC to meet the new > authentication challenges. > > -Wei >
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
