You are right that within DKIM2 alone, i=1 is i=1 - a re-originating service and an originally-originating service look structurally identical at the signature level. The distinction comes from the broader header ecosystem: re-originated list mail typically carries RFC 2369 headers (List-Id, List-Unsubscribe, List-Post, etc.) that are covered by the DKIM2 signature and observable by receivers. Those headers are the practical signal today.
The protocol-level answer to your question is the f=reorigin flag proposal in the GitHub issue (dkim2wg/spec Issue #2). A standardized flag value in the signed DKIM2-Signature would let receivers identify the pattern from the authenticated signature directly, without relying on list header inference. Your question also reframes the BCP argument usefully: if receivers cannot easily distinguish re-originators from first-party originators within DKIM2, the BCP should not require them to. The proposed sentence asks receivers not to treat chain absence with such RFC 2369 headers present as a negative signal - other reputation, content, and complaint signals remain fully in play. That is a simpler ask than identification and does not require new detection logic. William Weiner Weiner Advanced Development LLC, maker of EMail Parrot (emparrot.com) From: Hannah Stern <[email protected]> To: <[email protected]> Date: Wed, 22 Jul 2026 09:09:56 -0600 Subject: [Ietf-dkim] Re: DKIM2 with message encryption > Hi! > > On 7/13/26 18:26, William Weiner wrote: > [...] > > The ask is one sentence in Section 6: a valid single-hop DKIM2 signature > from a re-originating service with documented characteristics (p=reject, > functioning abuse contact, stable domain reputation) SHOULD be evaluated on > the same basis as any other Sender ADMD originator, without prejudice for > the absence of a prior chain. > > How would a recipient identify your service as a "re-originating > service" as distinct from other services anyway, if it signs i=1? > I'd think at least in terms of DKIM2 such a "re-originating > service" wouldn't look different from an "originally-originating > service" (or whatever we call the relevant complement set). > > Hannah. > > -- > Hannah Stern > > Software Developer > Mail Transfer Development > > 1&1 Mail & Media Development & Technology GmbH | | | > Phone: +49 721 91374-4519 > E-Mail: [email protected] | Web: www.mail-and-media.com www.gmx.net > www.web.de www.mail.com www.united-internet-media.de > > Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 5452 > > Geschäftsführer: Alexander Charles, Dr. Michael Hagenau, Thomas Ludwig, Dr. > Verena Patzelt > > > Member of United Internet > > Diese E-Mail kann vertrauliche und/oder gesetzlich geschützte Informationen > enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind oder diese > E-Mail irrtümlich erhalten haben, unterrichten Sie bitte den Absender und > vernichten Sie diese E-Mail. Anderen als dem bestimmungsgemäßen Adressaten > ist untersagt, diese E-Mail zu speichern, weiterzuleiten oder ihren Inhalt > auf welche Weise auch immer zu verwenden. > > 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. > > _______________________________________________ > 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]
