]> ITB.it

v.moccia@itb.it

Applications and Real-Time DKIM Working Group DKIM2 milter email authentication deployment profile This document defines a deployment profile for DomainKeys Identified Mail v2 (DKIM2) that is implementable via the existing milter interface without modifications to Mail Transfer Agent (MTA) core software. It identifies a mandatory core profile (DKIM2-core) covering envelope binding, chain of custody, header accountability, replay prevention and DSN authentication and an optional extended profile (DKIM2-extended) covering body recipes and Message-Instance headers. The separation is motivated by deployment realism: the core profile addresses the primary threat models identified in the DKIM2 motivation document and is deployable incrementally across heterogeneous infrastructure, including small operators, universities and research institutions, using the same milter-based deployment model that has proven effective for DKIM1 and ARC. The intent of this document is not to obstruct DKIM2 but to make it deployable. DKIM2-core can be deployed incrementally across the heterogeneous ecosystem in a short timeframe. DKIM2-extended requires significantly longer implementation cycles and may not be deployable in jurisdictions with stricter privacy requirements. Both profiles are part of DKIM2 - the separation serves adoption, not opposition.

Introduction DomainKeys Identified Mail v2 (DKIM2) addresses significant limitations of DKIM1 and the experimental ARC protocol , including DKIM replay attacks, backscatter from unauthorized use of envelope senders and the absence of cryptographic binding between message signatures and SMTP envelope parameters. The core technical contribution of DKIM2 - binding the MAIL FROM and RCPT TO values of each SMTP transaction to the message signature at every hop - is a genuine improvement over both DKIM1 and ARC and is sufficient to address the primary threat models identified in . However, the current specification also includes a body recipe mechanism that allows intermediaries to describe modifications made to the message body in sufficient detail to reconstruct previous versions. This mechanism introduces significant architectural complexity: it requires stateful milter implementations with persistent shared storage, JSON parsing in the delivery critical path and software modifications across the entire ecosystem of intermediaries. The body recipe mechanism also raises data protection concerns under GDPR and equivalent frameworks that have not yet been addressed in the specification. This document proposes a structured separation of DKIM2 functionality into two profiles:

• DKIM2-core: a mandatory profile implementing envelope binding, chain of custody, header accountability, replay prevention and DSN authentication. DKIM2-core is fully implementable via the milter interface without MTA core modifications, using header formats already familiar to the ecosystem through ARC deployment. Critically, DKIM2-core requires no persistent state between SMTP sessions - all information needed for signing and verification is available within the current session and the message headers themselves. State management is only required for body recipe generation, which belongs exclusively to DKIM2-extended.
• DKIM2-extended: an optional profile adding body recipe generation and verification via Message-Instance headers and JSON-encoded recipes. DKIM2-extended may require stateful milter implementations or MTA core integration and is appropriate for operators who require full body accountability and are willing to accept the associated architectural cost.

This separation is consistent with the DKIM working group charter , which states that "the working group will prefer a result that is incremental to the deployed ecosystem" and that "proposed solutions are expected to be robust in terms of interoperability and scalability". The approach taken in this document is explicitly constructive: it does not propose to replace DKIM2 but to define a deployment path that allows the ecosystem to adopt the core benefits of DKIM2 incrementally, without requiring simultaneous changes to every node in the delivery chain.

Relationship to DKIM2 Specifications This document is a deployment profile, not a competing specification. It references and depends on for the underlying mechanisms. Where this document proposes alternative encoding formats - specifically for envelope binding fields - these are offered as contributions to the ongoing design discussion in the working group.

Motivation The Internet email infrastructure is not composed solely of large providers with dedicated engineering teams. A substantial portion of email is handled by operators of all sizes outside the largest commercial providers: small ISPs, universities and research institutions, regional hosting providers, non-profit organizations and small businesses. What these operators have in common is not small scale per se - a university may handle millions of messages per day - but limited engineering resources dedicated to mail infrastructure. Their administrators depend on the milter interface for incremental deployment of new authentication features precisely because it allows them to adopt new protocols without modifying MTA core software, waiting for upstream vendor releases or dedicating engineering cycles to core system changes. Every authentication protocol that has achieved broad adoption - SPF, DKIM1, DMARC and to a limited extent ARC - has been deployable via this model. DKIM2 as currently specified breaks this pattern. Furthermore, the body recipe mechanism encounters a fundamental operational obstacle: the nodes most likely to make substantial body modifications - security gateways, DLP systems, URL rewriting proxies, antivirus engines - are precisely the nodes least likely to implement recipe generation. These nodes will systematically produce null recipes, which provide no additional accountability over incremental body hash chaining. The overhead of the recipe infrastructure is therefore paid by the entire ecosystem while the benefit accrues only to the minority of cases where all intermediaries cooperate fully. The pragmatic approach to body integrity documented in Section 3.4 - using relaxed canonicalization to tolerate common benign transformations rather than requiring intermediaries to declare or reconstruct them - has proven effective in practice and has contributed to the broad adoption of DKIM1. It should be noted however that relaxed canonicalization does not address all categories of involuntary body transformation: base64 line-width re-encoding, for example, breaks both simple and relaxed canonicalization equally. DKIM2-core preserves the relaxed canonicalization approach for body integrity while adding the cryptographic envelope binding and header accountability that DKIM1 lacks. The body recipe mechanism of DKIM2-extended represents a deliberate departure from this model toward deterministic reconstruction - a departure whose operational cost and deployment implications are addressed in Section 4.

Design Philosophy This document is guided by three principles that reflect the deployment realities described in Section 1.2. Additive, not transformative - every mechanism defined in DKIM2-core adds new header fields or new signed content to existing messages. Nothing in DKIM2-core requires existing software to change its core behavior. A legacy node that does not implement DKIM2 passes DKIM2 headers through without interpreting them, exactly as it handles any unrecognized header field today. This is the same property that allowed SPF, DKIM1, DMARC and ARC to be deployed incrementally across a heterogeneous ecosystem without flag-day transitions. Milter-first - the milter interface is the deployment mechanism that has enabled incremental adoption of every successful email authentication protocol. DKIM2-core is designed so that every mandatory feature is implementable as a milter without MTA core modifications. This is not a constraint imposed from outside - it is a deliberate architectural choice that maximizes the probability of adoption across the full range of operators described in Section 1.2, from large providers to small ISPs and universities. The term "milter" in the title of this document refers to the most widely deployed mechanism for extending MTA behavior without core modifications. The architectural arguments presented here apply to any filter interface that provides access to envelope callbacks during the SMTP transaction. Milter is used as the reference implementation because it is the dominant deployment model for email authentication protocols and because prototype DKIM2 implementations - including those demonstrated at the IETF hackathon - have converged on this interface independently. Stateless by design - DKIM2-core requires no persistent state between SMTP sessions. All information needed for signing and verification is available within the current session and the message headers themselves. This eliminates the need for shared storage between milter instances, reduces operational complexity and removes a category of failure modes that stateful implementations introduce. State management is only required for body recipe generation, which belongs exclusively to DKIM2-extended. These three principles together define the boundary between DKIM2-core and DKIM2-extended. Any mechanism that requires MTA core modifications, persistent inter-session state or content parsing beyond what the milter interface provides belongs in DKIM2-extended. Any mechanism that can be implemented additively, via milter and statelessly belongs in DKIM2-core.

Terminology and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interpreted as described in . This document uses terminology from (Internet Mail Architecture) and inherits definitions from . The following additional terms are defined for use in this document.

DKIM2-core:

The mandatory deployment profile defined in this document. DKIM2-core implements envelope binding, chain of custody, header accountability, replay prevention and DSN authentication. It is fully implementable via the milter interface without MTA core modifications and requires no persistent state between SMTP sessions.

DKIM2-extended:

The optional deployment profile defined in this document. DKIM2-extended adds body recipe generation and verification via Message-Instance headers and JSON-encoded recipes. It may require stateful milter implementations with persistent shared storage or MTA core integration.

Milter-capable node:

An MTA deployment that implements DKIM2-core functionality via the milter interface. A milter-capable node requires no modifications to the MTA core software.

Legacy node:

A node in the delivery chain that does not implement DKIM2 in any form. Legacy nodes pass DKIM2 headers through the delivery chain without interpreting them, exactly as they handle unrecognized header fields today.

Transparent relay:

A node that adds only trace headers (Received:, Return-Path:) and makes no other modifications to the message. Transparent relays do not need to participate in DKIM2 signing or verification. Note however that in practice many nominally transparent relays introduce involuntary body transformations - base64 re-encoding at different line widths, MIME reassembly by antivirus engines, whitespace normalization - that affect body hash values.

Forwarder:

A node that relays a message onward in an SMTP transaction of its own and presents an envelope sender in a domain it controls, whether or not it modifies the message. A Forwarder that adds a DKIM2 signature is subject to the envelope sender rewriting requirement of Section 3.1.4. A node that relays while passing the original envelope sender through unchanged is a Transparent relay as defined above. A Reviser that transmits the message onward is also a Forwarder in this sense.

Reviser:

A node that makes intentional modifications to message headers or body. A Reviser MUST declare its modifications using DKIM2-Chain-Mod headers (DKIM2-core) or Message-Instance recipes (DKIM2-extended) and MUST add a new DKIM2 signature covering the modified message.

Inbound milter:

The milter instance responsible for verifying incoming DKIM2 signatures during the SMTP session. The inbound milter operates at EndOfBody and has access to the complete envelope state accumulated during the session via MailFromRequest and RcptToRequest callbacks.

Outbound milter:

The milter instance responsible for generating DKIM2-Chain-Mod headers and adding DKIM2 signatures to outgoing messages. The outbound milter is positioned last in the milter chain, after all other milters that may modify the message and signs the final state of the message.

DKIM2-Chain-Mod header:

A signed header field added by a Reviser to declare a modification made to an existing header field. DKIM2-Chain-Mod headers carry an instance index (i=) aligned with the DKIM2-Chain-Sig hop number, a sequence index (seq=) for multiple modifications to the same field at the same hop and an optional frame index (fr=) to split values longer than 998 characters per .

Envelope binding:

The cryptographic binding of SMTP MAIL FROM and RCPT TO values to the DKIM2 signature at each hop, implemented via DKIM2-Chain-mf and DKIM2-Chain-rt header fields. Envelope binding prevents DKIM replay attacks by making it impossible to reuse a valid signature for a different recipient without breaking the chain.

Chain of custody:

The verifiable record of all entities that have handled a message, established by the sequence of DKIM2 signatures and envelope bindings from originator to final recipient. Each hop in the chain signs the current state of the message and references the previous hop's signature.

Null recipe:

A Message-Instance declaration that a modification was made to the message body but that the previous state cannot be reconstructed. Null recipes are only relevant in DKIM2-extended. In DKIM2-core, body modifications are declared implicitly through a changed bh= value with attribution to the signing hop.

Relaxed domain match:

The relaxed domain matching algorithm for matching the signing domain (d=) against the MAIL FROM domain, allowing subaddress schemes used for bounce handling. Labels are removed from the left side of the MAIL FROM domain until a match is found or no labels remain. Implementations MUST NOT remove more than two labels - that is, the MAIL FROM domain MUST be at most two levels below the d= domain. For example, bounce.mail.example.com matches d=example.com (two labels removed) but a.b.c.example.com does not (three labels would need to be removed). This limit is this profile's own. The base specification's algorithm removes labels until a match is found or none remain, with no bound on depth, and sets none either: its Section 3.10 allows a key published for a domain to validate signatures for any subdomain of it at any depth, a reach its Section 8.14 identifies as a concern. Bounding the removal to two labels bounds that reach. The bound governs only the fields defined in this profile, so it constrains the chains this profile's signers produce and never a chain produced under the base specification. An operator whose sending infrastructure sits more than two labels below the domain it signs for selects a signing domain nearer to it.

This document inherits definitions from . Where terms are used without definition in this document, the definitions in that document apply.

DKIM2-core: Mandatory Profile DKIM2-core is the mandatory deployment profile. All nodes that wish to participate in DKIM2 MUST implement DKIM2-core. Nodes that implement only DKIM2-core are fully interoperable with nodes that implement DKIM2-extended. The milter interface is an integration point, not a replacement for MTA functionality. DKIM2-core uses the milter interface to observe, verify and sign messages as they flow through the MTA's normal processing pipeline. Functions that belong to the MTA - transaction management, BCC splitting, queue handling, routing - remain with the MTA. The milter does not substitute for these functions and is not designed to do so. This separation of concerns is what makes milter-based deployment non-invasive and compatible with existing MTA infrastructure.

Envelope Binding Envelope binding is the primary technical contribution of DKIM2 over DKIM1 and ARC. By cryptographically binding the SMTP MAIL FROM and RCPT TO values to the message signature at every hop, DKIM2-core makes it impossible to replay a valid signature for a different recipient or sender without breaking the chain. Envelope binding is implemented via two new signed header fields: DKIM2-Chain-mf (carrying the MAIL FROM value) and DKIM2-Chain-rt (carrying the RCPT TO values).

Envelope Binding Format The DKIM2-Chain-mf field carries exactly one address - the SMTP MAIL FROM value. The DKIM2-Chain-rt field carries one or more RCPT TO values, using one header per address. Both fields use the i= instance indexing convention already established by ARC , where ARC-Seal, ARC-Message-Signature and ARC-Authentication-Results use the same i= numbering to build a verifiable chain across multiple hops. Implementers familiar with ARC will recognize this pattern immediately. Major email providers including Google and Microsoft implement ARC natively in their infrastructure and ARC milter implementations are deployed across the ecosystem. DKIM2-Chain-mf and DKIM2-Chain-rt extend this existing pattern to carry envelope values, requiring no new parsing concepts beyond what ARC implementations already handle. One header per address, including recipients with quoted local parts. The v= tag provides a sequence number that distinguishes multiple DKIM2-Chain-rt headers at the same hop. DKIM2-Chain-mf always carries exactly one address and does not require v=. This format handles all RFC5321 local part cases including quoted local parts containing special characters - within a single header value there is no separator ambiguity regardless of the characters present in the local part. The format copies exactly the ARC instance indexing pattern, requires no new parsing logic beyond what ARC implementations already provide and produces output directly inspectable in mail logs and headers without decoding tools. The design avoids the parsing complexity that arises when envelope addresses with display names, quoted local parts or multiple addresses are embedded in more complex header formats. DKIM2-Chain-rt carries only the bare Mailbox - the envelope address without display name or angle brackets - one per header. This is the natural format for SMTP envelope values, which by definition do not carry display names. It avoids the parsing complexity of RFC5322 address-list syntax, which includes display names, group syntax and other constructs that are irrelevant for envelope binding purposes. This format could produce more bytes than the JSON+base64 encoding currently specified in for messages with very many recipients. For the common case of messages with a small number of recipients - which represents the substantial majority of real-world email traffic - the size difference is negligible or absent. It remains directly human-readable without decoding tools, has a parsing complexity of O(1) per header rather than O(n) on the full recipient list and allows individual recipient membership verification without deserializing the complete list. DKIM2-core lists each RCPT TO value as an individual DKIM2-Chain-rt header, all covered by a single DKIM2-Chain-Sig. This provides per-address cryptographic binding: a verifier can confirm that the message was signed for exactly these recipients and no others. Replaying the message to a recipient not listed in a DKIM2-Chain-rt header produces a verifiable mismatch, even if that recipient is at the same domain as the original recipients. Alternative approaches such as DARA bind at the domain level - all recipients at the same destination domain share a single signature via darn=. DARA prevents replay to a different domain but does not prevent replay to a different recipient at the same domain. DKIM2-core closes this gap without requiring any additional MTA splitting beyond the standard per-domain delivery that MTAs already perform. The base specification encodes rt= values as base64 without JSON in its current revision, which reduces parsing overhead but retains opacity - the values are not directly human-readable without decoding. DKIM2-core's plaintext tag-value format for envelope binding fields remains directly inspectable without tooling. DKIM2-core achieves equivalent cryptographic binding of each recipient to the signed message via the standard milter envrcpt callback, listing all transaction recipients in DKIM2-Chain-rt fields. No MTA modification is required, making the mechanism deployable by any operator regardless of infrastructure. It is worth noting that quoted local parts containing special characters such as semicolons are permitted by but are not observed in practice in real-world email infrastructure. The format handles them correctly without any special-casing.

Relationship to Existing From:/To: Headers The DKIM2-Chain-mf and DKIM2-Chain-rt fields carry the SMTP envelope values, which may differ significantly from the RFC5322 From:, To: and Cc: header fields. This distinction is particularly important in two scenarios: Programmatic and bulk email - the envelope sender is typically a bounce handling address such as bounce-12345@mail.mailchimp.com and the envelope recipients are individual subscriber addresses that may not appear in the message headers at all. Using RFC5322 headers to infer envelope values would fail for this common case. Group syntax and empty groups - RFC5322 permits constructs such as To: Empty Group:; where the To: header carries no actual recipient addresses. The envelope RCPT TO values are the only reliable source of recipient information in these cases. It is also worth noting that the support for multiple rt= values - rather than a single recipient per message - was motivated by a specific operational requirement from a large mailbox provider whose anti-fraud system relies on verifying consistency between envelope recipients and To:/Cc: header fields to detect messages fraudulently presented as sent to multiple recipients but actually sent to only one. This use case requires that all RCPT TO values for a given SMTP transaction be visible in the signed envelope binding. A further distinction concerns cardinality rather than value. Section 3.6.2 defines the From: field as from = "From:" mailbox-list CRLF, so a single occurrence of the field may carry more than one mailbox. Where it does, the same section requires that the Sender: field be present and carry exactly one mailbox, since the agent responsible for the transmission can no longer be inferred from the author list. The identity of that agent is then carried in Sender: and not in From:. defines one reverse-path per transaction. The value carried in DKIM2-Chain-mf is therefore singular by construction, with no second field to consult and no selection rule to apply. This is one of the reasons the relaxed domain match of Section 3.1.3 is defined against the domain of the DKIM2-Chain-mf address: the identity each hop is held to is the one its own transaction establishes and it is established unambiguously for every message the hop handles. A verifier SHOULD verify the identity carried in the RFC5322 From: field against the signing domain of the hop that placed it there, for every value the field has held, using the relaxed domain match of Section 3.1.3. The DKIM2-Chain-Mod declarations defined in Section 3.2 carry the value removed in del= and the value added in new=, so the whole history of the field is present in the header fields and no earlier state has to be reconstructed. The procedure walks the chain downward from the highest hop:

1. At each hop i that carries a DKIM2-Chain-Mod with field=From and a new= value, the domain of that new= value is compared against the d= of the DKIM2-Chain-Sig at hop i.
2. The value the field held at origination is the del= value of the lowest numbered DKIM2-Chain-Mod with field=From, and its domain is compared against the d= of the signature at i=1. Where no declaration for the field is present anywhere in the chain the field has never been modified and the value in the message is compared against the d= at i=1.
3. Where a value reached in step 1 or step 2 carries more than one mailbox, or none because it uses the group syntax of , the comparison for that value is made against the Sender: field instead. The Sender compared is the new= value of the DKIM2-Chain-Mod with the highest i= not greater than the hop under examination that carries field=Sender; where there is none it is the Sender: field as present in the message. No comparison is defined for that value where no Sender: field is present or where the Sender: field uses the group syntax and carries no mailbox, since in neither case is there a domain to compare. Section 2.1, which replaces the corresponding text of Section 3.6.2, requires a Sender: field where the From: field carries more than one mailbox specification counting those within any group, so a plural From: with no Sender: does not conform, while an empty group carries no mailbox specification at all and the requirement does not reach it.
4. A DKIM2-Chain-Mod with field=From carries both del= and new=, since the From: field is required by Section 3.6 and may be neither absent before a change nor absent after one. A declaration carrying only one of the two describes a message that carried no From: field at some point along its path and is a protocol violation. No comparison is defined where a value uses a domain-literal in place of a domain, since there is then no domain to compare.

The base specification requires the same coverage by a different route. Its Section 14.8 states that a verifier "will need to inspect the currently present From header field and any previous From header fields that Recipes show have been present since the message was first signed". Its Section 11 identifies the signature that each value is compared against. The difference is in what each document gives the verifier to work with. A declaration that carries both the removed and the added value states what the field was and what it became, while a Recipe states how to rebuild a previous state, so the earlier values are reached there by undoing Recipes in order and are not reachable at all by a verifier that does not process them. Where the signature carries no envelope binding fields, as in Section 3.1.6, or carries a DKIM2-Chain-mf with an empty address, as for a DSN, there is no envelope sender to consider and the comparison above is the only one that applies.

Relaxed Domain Match The relaxed domain match algorithm is that of the base specification with one addition, the depth bound defined in Section 2 of this profile. The signing domain (d=) must match the domain of the DKIM2-Chain-mf address via relaxed domain match, allowing subaddress schemes used for bounce handling such as bounce-12345@mail.mailchimp.com to match d=mailchimp.com. The MAIL FROM domain MUST be at most two levels below the d= domain. This match does not apply to a signature that attests a received transaction. Section 3.1.6 gives the match that applies in its place.

Envelope Sender Rewriting on Forwarding A node that forwards a message and adds a DKIM2 signature MUST rewrite the SMTP envelope sender into a domain for which it holds a signing key, using a bounce address scheme such as SRS. This follows from the relaxed domain match requirement of Section 3.1.3: the signing domain must match the domain of the DKIM2-Chain-mf address, so a node that forwards while preserving the original envelope sender cannot produce a conformant signature. A node that does not forward is in the different position described in Section 3.1.6, where preserving the envelope of the received transaction is what the signature is for. It is also required by the continuity check of Section 3.3.8, which compares the envelope sender domain at one hop against the recipient domains of the hop before it. This is a change in behaviour for forwarders that pass the original envelope sender through unchanged, which remains common practice. The operational cost is bounded: envelope sender rewriting is already standard practice for forwarders that need to receive bounces for the mail they relay and it is available either within the filtering interface that performs the signing or as a separate stage ahead of it, depending on the capabilities of the MTA. The signer signs whatever envelope the MTA presents after rewriting. Nodes that relay a message without adding a DKIM2 signature are unaffected. A transparent relay that alters nothing, as described in Section 3.7.5, neither rewrites the envelope sender nor signs, so the existing chain remains verifiable against the envelope it was signed for. The two behaviours are consistent and the trigger is narrower than either: rewriting is required by the act of presenting an envelope sender of one's own, not by signing and not by relaying. A node that presents its own MAIL FROM must present one it can sign for. A node that passes the received envelope through, whether because it relays without signing or because it attests a transaction it received per Section 3.1.6, has nothing to rewrite.

BCC Recipients BCC recipients require separate SMTP transactions under DKIM2, to prevent disclosure of BCC addresses to the other recipients of the message. No such requirement exists today, because BCC confidentiality rests on the separation between the envelope and the message. The Bcc header field is removed at submission, as Section 3.6.3 provides and the RCPT TO values are consumed by the receiving MTA and are never delivered to a mailbox. An MTA may therefore batch several recipients of one destination domain into a single transaction, BCC recipients among them and disclose nothing. DKIM2 removes that separation by carrying the RCPT TO values in signed header fields that are delivered to every recipient. The requirement is introduced by the protocol and is not inherited from existing practice. The milter processes two distinct transaction types: For the To:/Cc: transaction the milter signs every recipient the MTA presents, since under the configuration described below a transaction carries either visible recipients or a single BCC recipient and never both. The comparison against the To: and Cc: header fields is still performed, to identify a transaction that mixes the two kinds and to support the consistency check described in Section 3.1.2. It requires address extraction from headers, since display names and comments must be stripped to obtain bare addresses and it is performed case-insensitively over the whole address. This is a deliberate relaxation of Section 2.4, which reserves the interpretation of the local part to the receiving host: both values being compared here were written by the same originating system and a comparison that distinguished them by case would classify a recipient as hidden on the strength of a difference no sending system intends. A recipient appearing both in To: and in BCC is possible but rare; such an address is a visible recipient and belongs to the To:/Cc: transaction. For each BCC recipient the MTA presents a separate SMTP transaction, as arranged by the configuration described below, which is not the default of current MTAs. The milter signs each transaction independently with a single DKIM2-Chain-rt carrying that recipient's address. No special handling is required in the milter, which processes each BCC transaction as a normal single-recipient message. Including BCC recipients in the To:/Cc: transaction with all addresses listed in DKIM2-Chain-rt would reveal BCC addresses in the signed headers, visible to all recipients and any archiving system. This directly violates Section 3.6.3 and MUST NOT be done. A transaction is representable in DKIM2 where every recipient it carries appears in the To: or Cc: header fields or where it carries exactly one recipient and that recipient appears in neither. Any other combination would expose a recipient that the message does not disclose to the recipients that it does, whether the transaction mixes visible recipients with a hidden one or carries more than one hidden recipient. For such a transaction the signer MUST NOT emit DKIM2-Chain-mf or DKIM2-Chain-rt and MUST NOT sign. Declining to sign is not sufficient on its own. Where the message carries a chain from earlier hops, leaving those header fields in place presents a highest numbered DKIM2-Chain-rt that describes a transaction other than the one in progress, which the check of Section 3.4 requires the next DKIM2 receiver to reject. The signer MUST therefore remove all prior DKIM2 header fields as well, so that the message leaves the hop with no DKIM2 chain at all. The result is a transaction carried outside DKIM2. It discloses nothing, since no envelope binding field is produced and it arrives with the absence of a prior chain that Section 6.1.1 requires a receiver not to treat as a negative indicator. This is not the re-origination of Section 6.1.1, which terminates the chain and signs a new i=1: no new first hop is produced here, because an envelope that cannot be represented without disclosure cannot be represented at i=1 either. The disposition of the downgraded message is a matter of local policy and the condition SHOULD be recorded as a configuration error of the sending system. This design requires no MTA core modifications, but it does require a configuration that is not the default. Both Sendmail and Postfix can be made to present one recipient per transaction and some large providers already send that way while others batch recipients by destination domain. Where batching is in use, enabling per-recipient transactions retransmits the message body once per transaction, since each transaction carries its own DATA and it applies to every message with several recipients at one domain and not only to those carrying BCC. The connection is reused, so the cost falls on bandwidth in proportion to message size and recipient count rather than on connection setup. A future standardized mechanism for BCC signaling at the SMTP level would confine the split to BCC recipients and remove that cost, but it is not required for correct operation. The milter buffers RCPT TO values during the envrcpt callbacks and performs the comparison against To: and Cc: headers in the eom callback, when all header fields are available. Recipients present in RCPT TO but absent from To: and Cc: are identified as BCC recipients. Whether those recipients arrive in transactions of their own is determined by the MTA configuration described above and not by the milter. The milter signs each transaction as presented, generating DKIM2-Chain-rt headers only for the recipients the MTA includes in that transaction. The splitting cost is operational and not architectural and it requires no changes to the MTA core.

Synthetic Hops and Intra-ADMD Signing The base specification requires that the chain of custody form a contiguous sequence where the rt= value at hop i aligns with the mf= value at hop i+1. In deployment scenarios where multiple signatures are applied within the same administrative domain, such as an Email Service Provider signing on behalf of a brand or a vanity domain forwarded through a mailbox provider, no SMTP transaction occurs between the two signing identities. The base specification addresses this by generating synthetic DKIM2-Signature headers representing hops that never occurred at the SMTP level, requiring the invention of email addresses for transactions that never took place. It also provides the nd= tag as an alternative: a signature carrying nd= omits mf= and rt= entirely and names the domain expected to produce the next signature, which avoids the invented address. A verifier checks that the named domain matches the d= of the following signature and where a message is transmitted with nd= in its highest numbered signature the base specification states that the receiving system will not be able to validate the MAIL FROM and RCPT TO values, that the message is therefore not a Fully Verified DKIM2 Message and that whether it is acceptable depends on out-of-band arrangements. An independent implementer writing a DKIM2 verifier in Rust against revision 06 of the base specification reported that nothing in the chain of custody checks tied a signature carrying nd= to the recipient values of the signature below it, so a party that merely received such a message could present it onward as its own. Revision 07 closes that path in its Section 7.1, which seeks a match between the signing domain of a signature carrying nd= and a recipient address in the next lower numbered signature. One point remains open in revision 08. Its Section 10.7 states that a sequence of signatures carrying nd= "MUST end with a DKIM2-Signature that contains mf= and rt= tags", while the special case described above permits a message to be sent while its highest numbered signature carries nd=. A message in that state is a sequence that does not end with a signature carrying those tags, so the two statements cannot both hold for it. DKIM2-core does not require this mechanism. Because DKIM2-Chain-mf and DKIM2-Chain-rt are separate header fields rather than tags within the DKIM2-Signature, a signature that covers no SMTP transaction is expressed by omitting them. A signer that applies two signatures within one administrative boundary emits the first with no envelope binding fields and the second with the envelope values observed in the actual transaction. No address is invented for a transfer that never took place and no additional tag is needed to declare the identity of the next signer, because the chain of custody is established by the sequence of signed headers rather than by address matching between consecutive signatures. A DKIM2-Chain-Sig for which no DKIM2-Chain-mf and no DKIM2-Chain-rt header field is present attests the state of the message and the responsibility of its signing domain and nothing about transmission. The d= to mf= match of Section 3.1.3 and the continuity check of Section 3.3.8 are not applicable to it and the continuity check at the following hop compares against hop i-2. Two constraints bound this case. Two consecutive signatures without envelope binding fields MUST NOT be present, so the gap is never longer than a single hop. The highest numbered signature MUST carry envelope binding fields, since it is the one verified against the transaction in progress and a message consisting exclusively of signatures without them is therefore not conformant. The base specification permits an unbroken sequence of more than one synthetic hop; this profile does not, because a bounded gap keeps the continuity check to a fixed comparison against the immediately preceding transaction. A signature carrying one of the two envelope binding fields and not the other is malformed and the result is a permerror. The omission described here is the omission of both. This is the case of an Email Service Provider signing on behalf of a brand, where the RFC5322 From identity and the envelope sender belong to different domains and only the second corresponds to an SMTP transaction. The brand signs with no envelope binding fields, the provider signs with its own and each domain is accountable for what it asserts. The relationship between the two is a contractual arrangement, not a cryptographic assertion in the message chain.

Attestation of a Received Transaction A node that receives an SMTP transaction and does not transmit the message onward in a transaction of its own may nevertheless sign it. This occurs where a message is delivered to a mailbox and the delivering domain seals what it stores. It occurs equally where a message is handed to an internal component such as a mailing list manager that will later cause a separate transmission. In both cases the signer has no outgoing envelope to describe and in both cases it does have an incoming one. The match of Section 3.1.3 runs in the opposite direction for such a signature. There the signing domain corresponds to the envelope sender, because the signature describes a transaction the signer presents. Here it corresponds to a recipient, because the signature describes a transaction the signer received. Such a signature carries the DKIM2-Chain-mf and DKIM2-Chain-rt values of the transaction it received, unchanged. It is recognised by one condition, which applies at every hop:

• the d= domain of the signature at hop i is at most two levels below the domain of at least one DKIM2-Chain-rt value at hop i, in the sense of Section 3.1.3.

The signer thereby names itself among the recipients of the transaction it describes. The d= to mf= match of Section 3.1.3 does not apply to a signature of this form and the condition above applies in its place. Where the hop is not the first, two further conditions are required:

• the DKIM2-Chain-mf value at hop i is identical to the value at hop i-1;
• the set of DKIM2-Chain-rt values at hop i is identical to the set at hop i-1.

Where both hold, the continuity check of Section 3.3.8 does not apply to the hop. These conditions are not redundant. Without them a node could name itself the recipient of a transaction of its own invention and thereby escape the continuity check. With them the envelope it attests is the one the preceding hop signed, which it is not free to choose. A signature that names its own domain among the recipients without reproducing the envelope of the preceding hop is not an attestation of receipt and is subject to Sections 3.1.3 and 3.3.8 as any other signature. At the first hop no preceding transaction exists, so no comparison is available and the single condition above is the whole test. A signature of this form at i=1 records that the signing domain received a transaction that carried no DKIM2 chain of its own and the DKIM2-Chain-Results of that hop states as much. The DKIM2-Chain-mf value of such a signature is the attesting domain's own record of the envelope sender presented to it. It is not an authentication of the domain named in it and no verifier is to read it as one. The only domain accountable for the signature is the one named in d=. A node that transmits the message onward in a transaction of its own does not use this form. Transmission requires rewriting the envelope sender into a domain the node can sign for, per Section 3.1.4, which produces an ordinary signature describing an ordinary transaction. The distinction is therefore settled by the topology at the point of signing and not by any decision taken at verification time. An implementation knows which form applies from whether an outgoing envelope exists. An attestation of receipt is never the signature that describes an outgoing transaction, because that position describes the transaction in progress while an attestation describes a transaction already completed. This does not immobilise the message. A node that transmits a message whose highest numbered signature is an attestation of receipt MUST add its own signature for the transaction it presents, so that the attestation becomes an intermediate hop of the chain. A message held in a mail store is presented in no transaction, so an attestation may stand as its highest numbered signature there for as long as the message is kept. A mailing list is the ordinary instance of this. The receiving domain attests the transaction it received and the list manager, which transmits later, rewrites the envelope sender into a domain it can sign for per Section 3.1.4 and signs above the attestation as any ordinary signer. The continuity check of Section 3.3.8 then applies to that hop unchanged, with the attestation as the preceding hop: the attestation carries both envelope binding fields, so the comparison is against the DKIM2-Chain-rt values at that hop, which name the attesting domain.

Formal Syntax The following ABNF defines the header fields introduced by this document. Rules are imported from and as noted. removal ; new= only -> addition ; del= + new= -> modification ; Shared index rules dkim2-chain-hop-number = 1*2DIGIT ; hop sequence number, 1-20, starts at 1 dkim2-chain-hop-index = "i=" dkim2-chain-hop-number dkim2-chain-rcpt-index = "v=" 1*3DIGIT ; recipient sequence number for DKIM2-Chain-rt ; starts at 1, increments per recipient at same hop, 1-500 dkim2-chain-mod-seq = "seq=" 1*2DIGIT ; modification sequence number for DKIM2-Chain-Mod, 1-20 ; Address rule dkim2-chain-addr = "addr=" [ Mailbox ] ; Mailbox as defined in [RFC5321] Section 4.1.2, ; extended per [RFC6531] Section 3.3 when the ; address contains non-ASCII octets ; including quoted local parts. ; The empty form is permitted only in ; DKIM2-Chain-mf, where it carries the null ; reverse-path of [RFC5321] Section 4.5.5 as ; described in Section 3.5.4. An empty addr= in ; DKIM2-Chain-rt is not permitted. ; Header field name header-field-name = 1*ftext ftext = %d33-57 / %d59-126 ; printable ASCII excluding colon, which terminates ; the field name per [RFC5322] Section 3.6.8. ; The semicolon is permitted: the value of field= ; runs to the first semicolon followed by SP, a tag ; name and "=", or to the end of the header field ; value. A field name cannot contain SP, so no other ; reading is available. No trailing semicolon is ; recognised after the field tag. ; Supporting rules tag-list = tag-spec *( ";" SP tag-spec ) [ ";" ] tag-spec = tag-name "=" tag-value ; a trailing semicolon is accepted on input ; and is not generated tag-name = ALPHA *( ALPHA / DIGIT / "_" ) tag-value = *( %x21-3A / %x3C-7E ) ; printable ASCII except semicolon domain-name = sub-domain *("." sub-domain) sub-domain = 1*( ALPHA / DIGIT / "-" ) selector-name = 1*( ALPHA / DIGIT / "-" / "_" ) base64string = 1*( ALPHA / DIGIT / "+" / "/" / "=" ) ; standard base64 alphabet per [RFC4648] ; Core rules imported from [RFC5234] ALPHA = %x41-5A / %x61-7A DIGIT = %x30-39 SP = %x20 DQUOTE = %x22 CRLF = %x0D %x0A ]]> The base64string production uses the standard base64 alphabet defined in . Header field names are case-insensitive per . The forms shown in this document are the forms this profile generates. The tag-value list syntax of the DKIM2 document set makes the semicolon at the end of a tag-list optional. The base specification defines the production and states the option in terms. The DNS document reproduces the same production and the debug header proposal of takes it from the base specification by reference rather than restating it. In the header fields defined by this profile a trailing semicolon is accepted on input and is not generated. The tolerance is safe here because the semicolon is structural punctuation inside a header field that is hashed as a whole, so two parsers that disagree about it agree on the hash and differ only on whether the field is accepted. This is not the case for a value that feeds a declaration, where a second admissible encoding of the same logical value would change what is reconstructed.

Header Accountability When a Reviser modifies, removes or adds a header field, it MUST declare the change by adding one or more DKIM2-Chain-Mod headers before signing. These headers MUST be included in the signed header set of the modifying hop and all subsequent hops, making the declaration cryptographically bound to the chain.

Modification Cases Modification - header existed and its value was changed. del= and new= on separate headers with same i= and seq=: Removal - header existed and was removed. Only del=: Addition - header did not exist and was added. Only new=: ]]> Note that new= is technically redundant for additions since the added value is already visible in the message headers. It is declared explicitly to provide an unambiguous cryptographic binding between the modification declaration and the hop signature, particularly in cases where multiple headers of the same type exist in the message. When a DKIM2-Chain-Mod header with del= and a DKIM2-Chain-Mod header with new= share the same (i=, seq=, field=) tuple, they MUST be interpreted as a single modification operation representing a value change. Implementations MUST NOT interpret them as independent operations - that is, as a removal followed by an unrelated addition. The tuple (i=, seq=, field=) is the sole correlating key. When present as a pair, the del= header MUST precede the new= header in the message. The dkim2-chain-mod-value production requires at least one octet between the delimiters - empty string values are not permitted. A header field whose value is the empty string is treated as absent for the purposes of DKIM2-Chain-Mod declarations.

Multiple Modifications Multiple instances of the same field, each with its own seq=: Successive hops use their own i=: The del= and new= tags MUST appear last in the DKIM2-Chain-Mod header field value. All other tags (i=, seq=, field=, fr=) MUST precede them.

Long Values For values that exceed practical inline length, implementations MAY use the optional fr= tag to split across multiple headers with incrementing fr= values. fr= is independent for del= and new=: fr= absent means value is complete in that single header. When fr= is present, headers with same i=, seq=, field= and same tag type (del= or new=) are concatenated in fr= order. Implementations that do not support fr= MUST treat a fragmented declaration as a null declaration for that field. Fragments MUST be concatenated without any intervening whitespace or separators. The reconstructed value is the exact concatenation of the fragment values in fr= order. The fr= tag value MUST be a positive integer starting at 1. A value of 0 or any negative value is malformed and MUST cause verification of that DKIM2-Chain-Mod declaration to fail. Fragments MAY appear in any physical order within the header set - implementations MUST reassemble them by fr= value rather than by physical position. If the fr= sequence contains a gap - that is, if fragment N is present but fragment N-1 is absent - verification of that DKIM2-Chain-Mod declaration MUST fail. Partial reconstruction from available fragments MUST NOT be attempted. A gap in the fr= sequence or a malformed fr= value SHOULD be logged as a potential integrity violation.

Relationship to Existing Conventions DKIM2-Chain-Mod headers formalize and cryptographically bind the informal X-Original- convention already widely deployed in the ecosystem. Systems using X-Original-From, X-Original-Subject and similar headers preserve previous header values across intermediary modifications - the same semantic goal as the del= tag in DKIM2-Chain-Mod. The key difference is that DKIM2-Chain-Mod declarations are included in the signed header set and cryptographically bound to the chain of custody, making them verifiable rather than merely informational. This pattern is already practiced informally in the ecosystem - for example, Google Groups preserves the original sender address in an X-Original-Sender header alongside its own Sender: field. DKIM2-Chain-Mod formalizes this existing convention by making the declaration cryptographically signed and part of the verifiable chain of custody, rather than an informational annotation with no authentication binding. This approach has precedent in , which proposed X-Prior- headers and Content-Footer headers as ARC extensions for the same purpose, declaring mailing list modifications in human-readable form without JSON encoding. DKIM2-Chain-Mod formalizes and generalizes this approach within the DKIM2 chain of custody framework.

Chain of Custody and Signature Each hop in the delivery chain MUST add a DKIM2-Chain-Sig header field signing the current state of the message. The chain of custody is established by the sequence of signatures and envelope bindings from originator to final recipient. DKIM2-core verification is hop-by-hop, not end-to-end. Each hop verifies the previous signature against the body it actually receives at the time of receipt. Attribution of body modifications does not require post-facto reconstruction: if bh= changes between hop N and hop N+1, the signing domain at hop N+1 is cryptographically identified as the modifier at the moment N+1 signs. No subsequent reconstruction is needed to establish who modified the body - the chain of signatures provides this attribution directly and verifiably.

DKIM2-Chain-Sig Formal Syntax Tags MAY appear in any order within the header field; each tag kind MUST appear at most once.

Signed Header Set The DKIM2 signature at each hop covers a specific set of header fields. The signed header set MUST include:

• All DKIM2-Chain-Results headers with i= values less than or equal to the current hop
• All DKIM2-Chain-mf headers with i= value equal to the current hop
• All DKIM2-Chain-rt headers with i= value equal to the current hop
• All DKIM2-Chain-Mod headers with i= value less than or equal to the current hop. DKIM2-Chain-Mod headers are subject to the same canonicalization rules as other signed headers per Section 3.4. The del= and new= values are canonicalized as header field values - line endings are normalized and folding whitespace is handled per the relaxed algorithm of Section 3.3.5.
• Any message header fields declared in the signer's h= tag
• All previous DKIM2-Chain-Sig headers with i= value less than the current hop or with i= value equal to the current hop and v= value less than the current signature's v= value. These are included in full, with their b= values intact
• The incomplete current DKIM2-Chain-Sig header with the b= value set to empty or a placeholder as defined in

When multiple DKIM2-Chain-Sig headers share the same i= value, the h=, d= and c= tags MUST be identical across all of them: the same signing domain, the same discretionary header list in the same order and the same canonicalization protect the same hop, differing only in signing algorithm. The s= tag MUST differ, as Section 3.3.3 requires, since a signer uses a distinct key selector per algorithm. Because h=, d= and c= are fixed, two such signatures describe the same canonicalized content. Where they also name the same hash algorithm in a=, their bh= and hh= values are identical and a mismatch between them is evidence of tampering and MUST be treated as a verification failure. This is not a novel constraint: the same body hash routinely appears unchanged across a DKIM1 signature and an ARC-Message-Signature covering the same message. Where the hash algorithms differ, as they may when a signature in a newer algorithm accompanies one in an older, the two sets of values are not comparable and no such inference is available. The integrity relationship between the signatures is then carried by the v= ordering alone, under which the signature with the higher v= covers the lower ones in full. Which algorithm a signer places at the highest v= is the subject of a recommendation in Section 3.6. DKIM2-Chain-Results is defined in Section 3.5.1. Received:, Return-Path: and other transport trace headers are excluded from the signed header set. They are also excluded from the hh= computation as specified in Section 3.3.5. Which header fields are declared in the signer's h= tag is at the signer's discretion. Signers SHOULD include headers that have security relevance for the message - From:, To:, Subject:, Date: - and SHOULD declare their inclusion or exclusion consistently across all messages. The b= value is calculated over the signed header set using the canonicalization algorithm specified in the signature, following the same procedure defined in Section 3.7. The header fields MUST be concatenated in the order listed above. This profile defines this order itself rather than relying on , which does not define DKIM2-Chain-mf, DKIM2-Chain-rt, DKIM2-Chain-Mod or DKIM2-Chain-Results as header types and therefore does not specify an ordering for them. Implementations MUST NOT assume that header fields arrive in a specific order. The signed header set is identified by field name and instance index (i=, seq=), not by physical position in the message. Intermediate MTA software may reorder header fields during transit without affecting chain of custody verification, since canonical ordering is established through the i= and seq= index values embedded in DKIM2-Chain-mf, DKIM2-Chain-rt and DKIM2-Chain-Mod headers. Implementations MUST use these index values, not header field position, to reconstruct the chain of custody.

Sequence Numbering DKIM2-Chain-Sig headers are numbered sequentially starting at i=1. Gaps in the sequence MUST be treated as making the message unsigned. A signer that adds a hop uses the single index one greater than the highest i= present and places every signature of that hop at that index. It MUST NOT add a header field at any other index. A field inserted at a lower index needs no rule of its own: the signed header set of Section 3.3.2 includes all DKIM2-Chain-Sig headers at lower indices in full and with their b= values intact, so an insertion below a signature invalidates that signature and is detected at the first hop above it. What remains is a second field at the index the signer is itself adding, which Section 3.3.2 governs, with one addition: the selector named in s= MUST differ between the signatures of one hop, since two signatures made under one key at one hop either agree, in which case the second is pointless, or differ, in which case the signer is presenting a verifier with two accounts of the same thing. Implementations MUST enforce the following per-type limits as a denial-of-service mitigation:

• i= (hop index): MUST NOT exceed 20. A realistic worst-case delivery path including nested mailing lists and security gateways at both ends does not exceed 15-16 hops; 20 provides margin without permitting pathological chains.
• v= (recipient sequence, DKIM2-Chain-rt): MUST NOT exceed 500 per hop. This is consistent with the recipient limits enforced by major MTA implementations.
• v= (signature ordering, DKIM2-Chain-Sig): MUST NOT exceed 4 per hop. The mandatory set of Section 3.6 holds two algorithms and a hop introducing a third alongside them has one index to spare, which is margin enough for an algorithm transition and does not permit a flood of signatures at one hop.
• seq= (modification sequence): MUST NOT exceed 20 per hop per field. A single hop modifying more than 20 instances of the same header field is not a legitimate scenario.
• fr= (fragment index): In DKIM2-core, implementations MUST NOT exceed 2 fragments per declaration. This limit reflects the practical constraint that a standard header field value cannot exceed 998 characters, requiring at most one continuation frame when combined with the DKIM2-Chain-Mod tag overhead of approximately 30 characters. A limit of 20 fragments would only be relevant if recipe content were transported in DKIM2-Chain-Mod headers - a use case that depends on architectural decisions about recipe storage not yet resolved in the base specification . DKIM2-extended implementations MAY increase this limit when recipe transport in headers is formally specified.

In addition, a message whose total size of DKIM2-specific headers (DKIM2-Chain-Sig, DKIM2-Chain-mf, DKIM2-Chain-rt and DKIM2-Chain-Mod) exceeds 128KB MUST be treated as a permerror. This global byte cap is a secondary defense-in-depth measure; the per-type limits above are the primary mitigation. The base specification carried contradictory statements on this point. An independent implementer working against its revision 06 reported that two of its sections disagreed on whether gaps in the i= numbering were acceptable. Revision 07 resolves the disagreement in the same direction as the requirement above and revision 08 states it in those terms: its Section 9.1 for Message-Instance revision numbers and its Section 10.1 for signature sequence numbers both state that a message with gaps or duplicates in the numbering is not a Fully Verified DKIM2 Message.

Body Hash (bh=) Each hop MUST calculate and include a body hash (bh=) of the current message body using the canonicalization algorithm specified in the signature. The bh= value changes whenever the body is modified, providing implicit notification that a modification occurred and attribution of that modification to the signing hop. No body recipe or reconstruction is required or expected in DKIM2-core. The change in bh= value between hops, combined with the identity of the signing domain at the modifying hop, provides sufficient accountability for delivery decisions. DKIM2-core replaces accountability-by-reconstruction with accountability-by-attribution: who modified the message and what they declared, not how to reconstruct the previous state. This substitution is not a reduction in security - it is a recognition that reconstruction is not required for the operational objectives of message routing and delivery decisions. Attribution is verifiable at each hop, applies uniformly to all intermediaries and remains available even for modifications that are irreversible by construction. The forensic value of reconstruction - where it exists - is preserved in DKIM2-extended as an optional layer for operators who require it.

Header Hash (hh=) The hh= tag contains a hash of all message header fields not excluded from the signed header set. This tag is OPTIONAL in DKIM2-core signatures. When present, it enables additional hop-by-hop integrity verification of declared modifications: while b= and DKIM2-Chain-Mod already provide cryptographic proof of each hop's own declarations, hh= with the rollback mechanism described in Section 3.3.7 allows each hop to verify that its predecessor has not omitted undeclared header modifications. Header canonicalization is always relaxed in this profile, as reflected in the c= production of Section 3.3.1. Only the body half of the c= pair varies. The following header fields are excluded from the hh= computation:

• Already covered by b=: DKIM2-Chain-Sig, DKIM2-Chain-mf, DKIM2-Chain-rt, DKIM2-Chain-Mod, DKIM2-Chain-Results
• Ephemeral or self-consistent, changing legitimately at every hop regardless of DKIM2 participation: Received, Return-Path, Authentication-Results (), ARC-*, DKIM-Signature, DKIM2-Signature and Message-Instance ()
• Vendor-specific diagnostic headers: X-MS-, X-GM-
• Exceptions to the vendor-specific exclusion apply to individual headers that cross organizational boundaries despite carrying a vendor-associated prefix. These exceptions are normatively defined, not a matter of prefix alone, and are detailed in Section 8.6.

The last two belong to the chain of the base specification, are covered by its own signatures and change at every hop that participates in it, so a node that runs both mechanisms on the same message does not have to declare them as modifications of its own. All remaining header fields, including other X-* headers, are included in the hh= computation. The rationale for including non-vendor X-* headers and the security implications of excluding them are discussed in Section 8.6. The hash algorithm used for hh= MUST match the algorithm used for bh= in the same DKIM2-Chain-Sig, as specified in the a= tag. The hash half of a= names the hash the verifier computes over the message content for bh= and hh=. It is not a statement about the internal construction of the signing algorithm. This profile carries the content hashes in the signature and names their algorithm nowhere else, so a signature MUST name a hash even where its signing algorithm takes no externally chosen digest: ML-DSA-44 in its pure form hashes the message within the signing operation, and a signature using it is written a=mldsa44-sha256 when the content hashes are SHA-256. The signing algorithm half corresponds to the name used in the base specification and the hash half is added by this profile. Where a signing algorithm does take an externally chosen digest the two SHOULD be the same hash, so that one computation over the body serves both the content hash and the signature. A hop carrying signatures that name different hashes is well formed and its bh= and hh= values differ accordingly, at the cost of one body hash computation per distinct hash. Canonicalization follows the DKIM1 relaxed algorithm per Section 3.4: header field names are lowercased, whitespace is normalized and continuation lines are unfolded.

Header Order and Multiple Instances DKIM2-core signatures cover a defined set of header fields, specified in Section 3.3.2. DKIM2-core signatures protect header fields at two levels. The signed header set covered by b= - the structural DKIM2 headers described in Section 3.3.2, together with any fields the signer additionally declares in h= - provides value-level protection consistent with DKIM1: any change to an included field's value invalidates the signature. The optional hh= tag provides set-level integrity for all non-excluded header fields, detecting undeclared additions and removals, as described in Section 3.3.5. When multiple header fields with the same name exist, their relative physical order in the message may be altered by intermediate systems - milters, antivirus scanners and content filters routinely reconstruct messages in ways that can reorder header fields with identical names. If the signed header set includes such fields and their order changes, any existing signature covering the original order will no longer validate. DKIM2-core addresses this through a two-level ordering strategy that minimises the surface area of ambiguous sorting. The first level covers all header fields included in the hh= computation. These are sorted alphabetically by lowercase field name. For most header fields, prohibits multiple instances at origination, so this sort operates on unique keys and is fully deterministic. This ordering is required at every hop that computes hh=, making it a wire-level constraint - but one that operates on field names only, not on field values, and that produces a fixed-size hash rather than an ordered sequence that downstream verifiers must reconstruct. The second level handles duplicate instances of the same header field using explicit i= and seq= index values declared via DKIM2-Chain-Mod, rather than physical position in the message. This is an integer lookup, not a string sort, and is unambiguous by construction. Section 3.3.7 defines the precise verification procedure. A residual case exists: header fields that permits in multiple instances at origination (such as Comments: and Keywords:) and that have no corresponding DKIM2-Chain-Mod entries. These instances are not attributed to any DKIM2-Chain-Mod declaration and must be disambiguated by a secondary sort on canonicalised field value. This sort is limited in scope - it applies only to the narrow set of multi-instance fields, which are rare in production traffic. If a field that defines as singular appears in multiple instances without a corresponding DKIM2-Chain-Mod declaration, this is a protocol violation; the verifier's required handling of this case is given in Section 3.3.7. Both DKIM2-core and the DKIM2 base specification require ordering computations. The difference is in the scope and determinism of the sort. The base specification mandates alphabetical ordering of all header field names with bottom-up ordering for duplicate names, applied to the full set of header fields that remain after the exclusions of its Section 4. The alphabetical component of that sort is deterministic and resolves reordering between distinct field names. It does not resolve reordering between instances sharing a field name: the bottom-up rule preserves whatever physical order the instances currently occupy, so a pair of instances transposed in transit is presented transposed after sorting. The base specification acknowledges this and places the obligation on any MTA that reorders same-named header fields to restore their original order before verification or onward relay. That obligation falls on nodes which, by definition of the case, are not participating in DKIM2 and have no signal that an order must be preserved. Interoperability testing at the IETF 124 hackathon in March 2026 confirmed failures between independent implementations attributable to disagreements on tag ordering within DKIM2-Signature fields - a simpler problem than duplicate header ordering, yet sufficient to cause failures. The base specification has since clarified that tags within a single header field may appear in any order, resolving that narrow point. This does not address the underlying problem. Duplicate instances of the same field name remain ordered by physical position, which is the case that DKIM2-Chain-Mod indices make unambiguous by construction. The reconstruction procedure compounds this: header field instances are numbered upward from the bottom of the header block, body lines downward from the top and the fields a recipe emits appear in the reverse of the order in which they are processed. Three directional conventions in one mechanism are an avoidable source of implementation divergence and an explicit index removes the need for any of them. DKIM2-core reduces the surface of ordering ambiguity to the minimum achievable without eliminating ordering entirely. Field-name sorting is deterministic on unique ASCII-lowercase keys. Duplicate ordering uses explicit integer indices for all hop-introduced instances. Value-based sorting is confined to the residual case of originals not attributed to any DKIM2-Chain-Mod declaration for multi-instance fields - a corner case that is rare in practice and bounded in scope. The base specification has no equivalent mechanism for disambiguating duplicates without relying on physical header position, which intermediate systems may alter.

Hop-by-Hop Header Integrity Verification When a verifier at hop i=N receives a message carrying an hh= tag, it performs verification in two sequential steps. This mechanism requires that all hops in the chain include hh= in their DKIM2-Chain-Sig. The verifier first establishes the canonical header set: all header fields present in the received message are ordered alphabetically by lowercase field name. Duplicate fields are ordered using the DKIM2-Chain-Mod declarations of hop i=N-1: fields without a corresponding DKIM2-Chain-Mod entry are originals; fields declared via DKIM2-Chain-Mod are ordered by their i= and seq= values. A duplicate field instance that cannot be explained by any DKIM2-Chain-Mod declaration in the chain is treated as an original field present at origination. If a header field defined as single-instance by appears more than once, each additional instance beyond the first MUST be accounted for by a corresponding DKIM2-Chain-Mod with a new= declaration. Unaccounted duplicates of single-instance fields constitute a protocol violation and the verifier MUST treat it as a verification failure. Original instances of the same field name are ordered among themselves by ascending canonicalised field value, as specified in Section 3.3.6. Their relative order at origination is not recorded anywhere in the message, so value ordering is what makes the set reproducible by every verifier. Where a header field name has both original instances and instances introduced by a DKIM2-Chain-Mod declaration, the original instances are ordered first, followed by the declared instances in ascending order of i= and, within the same hop, of seq=. This ordering reflects the sequence in which the instances entered the message and is applied identically when computing hh= and when reconstructing a prior header state under the rollback procedure of this section. The first step verifies the integrity of what hop i=N-1 signed. The verifier recomputes hh= over the canonical header set and compares the result against the hh= value declared in the DKIM2-Chain-Sig of hop i=N-1. If the values differ, the header set has been altered since hop i=N-1 signed it and the verifier MUST treat this as a verification failure. The second step is OPTIONAL and verifies that hop i=N-1 has not lied about its own declared modifications. The verifier applies the DKIM2-Chain-Mod declarations of hop i=N-1 in reverse: additions declared via new= are removed from the header set and removals declared via del= are restored to the header set with their original values. Modifications declared via both del= and new= are reversed by removing the new= value and restoring the del= value. The result is the header state as it should have been at hop i=N-2 according to what hop i=N-1 has declared. The verifier then recomputes hh= over this reconstructed header set and compares it against the hh= value declared in the DKIM2-Chain-Sig of hop i=N-2. If the values differ, hop i=N-1 has declared modifications that do not account for all changes it made and the verifier MUST treat this as a verification failure. In the monitoring phase of Section 5.6.2 nothing is rejected, by the definition of that phase, so the failure is recorded as a dkim2=fail result in the DKIM2-Chain-Results header and the message is delivered. This check is a single step backward, not a full chain traversal. Each honest hop performs the same check on its predecessor, so a lie introduced at any point in the chain is detected at the immediately following hop rather than at the final receiver. This property means that the chain self-validates during transit without requiring the receiver to reconstruct the entire message history. At i=1 there are no DKIM2-Chain-Mod declarations. The hh= value at i=1 covers the original header set and serves as the baseline against which hop i=2 will perform its rollback check. The mechanism does not require trust in intermediaries. Each hop verifies the previous signature cryptographically before signing its own. A hop that modifies a header without declaring it in DKIM2-Chain-Mod will produce a reconstructed header set that does not match the hh= of its predecessor and the discrepancy will be detected by the next honest verifier in the chain. The h= tag in DKIM2-Chain-Sig already provides cryptographic protection for the mandatory security-critical header fields. The hh= rollback mechanism extends this protection to the full non-excluded header set. The two mechanisms are complementary: h= provides hard guarantees on critical fields regardless of whether hh= is present and hh= provides additional assurance that no undeclared modification has occurred across the complete header set. Working group discussion has confirmed that localising a verification failure to a specific hop requires hop-by-hop verification, even when end-to-end verification is used as the primary mechanism.

Chain Continuity Between Consecutive Hops For every DKIM2-Chain-Sig with i= greater than 1, the domain of the DKIM2-Chain-mf address at that hop MUST match the domain of at least one DKIM2-Chain-rt address at hop i-1 or, where hop i-1 carries no envelope binding fields, at the nearest preceding hop that does, as described in Section 3.1.6. The match uses the relaxed domain match algorithm of Section 3.1.3 with the recipient domain in the role that the d= domain holds there, so the envelope sender domain MUST be at most two levels below the recipient domain it is matched against. The comparison is on the domain part only: a forwarding node rewrites the envelope sender into its own domain, as SRS does, so the local parts of the two addresses are not expected to correspond. The direction is the one that occurs in deployment, where a dedicated bounce domain is a subdomain of the domain that received the message. The reverse relation, in which the envelope sender domain is a parent of the recipient domain, does not satisfy this check. This check does not apply to a signature that attests a received transaction as defined in Section 3.1.6, which is subject to the check given there in its place. The constraint also closes the remaining replay path. An attacker that obtains a validly signed message cannot deliver it to a recipient of its own choosing by presenting the message unchanged without the mismatch being detected and recorded, because the replay check of Section 3.4 compares the DKIM2-Chain-rt values at the highest hop index against the RCPT TO of the transaction in progress. Adding a signature of its own does not help either. That signature carries its own DKIM2-Chain-mf, whose domain the present check requires to be a domain that was a recipient at the preceding hop. Signing for such a domain requires a key published under it. Extension of the chain is therefore restricted to parties that actually received the message. A failure of this check is cryptographic proof of dishonesty as defined in Section 3.5.2. The discontinuity is unambiguous: both signatures verify, so both hops are DKIM2 participants, yet the node at hop i declared an envelope sender in a domain that was not a recipient at hop i-1. A non-participating node cannot produce this condition, because it adds no signature at all. The message MUST therefore be rejected in enforcement mode, with the discontinuity recorded in DKIM2-Chain-Results.

Eight-Bit Content and Transport Conversion A body transferred as 8bit may be converted to a 7-bit content transfer encoding by an SMTP client that has to deliver to a peer which does not offer the 8BITMIME extension. The conversion rewrites the body and the Content-Transfer-Encoding header field, so it changes both bh= and hh=. Relaxed canonicalization does not absorb it: relaxed normalizes trailing whitespace, sequences of whitespace within a line and trailing empty lines, and has no effect on transfer encodings. Where the conversion is performed by a node other than the signer it is an ordinary body modification. A participating node signs the converted body under its own identity and the changed bh= attributes the change to it and a non-participating node breaks the chain as any other legacy node does. Where it is performed by the signing node itself it is invisible to the signer, because it happens during delivery, per recipient, after the message has been accepted and queued and no stage of a milter-based signer observes it. Signing the delivered form instead would require modification of the MTA, which is the dependency this profile exists to avoid. The base specification addresses transport conversions in its Section 17, which requires that a Signer sign the message as it is expected to be received by the Verifier rather than in a local or internal form and that any conversion of a local encoding to canonical form be applied to the message actually sent rather than only to the version presented to the signing algorithm. The case described here is the one in which that requirement cannot be satisfied at signing time: whether the body will be downgraded is determined per recipient, during delivery, after the signature has been computed, so the signer cannot know the form in which the message will be received. This profile does not require signers to normalize every body to a 7-bit content transfer encoding in order to prevent the case, since that cost falls on all traffic to protect a diminishing path and Section 5.3 already places such normalization with the originating user agent or submission agent rather than with the signer. The failure it produces is an undetermined-cause failure under Section 3.5.2, delivered with its result recorded rather than rejected. A receiver whose traffic still reaches peers without 8BITMIME is by that fact not in the terminal phase. An operator who wants the signature to survive that path normalizes upstream of the signer or configures the MTA not to convert.

Replay Prevention Replay prevention is a direct consequence of envelope binding. Since DKIM2-Chain-mf and DKIM2-Chain-rt are cryptographically signed at every hop and contain the actual SMTP envelope values, it is impossible to reuse a valid signature for a different recipient without breaking the chain. The comparison is an inclusion in one direction. Every recipient of the transaction in progress MUST appear among the DKIM2-Chain-rt values at the highest hop index. Recipients present in those values and absent from the transaction in progress are not a mismatch: a relay that adds no signature may split one transaction into several by destination, so the signed recipient set is a superset of the recipients of each resulting transaction. The condition this check detects is a recipient of the transaction in progress that appears in no DKIM2-Chain-rt value at the highest hop index. An attacker who attempts to replay a message to a recipient not listed in DKIM2-Chain-rt will produce that condition. A node that received the message and forwards it to a recipient of its own without adding a signature produces the same condition. The two are not distinguishable from the message, since the forwarding node leaves no signature, while the envelope sender it presents, whether the original or one rewritten into its own domain, is one that a replaying party which was itself a recipient can present equally. The condition is therefore detected with certainty while its cause is not, which makes it an undetermined-cause failure under Section 3.5.2: the message is delivered with the mismatch recorded in DKIM2-Chain-Results and is rejected in the terminal phase, where every failure is. This is what replay prevention costs while non-participating nodes remain in the paths and it is the limit Section 5.3 records. Mailing list redistribution is not a replay attack. When a mailing list receives a message and redistributes it to subscribers, it adds its own DKIM2 signature with its own DKIM2-Chain-mf and DKIM2-Chain-rt values, explicitly declaring the redistribution. The chain of custody shows the original sender, the mailing list and the final recipient as distinct entities in the chain.

Verification Reporting, Enforcement and DSN Handling This section defines how DKIM2-core verification results are reported and enforced and how the resulting accept/reject decisions propagate through delivery status notifications (DSNs) without causing backscatter to innocent sender domains.

DKIM2-Chain-Results DKIM2-core defines a per-hop verification result header analogous to ARC-Authentication-Results. The header is produced by the inbound verifier and records the outcome of chain verification for the hop index at which verification was performed. The i= value identifies the hop at which verification was performed. What that hop verifies is the signature at hop i-1, since no signer attests its own signature, so at i=1 the value is always none. The authserv-id is the FQDN of the MTA performing verification. DKIM2-Chain-Results carries no header.d= value: the i= index already identifies which DKIM2-Chain-Sig the result applies to and the signing domain can be read directly from that signature's own d= tag, so reporting it a second time here would be redundant. This differs from Authentication-Results for DKIM1 , where header.d= is needed because a message can carry multiple unordered DKIM-Signature fields with no equivalent index to disambiguate among them. DKIM2-Chain-Results travels only on messages that are accepted, since a message refused with a 5yz response or deferred with a 4yz response carries nothing onward. In the monitoring phase of Section 5.6.2 every outcome is accepted and therefore recorded in the header field. From the policy enforcement phase onward the outcomes that lead to a refusal or a deferral leave a local record only. The header field then carries the outcomes that accompany an acceptance. A registration of a dkim2 method in the Authentication-Results header field of has since been proposed in , with the properties header.d and header.i and the result codes none, pass, fail, permerror and temperror. That mechanism and this header field differ in what becomes of the record rather than in what it contains. An Authentication-Results field carries no signature, so a party beyond the ADMD that wrote it has no basis on which to rely on it. Section 5 requires an ADMD to delete an inbound instance bearing its own authserv-id unless it came directly from another trusted MTA, so such a record does not even survive the boundary it was written for. DKIM2-Chain-Results is part of the signed header set of every subsequent hop, as Section 3.3.2 requires, so the record of each hop travels with the message and is covered by the signatures that follow it. Each hop adds the header carrying its own i= value, so a message that has traversed three signing hops carries three. For example:

Verification Result Reporting and Graduated Enforcement The base specification defines a binary delivery model: a message either passes chain verification and is accepted or fails and is rejected during the SMTP session. No mechanism is provided for recording intermediate verification results, for communicating partial chain validity or for expressing graduated enforcement policy. This is a structural gap, not a missing edge case. During any realistic deployment period - and operational experience with ARC suggests this period may be indefinite - messages will transit legacy nodes that break the chain without malicious intent. A binary accept/reject model applied to these messages produces either false rejections of legitimate mail or no enforcement at all. Neither outcome is acceptable. The adoption burden this implies is materially heavier than for comparable mechanisms. DMARC enforcement requires a single DNS policy record: sender and receiver agree and intermediate nodes do not need to participate at all - they simply pass mail through. Even so, DMARC's interaction with mailing lists produced well-documented, severe breakage. DKIM2's chain of custody instead requires every node in the delivery path - every forwarder, list and gateway - to be DKIM2-aware before a binary enforcement model behaves as the base specification implies. Treating full-path participation as a precondition for accepting mail does not describe a transition path - it describes rejecting legitimate mail as routine behavior for as long as any non-participating node remains anywhere on the path, which may be years or may never fully resolve. This burden has been quantified from operational experience. Matthew Grove of Intuit reported to the working group in August 2026 that, under the 2024 bulk sender requirements adopted by major mailbox providers, roughly 20% of senders above the volume threshold had not completed the required DNS changes two years later. The senders concerned were not refusing to comply. Some did not understand what was being asked of them. Others could not make the change at all: their site is on one platform while their DNS is on another, the credentials are held by a web developer or an agency, or the hosting platform does not expose the records in its interface. The requirement in that case was a single DNS record, published once, at the sending domain only. It required no software on any node, no change to message format and no participation by intermediaries. That figure therefore measures the floor of the adoption problem rather than its ceiling: a mechanism that requires every node on the delivery path to run new software, declare its modifications and maintain a signing key is not comparable in difficulty to publishing one record. The population that a binary enforcement model excludes first is the one with the least dedicated mail infrastructure and it is the population for which this profile is written. The same discussion raised a question that the working group has not resolved. If major mailbox providers apply to DKIM2 the exemption for small senders that they applied when introducing the bulk sender requirements, a substantial population of DKIM1-signed mail remains in circulation and the replay conditions that motivate DKIM2 remain largely in place for it. If instead no exemption is made, the adoption burden falls on precisely the operators documented above as unable to complete a single DNS change. Whether universal deployment is a design requirement of the replay mitigation or whether enforcement above a volume threshold suffices, the graduated enforcement model defined in this section does not depend on the answer: it derives the enforcement level from adoption observed locally, so a receiver applies the strictness its own traffic supports rather than the strictness the specification assumes. DKIM2-core requires the DKIM2-Chain-Results header described above to record the outcome of chain verification with the full set of verdicts. This result is consumed by downstream filtering systems for policy decisions, exactly as Authentication-Results is consumed today. The critical distinction for enforcement policy is between verification failures that constitute cryptographic proof of dishonesty by a DKIM2-participating node and failures whose cause cannot be determined from the message alone. These two cases are not always distinguishable from the raw failure codes and getting this distinction right is what makes rejection safe. Throughout this section, enforcement mode means the policy enforcement phase of Section 5.6.2. In the monitoring phase that precedes it nothing is rejected or delayed, by the definition of that phase, so every outcome below is recorded in DKIM2-Chain-Results and delivery proceeds. In the terminal phase that follows it every failure is rejected, so the classification below no longer governs the disposition. The following enforcement model applies: Structural failure - a DKIM2-Chain-Sig whose signing key record does not exist or is invalid, an unknown algorithm, a syntax error or a sequence gap - constitutes a permerror. Verification cannot be attempted at all. The message MUST be rejected in enforcement mode regardless of transition period considerations. These failures cannot be produced by an innocent legacy node: they indicate either a misconfigured DKIM2 implementation or a forged header. Transient failure - a condition that prevented verification and may not recur, such as a DNS lookup for a signing key that failed or timed out - constitutes a temperror. In enforcement mode the verifier SHOULD defer the message with a 4yz response so that the sending system retries. The signature MUST NOT be treated as verified. Where a hop carries more than one signature, a temperror on one of them is not satisfied by the success of another: deferring costs a delay, while accepting on the signatures that remain would let a party able to prevent resolution of one selector choose which signature decides the outcome. Cryptographic proof of dishonesty is present when the b= verification of the most recent DKIM2-Chain-Sig succeeds and the hh= value it covers matches the current header set, but the rollback of declared DKIM2-Chain-Mod modifications does not reconstruct the hh= value committed by the preceding hop. If b= is valid, then hh= and all DKIM2-Chain-Mod declarations are guaranteed intact. If the rollback then fails, the signing node at i=N declared modifications that do not account for all differences between the header state it received and the header state i=N-1 signed. This is cryptographic proof that i=N misrepresented its modifications. The message MUST be rejected in enforcement mode. Undetermined-cause failure covers every other outcome in which b= itself verifies: hh= mismatch alone, bh= mismatch alone or both together, as well as rollback failure when hh= has already failed and cannot be trusted as an input to it. In each of these cases b= confirms that the DKIM2-Chain-Sig header field the signing node produced is genuinely what that node signed - nothing about the signing node's own declaration is in question. What has changed is content outside that guarantee: header fields not covered by the signed header set, the body or both. The verifier cannot determine whether that change was made by a non-participating legacy node performing ordinary message handling or by an attacker exploiting the same absence of a signature. No reconstruction mechanism resolves this. Recipes and DKIM2-Chain-Mod declarations both depend on the modifying party participating and declaring what it changed - a non-participating node does neither by definition, so the ambiguity is not a gap in the reconstruction machinery. It is what non-participation means and no mechanism can close it after the fact. In enforcement mode, the message MUST be delivered with the verification result recorded in DKIM2-Chain-Results as failed with cause undetermined, rather than attributed to any specific actor. Downstream policy systems MAY use this result to apply local filtering. The same classification applies where b= itself does not verify and no later signature is present. The signed content was altered by a party that did not sign, which is the case described in Section 5.3 for a chain broken by a non-participating node. The guarantee the model gives is that no message is rejected unless its failure identifies the party responsible for it, so legitimate mail transiting legacy infrastructure is not lost. One further condition is rejected in enforcement mode without belonging to either class above: the partial pass of Section 3.6, where a verifier able to evaluate every signature at a hop finds that one verifies and another does not. The terminal phase of Section 5.6.2 is the state in which every failure is rejected. The classification above exists to make rejection safe while nodes that modify messages without declaring their modifications are still a normal feature of the delivery path and its purpose is to avoid refusing legitimate mail on evidence that does not identify a responsible party. Once a receiver's own traffic no longer contains such nodes in any material quantity that purpose is exhausted: a chain that does not verify is an error and the disposition follows the verdict, without further qualification of its cause. Entry into this phase is a local decision taken on local evidence. This profile sets no date and no threshold for it, because the evidence is the receiver's own traffic and no external party can observe it. A receiver that enters this phase SHOULD continue to record verification results as in the monitoring phase, so that the decision remains reversible on the same evidence that justified it. Across the monitoring, enforcement and terminal phases the verdict itself does not change. The specification states whether the chain is valid and local policy decides the disposition, so a stricter phase alters what is done with a message and never the verification result recorded for it. The same separation applies to assertions a sender places in the message. A request that intermediaries handle a message in a particular way does not bind the receiver, because nothing in the mechanism verifies whether it was honored and a node that disregards it is under no obligation to reveal that it did. This profile derives disposition from verification results and from local policy, and from nothing else.

Verification During SMTP Session DKIM2-core verification is performed during the SMTP session at two distinct points: During RCPT TO - the inbound milter MAY perform local policy checks based on the envelope sender and recipient, for example checking against local allowlists or denylists. No DKIM2-specific verification is possible at this stage because the message headers, including DKIM2 signatures, have not yet been received. At EndOfBody - full signature verification is performed when the complete message and accumulated envelope state are available. The inbound milter verifies the DKIM2 signature chain, the envelope binding in DKIM2-Chain-mf and DKIM2-Chain-rt and the consistency of DKIM2-Chain-Mod declarations with the signed header set. The milter then returns one of the following to instruct the MTA:

• SMFIS_CONTINUE - the message passes verification or the failure does not constitute cryptographic proof of dishonesty by a DKIM2-participating node; the MTA proceeds with delivery and the result is recorded in DKIM2-Chain-Results
• SMFIS_REJECT - a structural failure or proven dishonesty is detected per the graduated enforcement model in Section 3.5.2; the MTA issues a 5xx rejection to the connected peer
• SMFIS_TEMPFAIL - a transient error occurred, for example a DNS timeout during key lookup; the MTA issues a 4xx temporary failure to the connected peer

When the milter returns SMFIS_REJECT, the MTA issues a 5xx rejection directed at the connected peer - the system currently delivering the message over the active SMTP connection. This rejection is never directed at the original envelope sender. This is the fundamental mechanism that prevents backscatter: no DSN is ever generated toward an address that was not the source of the current SMTP session.

Reject Propagation and Backscatter Prevention When a DKIM2-core node rejects a message with 5xx during the SMTP session, the connected peer (the previous hop in the delivery chain) receives the rejection and is responsible for generating its own rejection toward its own peer in turn. Each hop manages its own rejection independently. The original sender is reached through this chain of independent rejections without generating backscatter at any point. A node that accepts a message with an invalid or missing DKIM2 signature and subsequently generates a DSN to the original envelope sender produces backscatter. The base specification does not forbid this in terms. Its Section 13.2 states that for a message that has not been Provisionally Verified "a DSN generated after the message has been accepted may go to a third party whose address was forged" and concludes that the best strategy for a clearly invalidly signed message is to reject it while the SMTP conversation is still open. The prohibition that follows is this profile's own. A node reaches that situation by accepting a message whose verification did not pass, which Section 3.5.2 requires of it where the cause of the failure cannot be determined and Section 3.5.6 confirms for a message that carries no DKIM2 signature at all. Nodes that do so MUST NOT generate a DSN to the original envelope sender on the strength of that verification outcome. A notification directed at the connected peer instead requires an address for that peer, which exists only where the peer presented an envelope sender of its own, as Section 3.1.4 requires of a node that forwards and signs. Where that address is not available the node has no addressee for a verification failure and the message is lost without notice. Section 6.1 requires a receiver that has accepted a message and then fails to deliver it to mail a notification to the address in the envelope return path, so a node in that position stands between that requirement and the prohibition above. The case arises only where verification is deferred past the SMTP session. Section 3.5.3 places it inside the session, where a failure is reported in the SMTP response and nothing has to be generated afterwards. A receiving system that accepts at its edge and verifies later, or whose externally facing MX does not participate at all as described in Section 3.1.6, gives up that reporting path. A failure it detects afterwards can be recorded but not reported. A failure that arises after acceptance for reasons unrelated to verification, such as an unavailable mailbox, is an ordinary bounce and is addressed to the envelope sender the node received in the usual way.

Authenticated DSN Generation A node that has accepted a DKIM2-signed message and needs to generate a DSN does not need to possess a signing key aligned with the DKIM2-Chain-rt value at the incoming hop. It needs only to sign the DSN with a key authorized for its own domain and direct it to the connected peer that delivered the original message. The DSN propagates back along the chain via the same hop-by-hop rejection mechanism described in Section 3.5.4. This is ordinary outbound signing, not a DSN-specific mechanism. The DSN itself is produced by standard MTA bounce-generation logic, independently of DKIM2; the milter's role is limited to signing it as a newly originated message, exactly as it would sign any other outbound mail from the domain. The bounce carries no DKIM2 signatures from the original delivery chain and there is no chain-of-custody state to extract, redact or forward from the rejected message into the bounce - a class of complexity that arises only when a DSN mechanism is required to carry and selectively strip prior chain state. When the DSN envelope sender is the null address per , the DKIM2-Chain-mf field carries an empty addr= value. The d=/mf= alignment check defined in Section 3.1.3 is not applicable for null-sender messages. The verifier identifies the message as a DSN by the empty mf= value; the signing domain's identity is established by the d= tag and the corresponding DNS key record. The verifier MUST proceed with full chain verification - including signature validation, hop sequence integrity and the hh= rollback check where present - and record the result in DKIM2-Chain-Results as for any other message. The verifier MUST NOT issue a rejection response to a null-sender message regardless of verification outcome. This is a permanent protocol requirement, not a transitional measure: rejection of a null-sender message risks a mail loop if the sending MTA does not correctly implement Section 6.1 null-sender loop prevention. The verification result is recorded for downstream policy evaluation. During the transition period and for as long as any non-participating node remains on a delivery path, null-sender messages without DKIM2 signatures will continue to arrive. This is not a condition that a mature deployment eliminates, since complete participation is never achieved on every path, as Section 5.3 records. The rule above therefore applies in every phase of Section 5.6.2 and is an exception to the terminal phase, which otherwise rejects every failure.

Receiving Mail from Non-Participating Paths Where a receiver gets a message without a valid DKIM2 signature it cannot perform DKIM2-specific verification: envelope binding, chain of custody validation and authenticated DSN generation toward the connected peer are not available. This is not confined to a transition period, since complete participation is never achieved on every path, as Section 5.3 records. The receiver falls back to pre-DKIM2 behavior: verify DKIM1 signatures if present, apply DMARC policy if configured and generate DSNs as today. Whether this fallback alone justifies rejection is governed by the graduated enforcement model of Section 3.5.2 - it does not, on its own.

Cryptographic Algorithms DKIM2-core mandates support for the RSA-SHA256 and Ed25519-SHA256 signing algorithms. Verifiers MUST implement both. The base specification Section 3 requires more: a verifier there MUST implement five algorithms, the SHA256 and SHA512 hashes and the RSA-SHA256, Ed25519-SHA256 and ML-DSA-44 signing algorithms, while a signer MAY implement any subset of them. This profile does not adopt that requirement. A signature in an algorithm outside the set above is handled by the rule given later in this section, which judges the hop on the signatures the verifier is able to check. A post-quantum signing algorithm changes the cost of verification and not only the size of the key record. The ML-DSA-44 public key is 1312 octets, which is about 1752 characters of base64 and seven TXT strings of the maximum length. A response carrying it exceeds both the 512 octet limit of DNS over UDP and the 1232 octet buffer size commonly advertised with EDNS0, so the lookup is answered with a truncated response and repeated over TCP, with the handshake that this implies. Verification performs one key lookup per hop, so an algorithm of this size moves the key lookups of every participating hop onto TCP. This profile takes no position on which algorithms the base specification should mandate. It records that the choice carries a per-hop cost at verification time, which is the cost this profile exists to keep bounded. The ecosystem's record on algorithm transition is measurable. A longitudinal study of 464 million DKIM signatures collected between March and October 2020 found that 65.8% of signing domains were still producing rsa-sha1 signatures , two years after removed that algorithm from DKIM, and that 84% of the keys in a separate sample of 3.6 million domains were 1024 bits or shorter. That study observed one large provider in one country, so its absolute figures are not a census of the whole ecosystem. Two mailboxes at unrelated domains operated by the author of this document give a receiver's view of the same question. The first carries 63000 signatures received between 2024 and 2026, of which rsa-sha256 accounts for 96.6%, rsa-sha1 for 3.3% and ed25519-sha256 for 0.068%, 43 signatures in all. The second carries 16292 signatures received between 2011 and 2026 and contains no ed25519 signature at all. In 2026 the first mailbox received 78 rsa-sha1 signatures and 42 ed25519 signatures, so at that vantage point an algorithm withdrawn from DKIM in January 2018 remains almost twice as common as the algorithm added in September of the same year. These are single-observer samples and the ed25519 signatures of the first mailbox fall almost entirely in one year, so they may originate with a small number of senders. The transition these figures describe asked a signer for one key record and one algorithm name. The base specification asks every verifier to implement five algorithms. A profile that rests on that requirement being met rests on a change of a different order from the one the ecosystem has not yet completed. Signers SHOULD implement both algorithms and MAY sign a message with multiple algorithms simultaneously - for example RSA-SHA256 for compatibility with legacy verifiers and Ed25519-SHA256 for efficiency. Multiple DKIM2-Chain-Sig headers sharing the same i= value are ordered by the v= tag defined in Section 3.3.1 - the same index used for DKIM2-Chain-rt; see Section 3.3.2 for how this affects the signed header set. The tag-value format of DKIM2-Chain-Sig imposes no constraints on the signing algorithm beyond producing a binary output encodable in base64. This ensures forward compatibility with post-quantum algorithms when they are standardized for use in email authentication. Where a signature uses an algorithm outside the mandatory set and the verifier does not implement it, that signature is not evaluated and the hop is judged on the signatures the verifier is able to check. The result recorded for that hop is neutral, which states that the hop was accepted on the signatures that could be checked and not on all of those present. This is what allows a new algorithm to be introduced without a flag day: a verifier that does not yet implement it is unaffected by its presence. It is not a partial pass, which is defined below and concerns a signature the verifier can check and which fails. Where the verifier is able to check no signature at all at a hop, there is nothing on which to judge it and the hop is not reported as a pass. A signer is required below to include at each hop a signature in an algorithm of the mandatory set and a verifier of this profile implements both algorithms of that set, so this state is reachable only where that requirement was not met or where the signature that met it was removed. It is a defect of the message and not a limit of the verifier. It is therefore a permerror of the structural class of Section 3.5.2. The verifier MUST reject the message in the policy enforcement phase of Section 5.6.2 and in the terminal phase that follows it. In the monitoring phase nothing is rejected and the outcome is recorded like any other. No exception is made for an algorithm the verifier recognises by name and does not implement: a rule that tolerated the absence of any checkable signature would be available to an attacker that strips the signatures of a hop and leaves one naming an algorithm nobody implements. Revision 08 of the base specification assigns a permanent error to a signature in an algorithm the verifier has not implemented. This profile does not. It follows instead, whose Section 3.3.4 states that "Verifiers MUST ignore any signatures using algorithms that they do not implement" and whose Section 3.4 states the same rule for unrecognized canonicalization algorithms. A signature that cannot be evaluated is not a failed signature. The distinction is recorded rather than resolved: the hop is reported as neutral in DKIM2-Chain-Results, with the algorithm that was not evaluated named in the comment. The answer of the base specification holds only where every verifier implements every algorithm it defines. Where that does not hold, its four output states carry no verdict for a signature that was not evaluated, so an error is the only one available to it. The registry of result names for the dkim method of carries the verdict this case needs. Its Section 2.7.1 defines neutral as the result where "the signature or signatures contained syntax errors or were not otherwise able to be processed", which is this case exactly. The dkim2 method proposed in declines it, stating that a DKIM2 verification produces no neutral result. This profile adopts it, as Section 3.5.1 defines, and the message travels on. A signer MUST include at each hop at least one signature in an algorithm of the mandatory set above. Signatures in other algorithms are additional to it and never a substitute for it. The algorithm named in a= and the key type published in the key record are two statements about the same signature and a verifier MUST check that they agree. Where the record names a type that does not correspond to the signing algorithm of a=, verification MUST NOT be attempted and the result is a permerror of the structural class of Section 3.5.2: a failure produced by using an unsuitable key would be recorded as a failure of the signature and would misstate its cause. A record whose k= names a type the verifier does not recognise is ignored, as Section 3.6.1 requires, and the signature is then one the verifier is unable to check. A record whose p= value is empty declares the key revoked and gives a permerror. The v= ordering of Section 3.3.1 has a consequence for this case. Because a signature with a higher v= covers the signatures with lower v= at the same hop in full, including their b= values, a signer that places the most widely implemented algorithm last makes that signature a witness to the presence and integrity of the others. A verifier that cannot evaluate the earlier signatures still hashes their header fields like any others, so their removal or corruption breaks the signature it can evaluate. Signers SHOULD therefore assign the highest v= at a hop to the algorithm they expect the largest number of verifiers to implement. The protection this affords is against a party that strips or alters a signature and not against one able to forge the algorithm the verifier relies on, since such a party can produce a consistent outer signature over any content it chooses. When a message carries signatures for multiple algorithms at the same hop, a verifier that supports all those algorithms MUST treat the failure of any one signature as invalidating the entire hop. This prevents a downgrade attack in which an attacker invalidates the signature in the stronger algorithm in order to force acceptance on the weaker one. It does not prevent the same attacker from removing that signature instead, since the set of signatures present at a hop is chosen by whoever last handled the message and a verifier has no way to know that a signature it never received once existed. Closing that case requires a statement an attacker cannot edit out, which means one published in the DNS, and Section 3.6.1 defines an optional record for that purpose. Where a verifier is able to evaluate every signature at the hop, a state in which one verifies and another does not is not admissible. The signature that verifies establishes that the signed content is intact, since all signatures at a hop cover the same canonicalized content, so the failure of the other cannot be the modification in transit that the undetermined-cause class of Section 3.5.2 exists to accommodate. The verifier MUST reject the message from the policy enforcement phase of Section 5.6.2 onward. In the monitoring phase nothing is rejected, by the definition of that phase. No exception is made for a signature that failed through a defect in the software that produced or checked it. A defect and an attack are indistinguishable from the message. A rule that excused the first would excuse the second. A signature that is present and does not verify is a failure of the hop that made it and that holds whether the signature was defective when produced or was damaged in transit. The two possible rules differ in what they tolerate. A rule that accepts a hop on any single valid signature tolerates a cryptographic break that has not become public, since a party able to forge one algorithm needs only to present that signature alone. A rule that requires every checkable signature to verify tolerates no defect in the software that produced them. This profile takes the second position. The cost of doing so while a new algorithm is being introduced falls in the monitoring phase of Section 5.6.2, where nothing is rejected. Revision 08 of the base specification allows a signer to declare how its signatures combine, with a comma joining signatures into a group that passes only if all of them pass and a vertical bar separating groups of which any one passing suffices. This profile does not act on that declaration. It evaluates every signature at a hop that it is able to check, requires all of those to verify and leaves the rest unevaluated, which is the rule stated above and does not vary with what the signer asks for. There are two reasons. A declaration of this kind cannot be relied upon, for the reason given above: the signatures that reach a verifier are the ones the last handler chose to send, so a party able to forge one algorithm presents a group that names only that algorithm. And acting on it introduces a failure that falls on legitimate mail, because a verifier that implements two algorithms of a group of three must fail a message whose content it could have verified. A signer cannot know what a receiver implements, so a conjunction declared in the message is a wager on the receiver's capabilities whose penalty is paid by the message. For body hash calculation, DKIM2-core supports both relaxed and simple canonicalization as defined in Section 3.4. The choice of canonicalization algorithm is indicated in the signature and is a per-hop decision. The choice between relaxed and simple canonicalization for body hashing reflects a fundamental tradeoff documented in Section 3.4. Relaxed canonicalization tolerates common modifications made by intermediate systems, such as whitespace replacement and header field line rewrapping, at the cost of reduced sensitivity to intentional modifications. Neither canonicalization absorbs a change of content transfer encoding; see Section 3.3.9. Simple canonicalization detects all byte-level changes but is more sensitive to involuntary transformations. DKIM2-core implementations that include legacy infrastructure in their deployment path SHOULD use relaxed canonicalization for body hashing to maximize chain continuity.

Optional Declaration of Signing Algorithms A domain MAY publish the set of signing algorithms it uses, so that a verifier can distinguish a signature that was removed from one that was never made. The declaration is published as a TXT record at _dkim2 under the domain and is a tag-value list of the form used for key records. It is published under a name of its own because keys are published per selector and requires the TXT records for a selector to be unique, stating that the results are undefined where an RRset holds more than one. The v= tag MUST be present and MUST be the first tag. The a= tag carries a colon-separated list of algorithm names in the form defined in Section 3.3.1. Other tags MAY be present and MUST be ignored by a verifier that does not understand them, and unrecognised algorithm names MUST be ignored. A verifier MAY fetch this record for the signing domain of any hop it verifies. Where the record is present, every algorithm it names MUST be present among the signatures at that hop. A named algorithm that is absent is evidence that a signature was removed after it was made and the hop MUST NOT be reported as a pass. Where the record is absent the hop is judged by the rules above and its absence is not a negative indicator. The declaration describes how the domain signs and is evaluated per hop against the signatures carrying that domain in d=. A domain that signs with different algorithms under different selectors cannot be described by one record and SHOULD NOT publish one. A domain that stops using an algorithm MUST remove it from the record and wait for the record's time to live to expire before it stops signing with it, since a declaration that outlives the practice rejects the domain's own mail. Two limits are inherent. A party able to suppress the DNS response removes the commitment, and a verifier cannot distinguish a record that is absent from one that was suppressed, where a suppressed key record produces a temporary error instead. The mechanism therefore raises the cost of exploiting a broken algorithm and does not defend against control of the resolution path. And it costs one additional lookup per distinct signing domain, cacheable for its time to live, which is why publishing it and checking it are both optional.

Milter Implementation DKIM2-core is designed to be implementable via the milter interface without modifications to MTA core software. This section describes the recommended deployment patterns.

Two-Milter Pattern The recommended implementation uses two milter instances. The protocol flow described in Section 3.5 maps to the milter callbacks as follows: Inbound milter - runs on the receiving MTA. Operates at two points in the SMTP session:

• During RCPT TO: MAY perform local policy checks based on the envelope sender and recipient - for example checking against local allowlists or denylists. No DKIM2-specific verification is possible at this stage because the message headers, including DKIM2 signatures, have not yet been received.
• At EndOfBody: performs full DKIM2 verification with access to the complete message and accumulated envelope state from MailFromRequest and RcptToRequest callbacks. The milter verifies the DKIM2 signature chain, the envelope binding in DKIM2-Chain-mf and DKIM2-Chain-rt and the consistency of DKIM2-Chain-Mod declarations with the signed header set. The milter applies the graduated enforcement model defined in Section 3.5.2 to determine the appropriate return value: SMFIS_REJECT for structural failures or proven dishonesty, SMFIS_TEMPFAIL for transient errors, SMFIS_CONTINUE otherwise.

The inbound milter requires no persistent state between sessions - all information needed for verification is available within the current SMTP session. Implementations using RSA-SHA256 MAY initiate DNS key lookup at EndOfHeaders as an optimization when d= and s= are available from the DKIM2-Chain-Sig header, reducing the time spent waiting for DNS resolution at EndOfBody. Implementations using Ed25519-SHA256 or supporting multiple algorithms MUST defer all DNS lookups and signature operations to EndOfBody, where the complete signed header set is available. Full signature verification including body hash comparison MUST be performed at EndOfBody regardless of algorithm. Outbound milter - runs on the transmitting MTA, positioned last in the milter chain after all other milters that may modify the message. Operates at EndOfBody with access to:

• The complete message in its final state after all other milters
• Envelope values accumulated via MailFromRequest and RcptToRequest callbacks
• All DKIM2-Chain-Mod headers added by modifying entities earlier in the chain

Constructs DKIM2-Chain-mf and DKIM2-Chain-rt from envelope values, validates the formal correctness of any DKIM2-Chain-Mod headers present and adds the DKIM2 signature covering the final state of the message. Requires no persistent state between sessions. The inbound milter is inactive on outbound traffic and the outbound milter is inactive on inbound traffic - this is standard milter behavior already implemented and deployed. The two milter instances do not need to run on the same server. Each hop in the delivery chain signs independently with its own key. The inbound milter of hop N and the outbound milter of hop N+1 have no need to communicate - the chain of custody is established through the signed headers in the message itself.

Responsibility for Declaring Modifications A fundamental principle of DKIM2-core is that every entity that modifies a message MUST declare its modifications via DKIM2-Chain-Mod headers at the time of modification. This responsibility belongs to the entity that makes the modification, not to the signing milter. This principle has an important architectural consequence: the outbound milter does not need to reconstruct what was changed by comparing the current message with a previously cached version. It trusts that modifications have already been declared by whoever made them and signs the message as presented. This eliminates the need for stateful milter implementations with persistent shared storage in the DKIM2-core profile. Implementations that delegate modification declaration to the signing milter rather than to the modifying entity - requiring the milter to infer changes by comparing with a cached copy - are technically possible but architecturally unsound. They couple the signing infrastructure to the modification logic in ways that create operational fragility and are incompatible with the stateless deployment model described here.

Mailing List Managers Delegating to an MTA When a mailing list manager such as Mailman, mlmmj or Sympa passes messages to a local MTA for transmission, the recommended pattern is:

• The list manager modifies the message - adding List-* headers, modifying Subject, appending footer
• The list manager adds DKIM2-Chain-Mod headers declaring each modification it made
• The list manager submits the message to the local MTA, forcing the MAIL FROM to the list bounce address
• The outbound milter on the MTA constructs DKIM2-Chain-mf and DKIM2-Chain-rt from the envelope values and signs the message

List managers that cannot be modified to add DKIM2-Chain-Mod headers MAY rely on the outbound milter to detect undeclared modifications by comparing the signed headers against the incoming DKIM2 signature. However this approach requires stateful milter operation and is therefore classified as DKIM2-extended behavior. It is NOT part of the DKIM2-core profile.

Mailing List Managers with Integrated SMTP Some mailing list managers - including mlmmj and similar lightweight implementations - can open SMTP connections directly without passing through a local MTA. These implementations act as their own MTA for the purpose of message transmission and MUST implement DKIM2-core signing directly, without relying on an external milter. Such implementations MUST:

• Declare all modifications made to the message via DKIM2-Chain-Mod headers before signing
• Construct DKIM2-Chain-mf from the MAIL FROM value used in the SMTP transaction
• Construct DKIM2-Chain-rt from the RCPT TO values used in the SMTP transaction
• Sign the message with a key authorized for the signing domain

Alternatively, these implementations MAY be configured to relay through a local MTA that carries an outbound milter, delegating signing responsibility to that MTA. This is the RECOMMENDED approach for operators who wish to minimize the scope of DKIM2-core implementation.

Hop Counting and Multiple Hops Within the Same Administrative Domain When a message passes through multiple MTAs within the same administrative domain - for example, a receiving MTA that passes to a list manager that passes to a transmitting MTA - each SMTP transaction that adds a new DKIM2 signature constitutes a new hop with an incremented i= value. Operators MAY choose not to add a DKIM2 signature at intermediate hops within their own administrative domain if the intermediate hop does not modify the message and does not need to be independently attributed in the chain of custody. Transparent internal relays that add only Received: headers do not need to participate in DKIM2 signing. However, any hop that modifies the message - including a list manager - MUST be represented in the chain of custody with its own DKIM2 signature, regardless of whether that hop is within the same administrative domain as adjacent hops. A list manager's signature may be generated by the list manager itself, when it signs directly as its own MTA, or by a downstream MTA to which it delegates signing. Signing both before and after mailing list processing is supported as an optional mode. In this configuration the inbound milter verifies the previous hop and signs at i=N, the list manager adds DKIM2-Chain-Mod declarations for its modifications and the outbound milter signs at i=N+1 covering the declared modifications. This mode ensures that all outbound messages carry a DKIM2 signature regardless of the delivery path - including cases where a single submission results in both list-processed and direct-delivery copies. Operators who do not require this coverage may use the single-hop model described above.

Confirmation of Milter-Based Implementability The feasibility of implementing DKIM2-core via the milter interface without MTA core modifications has been confirmed by multiple participants in the working group discussion. Murray Kucherawy, co-chair of the DKIM working group, confirmed publicly on the working group mailing list that core MTA modifications are not necessary to add DKIM2 support via milter - consistent with the deployment model used for DKIM1, SPF, DMARC and ARC. G.W. Haywood, maintainer of Sendmail::PMilter - a Perl milter implementation supporting both Sendmail and Postfix - noted that milter protocol version 6 already provides the necessary primitives: adding, deleting and modifying headers and replacing the message body. He assessed that implementing DKIM2 via milter would not be a significant implementation effort once the specification stabilizes and expressed intent to implement DKIM2 support. John Levine subsequently confirmed on the working group list that the primary difference from existing DKIM in terms of milter implementation is access to envelope addresses - and that SMFIC_MAIL and SMFIC_RCPT callbacks already provide these in the milter protocol. He characterized the milter-based implementation of DKIM2 as a Small Matter Of Programming. G.W. Haywood concurred with this assessment. A working milter implementation of DKIM2 in Perl using Sendmail::PMilter has been published by Bron Gondwana, co-author of the DKIM2 specification, in the working group interoperability repository at https://github.com/dkim2wg/interop/. This implementation demonstrates that the milter interface provides the primitives necessary for DKIM2 implementation - including Message-Instance generation and outbound signing - without MTA core modifications. The existence of this implementation confirms the milter-based deployment model described in this document, independently of whether the full DKIM2-extended profile or only DKIM2-core is implemented. These confirmations from active MTA implementers are consistent with the DKIM2-core design principle described in this document: all mandatory functionality is expressible within the existing milter interface without requiring changes to MTA core software. An implementation of the specific deployment profile described in this document is documented in the Implementation Status section.

Content-Modifying Gateways and Topology Requirements Antivirus engines, DLP systems, encryption gateways and content filters may modify messages in transit without participating in any authentication protocol. This section describes how such components are accommodated under DKIM2-core and what deployment topology this requires. These components are not autonomous nodes on the delivery path. Each one is deployed inside the administrative domain of either the sending or the receiving operator, which has installed it deliberately for a security purpose. An operator therefore always knows which content-modifying components are present in its own path, even though a remote party cannot discover them. The problem is not detection by third parties: it is that the ADMD hosting the component must take responsibility for what the component does. Under DKIM2-core that responsibility is expressible. The modifying component itself needs no knowledge of DKIM2. What is required is that a DKIM2 signer be placed downstream of it, within the same administrative domain, so that the modification is attributed to that domain through a signature over the modified content. The signer does not describe what was changed: it states that the message left its domain in the state presented and that the domain accounts for it. This holds whether the modification was an attachment removal, a redaction, a URL rewrite or an encryption of the entire body. A hop is in one of two positions. Either it originates the message and its signature is the first in the chain, or it sends on a message it received and its signature continues a chain. In the first position there is no earlier state to reconcile and whatever the pipeline changed is part of the message as originally signed. In the second, two routes are available and no third one is. Either the component that modified the message declares what it changed through DKIM2-Chain-Mod, per Section 3.2, or the hop re-originates per Section 6.1.1: terminate the inbound chain, remove all prior DKIM2 header fields and sign as a new i=1 under the domain's own identity and envelope. What is not available is a signature that continues the chain over a state the signer has not accounted for.

Topology on the outbound path The signer is placed after the complete filtering pipeline, so that it signs whatever emerges from it. Modifications introduced by any component in the pipeline are covered by the signature of the ADMD that operates it and the envelope binding reflects the transaction as it is actually transmitted. The operator signs the output of its own gateway and thereby accepts accountability for its behavior. Where the signature is not the first in the chain, the two routes above apply to the hop exactly as they apply on the inbound path.

Topology on the inbound path On the inbound path an additional constraint applies. DKIM2 binds the MAIL FROM and RCPT TO values of the SMTP transaction to the signature, so verification requires access to the envelope of the incoming session. A component that receives a message outside that session no longer has those values available. Verification must therefore be performed by the node that accepts the external connection. Where a content-modifying gateway is the node accepting external connections, it terminates the SMTP session and the envelope is not available to any node behind it. Such a deployment cannot verify DKIM2 at all, regardless of what it does to the content. The topology that supports DKIM2-core on the inbound path is therefore:

1. an edge MTA that accepts the external SMTP connection, verifies the DKIM2 chain and the envelope binding, and records the verification result;
2. the content-modifying component, which operates on the message as an internal stage;
3. an internal DKIM2 signer, if and when the message is relayed further.

Where delivery is terminal, step 3 does not arise. Verification at the edge is the last point at which the chain is meaningful, no further signature is produced and no downstream party is affected by the modification. Where the message is relayed further, a hop whose modifications are not declarable cannot present its signature as an unqualified continuation of the chain. The two routes set out above apply. Neither requires state: nothing has to retain the message as it stood before modification and no difference has to be computed. A component that modifies a signed header field without declaring it breaks the header hash of the preceding hop and the message will fail verification downstream. Operators who currently deploy a content-modifying gateway as their externally facing MX must introduce an edge MTA ahead of it in order to participate in DKIM2. This is a change of network topology, achievable with existing software and without modification to the gateway product. It is a real deployment cost and operators should account for it.

Gateways operating as the external MX under third-party control A distinct case arises where the externally facing MX is operated by a third party on the operator's behalf, as with cloud-hosted security gateways. The operator controls no node ahead of the gateway and cannot introduce one. Verification of the incoming chain is available only to the gateway operator and if that operator does not implement DKIM2 the chain terminates there irrespective of the receiving domain's own capabilities. This profile does not resolve that case. A receiving domain in this position cannot verify DKIM2 for the affected flows and SHOULD NOT represent itself as able to do so. This is a limitation of the deployment arrangement rather than of the profile and it resolves if the gateway operator implements DKIM2-core verification at its edge, which requires no recipe generation and no state beyond the SMTP session.

What a participation declaration can assert A capability declaration mechanism has been discussed in the working group as a way to signal whether a domain participates in DKIM2. It is specified in , which was at revision 04 at the time of writing and is under active revision. A declaration of that kind names a domain, while a chain is continued or broken by nodes, so the two do not describe the same object. The operator is nonetheless in a position to make such a declaration accurate, because the topology of its own paths is known to it: which node accepts external connections, which internal relays exist, whether an alias or forwarding service is in use and whether a list manager sits in the path. The topology requirement set out above is what turns that knowledge into an accurate declaration. The one case in which the knowledge does not suffice is the one described immediately above, where the node ahead of the operator's own externally facing MX belongs to a third party. Such a declaration covers the case of a domain that does not participate. It does not cover the case described here, where a domain participates, signs correctly and has an in-path component ahead of its externally facing MX that no declaration describes. A domain in that position that declares participation makes its own situation worse: a receiver that finds the declaration and a broken chain has grounds to treat the discontinuity as deliberate rather than as an exit from DKIM2. The topology requirement above is therefore not an alternative to a declaration mechanism. It is the condition under which declaring participation is accurate. A declaration that named the position of a non-participating component within the declaring domain's own path, rather than only the domain's participation, would distinguish a discontinuity that is localized from one that is merely observable, which is a distinction none of the present mechanisms expresses. The granularity of such a declaration determines what it can truthfully assert. A declaration published for a domain asserts participation for every node that sends on that domain's behalf and in a domain of any size those nodes are not uniform: an externally facing MX, internal relays, an alias or forwarding service, a list manager and, in the case described above, a gateway operated by a third party. A domain cannot assert participation for a node it does not control and a node that forwards without modifying has no occasion to sign, which Section 3.7.5 permits. The declaration is accurate for the domain as a whole only where every one of those nodes participates. That condition matters wherever a receiver draws its conclusion from the declaration rather than from the message. Where a receiver treats the presence of a declaration for the preceding hop's domain, together with the absence of a signature from that domain, as evidence that the message was replayed, each of the cases above produces that evidence without a replay having occurred: a transparent relay that signs nothing, an internal relay that was never required to sign and a third-party MX that cannot sign. This profile draws its conclusions from the message instead. A signature that is present and does not verify is a failure of the hop that made it, while the absence of a signature is the absence of evidence and not evidence in itself.

Internationalization

Scope and Principle The mechanisms specified in this profile operate on octets, not on text. Header hashes, body hashes and signature inputs are computed over octet sequences and the comparisons that establish envelope binding are comparisons of octet sequences. This profile therefore does not define a notion of textual equivalence and no participant may introduce one. This is a deliberate design constraint rather than an omission. Any transformation that preserves the meaning of text while altering its octets, such as Unicode normalization, case folding or transcoding between character encodings, produces a different hash for input that a human reader would consider identical. Where such a transformation is applied by one participant in a chain and not by another, the two compute different hashes over the same message and the chain breaks on legitimate mail. Since the milter and MTA interfaces through which implementations receive messages do not declare a character encoding and since permits header field values and permits envelope addresses to contain UTF-8, an implementation cannot in general know whether a given octet sequence is UTF-8. Octet transparency is consequently not a hardening measure but the only behavior that can be specified coherently.

DKIM2-Chain-Mod Values The del= and new= values are delimited by DQUOTE. The value is delimited positionally, on the unfolded header field value: it begins immediately after the first DQUOTE following the tag's "=" and ends immediately before the last DQUOTE in that header field value. Because del= and new= MUST appear last in the header field, this rule yields exactly one parse. A DQUOTE octet occurring within the value MUST NOT be treated as a terminator and no unescaping is applied. Each fragment of a fragmented value is independently delimited by its own DQUOTE pair and the positional rule applies to each fragment separately. Fragments are reassembled by concatenating the delimited values in ascending fr= order, with no separator inserted. A del= or new= tag whose value does not begin with DQUOTE is malformed. Implementations MUST NOT accept an unquoted value terminated by the tag separator, because that would provide two encodings of the same logical value on a field that feeds a hash and the unquoted form cannot carry the tag separator itself. The value between the delimiters is a sequence of octets. A signing participant MUST place it in the tag exactly as the octets appeared in the header field value being declared and a verifying participant MUST use it for reconstruction exactly as the octets appear between the delimiters. Implementations MUST NOT apply any transformation to the value at either point, including Unicode normalization, case folding or transcoding between character encodings, and MUST NOT reject a DKIM2-Chain-Mod declaration on the grounds that the value is not well-formed in any particular character encoding. This prohibition concerns the value at the two points just described: where the signing participant places it in the tag and where the verifying participant extracts it for reconstruction. It does not concern the canonicalization of the DKIM2-Chain-Mod header field itself, which is applied per Section 3.3.5 by every participant alike. That canonicalization compresses runs of whitespace within the value and it does so identically when the header field being declared is hashed at hop i-1 and when the reconstructed header field is hashed at hop i+1. Because the compression is idempotent, a difference in internal whitespace, whether present from the outset or introduced in transit, is absorbed on both sides of the comparison and the reconstruction closes. Because the values are compared after relaxed canonicalization, the mechanism establishes equivalence of the declared value under that canonicalization rather than octet identity with the original header field value. A declaration that differs from the original only in internal whitespace reconstructs successfully and a modification consisting solely of a whitespace change produces no observable effect on the header hash. This is the same tradeoff that relaxed canonicalization makes for body integrity, discussed in Section 3.6. This differs deliberately from the strict-validation discipline that has proven correct for structured data formats. There, a parsed structure drives subsequent decisions and differing leniency between parsers creates exploitable differentials. No parsing of the value occurs here: the octets are delimited positionally and hashed. Transparency, not validation, is what removes the differential in this case. A header field value may contain octets that dkim2-chain-mod-value cannot carry: DEL and the C0 controls other than HTAB, which Section 4 permits only in its obsolete syntax and which conforming implementations MUST NOT generate. An implementation that modifies such a header field, and therefore has to declare it, MUST NOT sign the message, because a declaration that drops or replaces those octets asserts a value the field did not hold. A header field whose value is the empty string cannot be declared, because dkim2-chain-mod-value requires at least one octet between the delimiters and this profile treats such a field as absent for the purposes of DKIM2-Chain-Mod declarations as stated in Section 3.2.1. The two states are not equivalent under the header hash: a field present with an empty value contributes its name to the computation and an absent field contributes nothing. A modification consisting solely of the addition or the removal of an empty header field is therefore neither declarable nor reversible under this profile. This is a known limitation and not a property of the mechanism.

Envelope Addresses An SMTP transaction using the SMTPUTF8 extension may present envelope addresses containing non-ASCII octets in the local part, in the domain or in both. The addr= tag of DKIM2-Chain-mf and DKIM2-Chain-rt MUST carry the address exactly as it appeared in the corresponding SMTP command, octet for octet. An implementation MUST NOT normalize, transcode or otherwise rewrite the address when placing it in the tag, including conversion between the U-label and A-label forms of the domain. This prohibition concerns the value carried in the tag and not the comparison defined below, which converts a copy and never writes the converted form back. The base specification takes the opposite course. Its Section 18, on the internationalized email framework of , requires that domain values from MAIL FROM and RCPT TO be mapped from U-labels to A-labels before being recorded, while local parts are recorded unchanged on the ground that the base64 encoding of the value raises no difficulty. The same encoding carries the domain, so the reason given for the local part applies to the domain as well. Recording a converted form means the signature no longer attests the address as it was presented in the transaction. It does not remove the need for conversion at the verifier either, which must still map a U-label received in the live envelope before comparing it. This profile therefore records the address as presented and converts only for the comparison, which places the conversion where it is unavoidable and nowhere else. Unlike DKIM2-Chain-Mod values, envelope addresses are compared and not merely transported, so transparency alone does not determine the outcome. Comparison proceeds in two stages:

1. The two addresses are compared as octet sequences, with the local parts compared case-sensitively as required by Section 2.4 and the domains compared case-insensitively over the ASCII range only. If they match, the comparison succeeds.
2. If they do not match and either domain contains octets outside the ASCII range, the two domains are converted to their A-label forms per and compared again, case-insensitively. If they match, the comparison succeeds.

Implementations MUST implement the second stage. Where the conversion of a domain to its A-label form fails because the domain is not a valid internationalized domain name, the message is malformed and the result is a permerror. Where both conversions succeed and the A-labels differ, the comparison has failed and the result is a fail. No other outcome is defined and in particular an implementation MUST NOT report a distinct result for its own inability to perform the conversion: the capability is required and a verification result describes the message rather than the verifier. Stage 1 alone resolves every comparison in which both addresses are ASCII, which is the case for the overwhelming majority of current traffic. Stage 2 is reached only when the octet comparison has already failed and non-ASCII octets are present, so the cost of internationalized domain name support falls only on deployments that actually encounter it.

Header Field Names Header field names are not internationalized. extends the unstructured production of , and therefore the values of header fields, but leaves field-name unchanged. Field names consequently remain restricted to printable ASCII and comparisons of field names are ASCII case-insensitive comparisons. The header-field-name production of this profile is nevertheless narrower than permits. Field names containing an underscore or other printable ASCII characters occur in deployed infrastructure, frequently in header fields added by filtering and scanning components and the component that modifies such a header field is often not the one that created it. A component that modifies it has no means of declaring the modification under the narrower production, which would prevent rollback of a legitimate and declarable change. The production is therefore the one of Section 3.6.8 unchanged. The semicolon that separates tags within the DKIM2-Chain-Mod header field is distinguished positionally, as the del= and new= values are: the value of the field tag runs to the first semicolon followed by SP, a tag name and an equals sign, or to the end of the header field value. A field name cannot contain a space, so no other reading is available, and the trailing semicolon that the syntax of Section 3.1.7 accepts on input is not recognised after the field tag. Any field name that permits can therefore be declared.

Domain Comparison Wherever this profile requires comparison of domain names, whether between the d= tag and an envelope domain, between envelope domains at successive hops or against configured local domains, the comparison follows the two stages of Section 3.8.3 applied to the domain alone: an ASCII case-insensitive comparison first and, where that fails and octets outside the ASCII range are present, a comparison of the A-label forms defined by IDNA2008 . The d= tag is restricted to ASCII by the domain-name production of Section 3.3.1, so a signing domain is always in that form already and the lookup of its key record requires no conversion: only an envelope domain can reach a comparison as a U-label. Implementations MUST NOT apply locale-dependent case mapping to octets outside the ASCII range for this purpose. A case mapping drawn from the runtime locale may fold or classify continuation octets of a UTF-8 sequence, which both corrupts the comparison and, where the same primitives are used in canonicalization, produces a hash over octets that differ from those received.

DKIM2-extended: Optional Profile

Overview and Scope DKIM2-extended is a superset of DKIM2-core. A node that implements DKIM2-extended implements all of DKIM2-core plus the body recipe mechanism described in this section. DKIM2-extended is not a separate protocol - it is an additional layer of functionality built on top of the mandatory core profile. The body recipe mechanism allows intermediaries to describe modifications made to the message body in sufficient detail to allow reconstruction of previous versions. This capability has forensic value for operators who need to investigate message handling after the fact, audit modification chains or satisfy compliance requirements that mandate retention of original message content. Body recipes cannot provide guidance as to whether content is safe - safety determination remains in the domain of content scanning and reputation systems. The operational value of reconstruction data depends on the receiver's capacity to process it at scale, which varies enormously across the ecosystem. However, the body recipe mechanism is not required for the primary operational objectives identified in the DKIM working group charter: replay prevention, backscatter mitigation and modification attribution. These objectives are fully satisfied by DKIM2-core. The working group charter states that "the working group will prefer a result that is incremental to the deployed ecosystem" and that "proposed solutions are expected to be robust in terms of interoperability and scalability." DKIM2-extended should be evaluated against these criteria by operators considering deployment. Operators who do not require forensic body reconstruction SHOULD implement DKIM2-core only. Operators who require body accountability for compliance or forensic purposes MAY implement DKIM2-extended, subject to the operational considerations described in this section. A note on enforcement models: the deployment of DKIM2-extended cannot rely on the policy decisions of individual large providers as an enforcement mechanism. states that the IETF works for the benefit of the Internet as a whole, not for the interests of particular entities. A protocol whose correct operation depends on major receivers choosing to penalise non-conformant implementations introduces a dependency that is outside the scope of the protocol specification and that structurally disadvantages operators who lack leverage with those receivers. DKIM2-core provides verifiable security properties through cryptographic mechanisms alone, independent of any provider's enforcement decisions. This ensures that small operators, universities, regional ISPs and non-commercial organisations can participate on equal terms.

Body Recipes and Message-Instance Headers The body recipe mechanism is described in detail in . This section summarizes the mechanism and identifies operational considerations relevant to deployment decisions. A Message-Instance header is added by each hop that modifies the message body. It contains a JSON-encoded recipe - a structured description of the modifications made - encoded in base64. The recipe provides sufficient information for a verifier to reconstruct the previous version of the message body from the current version by applying the recipe in reverse. A null recipe declares that a modification was made but that the previous state cannot or should not be reconstructed. Null recipes are discussed further in Section 4.6. An alternative approach stores the previous body in the MIME preamble or epilogue area rather than as literal data in the recipe, leaving the recipe a copy range into the message as transmitted. The base specification does not define it: the words "preamble" and "epilogue" do not appear in , whose Section 2.3 states only that a Forwarder may alter the message content and that a record will be made of the changes. One implementation does it. The production Perl code in the working group interoperability repository places the previous body in the epilogue when a diff exceeds its configured limit on literal lines, and where the message is not multipart it converts the content into a multipart/mixed message in order to create the area it needs. The first limitation identified in working group discussion is therefore not removed by implementation but made concrete: a substantial fraction of modern email, particularly bulk and transactional mail, is single-part HTML with no MIME boundaries, so the area does not exist and has to be manufactured. The mechanism whose purpose is to record what was done to a message alters the structure of the message in order to have somewhere to put the record. The second limitation is unchanged: the use of these areas for signed content has not been tested and their behaviour across the heterogeneous ecosystem of MTA and filtering software is unknown. A third storage option - encoding the recipe as a MIME attachment on the message - has also been considered. This avoids the header-size and MIME-availability constraints of the other two approaches, but makes the recipe visible to the end user: mail clients render attachments in the message view and an opaque base64-encoded JSON blob attached to ordinary correspondence is both confusing to end users and inconsistent with normal mail presentation. Archiving and mail-storage systems would also retain and index this content as a distinct MIME part, compounding the privacy considerations discussed in Section 4.8. Furthermore, proposals to store original message content in the MIME epilogue and reference it via non-monotone copy instructions would require recipe processors to access arbitrary positions in the message rather than reading it sequentially. Working group discussion has confirmed that non-monotone recipes make streaming recipe processing with bounded memory impossible, as the processor must buffer the complete message before applying any recipe step. This eliminates the streaming processing model that DKIM1 and DKIM2-core support natively. The implementation described above avoids non-monotone access by a different means and pays for it in the same coin. Placing the whole previous body in one contiguous region at the end of the message makes the recipe a single ascending copy range, so the access pattern is monotone. What a processor then needs in order to emit the first line of the reconstructed body lies at the end of the message it is reading, so bounded-memory streaming is lost in any case. The two arrangements fail for different reasons and neither streams. Body recipe generation requires the signing component to access both the pre-modification and post-modification states of the message, which necessitates complete message buffering at the signing hop. This is distinct from recipe application, which can be performed sequentially for monotone recipes. The streaming constraint identified by the working group as fundamental applies to both signing and verification; body recipe generation violates it at the signing stage. The three architectural options for recipe transport each present fundamental limitations that cannot be resolved simultaneously. Storing recipes in message headers is subject to MTA header size limits that make the mechanism unusable for any recipe containing removed content of significant size, as documented in Section 4.4.1. Storing recipes as MIME attachments makes them visible to end users as message attachments, which is operationally unacceptable and raises additional privacy concerns. Storing recipes in the MIME preamble or epilogue requires non-monotone access patterns that make streaming processing impossible. No transport option exists that is simultaneously compatible with production MTA infrastructure, invisible to end users and streamable with bounded memory. Furthermore, any header-based recipe transport implicitly requires coordinated reconfiguration of header size limits across every MTA in the transit path - including nodes that do not implement DKIM2-extended - to prevent silent truncation. This represents a hidden dependency on ecosystem-wide MTA updates that contradicts the incremental deployment model that DKIM2 is intended to support. A further property of the preamble and epilogue option is that a conforming client does not show the user what is placed there, and that is a difficulty rather than a reassurance. Section 5.1.1 states that these areas "should generally be left blank, and implementations must ignore anything that appears before the first boundary delimiter line or after the last one", and the note that follows gives the reason they are generally not used: "the lack of proper typing of these parts and the lack of clear semantics for handling these areas at gateways". The previous body is therefore placed in the one region of a message whose handling by intermediaries the MIME specification declines to define, by a protocol whose subject is what intermediaries do to messages. The content is not displayed, not labelled and not announced, yet it is present in the delivered message, where a source view shows it, a mail store indexes it and a client that does not follow the rule may render it. Where the modification being described was a redaction or the removal of an attachment, what travels in the epilogue is the material the modification existed to remove.

Verification Depth Is Not Specified The base specification prescribes the depth of verification without requiring it. Its Section 14.4 states that the Verifier needs to check the Chain of Custody from start to finish and its Section 14.6 requires that, where more than one signature is present, all of them be checked where the Verifier is able to do so. Neither statement is accompanied by a requirement that the chain be traversed, and its Section 13.2 defines an acceptance path that does not traverse it: a receiver MAY make an initial assessment on Provisional Verification, which examines the highest numbered DKIM2-Signature and Message-Instance header fields alone, checking that their m= values agree, that the signatures and the hashes there pass and that the MAIL FROM and RCPT TO are consistent with the mf= and rt= of that signature, and may accept the message on that basis. That path exists because the full procedure is expensive, and what makes it expensive is reconstruction rather than the chain of custody: establishing every intermediate state means applying the recipes of every hop. Revision 08 states what may follow such an acceptance and its reasoning holds: where the receiver later determines that the message is not a Fully Verified DKIM2 Message it MAY generate a Delivery Status Notification, which cannot become backscatter because the shallow check has already verified the envelope against a system that took part in the delivery. The cost is not in the notification. It is that acceptance was decided on one hop while the specification describes the verification of all of them. Nor is the composition of reconstruction and validation required. Section 14 of the base specification states that a Verifier determining a particular DKIM2-Signature must reconstruct the state of the message as it stood when that header field was added, which governs how a signature is evaluated once a Verifier has chosen to evaluate it. Section 14.7 of that document describes how a hash value is validated. Neither requires that a Verifier reporting a result have validated each reconstruction against the hashes of the Message-Instance it reconstructs. Section 13.4 of that document states that where only the first form of the message is of interest, all the recipes can be applied in turn and only one hash value checked, the correctness of the intermediate hash values being not relevant to that assessment. That is a sound end-to-end check of the original content. What it does not establish is which hop made which change: a hop that declares an intermediate state it did not hold, compensated by the recipe of the hop after it, yields the same final reconstruction. Working group discussion accepted that localising a failure requires hop-by-hop verification as a fallback where the end-to-end check does not pass. That fallback is triggered by failure, so it does not reach the case where the end-to-end check passes over intermediate states that were misdeclared. Confirming the original is not the same as attributing the modifications and only the second is what the chain of custody exists to provide. Revision 08 adds a prohibition that rests on the same uncomputed property. Its Section 13.1 states that whether a message being a Fully Verified DKIM2 Message makes any difference to acceptance is entirely a matter for local policy. The same section states that a message carrying DKIM2 header fields which is not a Fully Verified DKIM2 Message MUST NOT be sent to another system without a local arrangement. The antecedent of that prohibition is established only by the full determination, which the same section leaves optional for acceptance and which its Section 13.2 permits a receiver to replace with an assessment of the likelihood that the property holds, made on the highest numbered signature and Message-Instance alone. A hop that accepts on that assessment and forwards has no basis on which to know whether it is within the prohibition or outside it. The consequence is that two conformant implementations can guarantee different properties. Both conform: one reconstructs the whole chain and validates every intermediate state while the other accepts on Provisional Verification and stops. The two messages are delivered on different evidence and nothing distinguishes them afterwards, because the base specification defines no field in which a receiver records the depth it reached. Mechanisms built on top of verification inherit this. The base specification requires in its Section 11 that the From: header field be Authentic, and it locates the comparison at i=1 where the field has not been altered and at the signature following the Recipe that replaced it where it has. Establishing the property therefore requires walking the chain to that hop, and in the second case it requires reading the header Recipes to find which hop replaced the field. A verifier that stops at the most recent signature cannot do either. A verifier that implements the core mechanisms without Recipes cannot do the second at all. Both report the same result as a verifier that did. A mandatory core profile addresses this directly. DKIM2-core defines a fixed verification procedure whose cost does not depend on chain length: envelope binding against the current transaction, the continuity check of Section 3.3.8 and, where hh= is present, the single-step rollback of Section 3.3.7. Every conformant node performs the same checks, so a result carries the same meaning wherever it is produced. Reconstruction of earlier message states remains available in DKIM2-extended for operators who require it, as an addition to a defined floor rather than as a substitute for one.

Computational and Traffic Overhead Operators considering DKIM2-extended deployment should be aware of the following overhead costs. This analysis assumes the header-based Message-Instance mechanism as currently specified in , which places the recipe in the message header and defines no alternative. JSON parsing in the delivery critical path - Message-Instance headers contain base64-encoded JSON that must be decoded and parsed at every verifying hop. JSON parsing introduces a dependency on a JSON library in the MTA or milter critical path. While JSON libraries are available in all languages, their presence in the delivery path introduces attack surface that does not exist in DKIM1 or DKIM2-core. Section 4.5 addresses the security implications. Traffic overhead - every message that transits DKIM2-extended-aware nodes accumulates Message-Instance headers with base64-encoded JSON recipes, additional DKIM2-Signature headers and potentially substantial body recipe content. These headers travel in the message to all recipients, including those on servers that do not implement DKIM2 at all. The overhead is not optional - it is imposed on the entire ecosystem by nodes that implement DKIM2-extended, regardless of whether downstream infrastructure can use it. Stateful milter requirement - unlike DKIM2-core, which is stateless by design, DKIM2-extended requires the signing milter to have access to the message state before and after modifications in order to calculate body recipes. This requires either a stateful milter implementation with persistent shared storage, accessible to both the inbound and outbound milter instances, or MTA core modifications that provide equivalent capability. This is a significant architectural difference from DKIM2-core and from all previous email authentication protocols. The reference implementation has since taken the first of those two routes. A plan published in the working group interoperability repository on 14 October 2026 gives chain of custody to an unpatched Mailman 3 by placing one milter at ingress and one at egress: the inbound milter stores the message as it arrived in a snapshot directory shared with the outbound milter, keyed by a token it writes into the message, and the outbound milter retrieves that snapshot and diffs the modified message against it. The configuration option is named for what it is, a snapshot directory shared between the verifying handler and the signing handler. The shared state is required by recipe generation alone: signing and verification remain stateless in that implementation as they are in this profile. The arrangement also requires routing only the chosen traffic through the two milters, with per-recipient and per-sender rules in the MTA, and a change to the list manager own listening port.

Recipe Size Limits and Computational Overhead The JSON recipe format introduces complexity dimensions that must be explicitly bounded to prevent denial of service attacks. Unlike DKIM1 and ARC whose computational cost is bounded and predictable, DKIM2-extended recipe processing has a cost that depends on recipe complexity - a parameter controlled by the sender or any intermediary in the delivery chain. Verification of a complete recipe chain has complexity O(n*m) where n is the number of hops with recipes and m is the maximum size of any version of the message. Both n and m grow with message complexity and delivery path length. DKIM2-core verification is O(1) per hop regardless of chain length or message size. The following limits MUST be enforced by all DKIM2-extended implementations: Maximum recipe object count Implementations SHOULD enforce a maximum limit on the number of top-level objects in a recipe. During the development of this specification, a limit of 50 top-level objects was proposed as a DoS mitigation measure. This value has not been formally validated and implementations MAY choose a different limit based on their operational experience. The need for any such limit is itself evidence of the attack surface introduced by the recipe mechanism. Maximum nesting depth The current specification does not define a maximum JSON nesting depth. Implementations SHOULD enforce a maximum nesting depth of 8 levels. This is sufficient for any legitimate MIME structure - real-world messages rarely exceed 4-5 levels of MIME nesting - while preventing attacks that use artificially deep nesting to exhaust parser stack space or trigger pathological behavior in JSON libraries. Maximum recipe size in bytes Implementations SHOULD enforce a maximum size for individual recipes and for the total accumulated Message-Instance header content in a message. Until normative limits are defined in , implementations SHOULD enforce a maximum individual recipe size of 16KB and a maximum total Message-Instance header size of 32KB. These values are conservative estimates consistent with the header size limits enforced by production MTA software on default configurations. The recipe format uses copy-range instructions for unmodified content and literal data instructions for content that has been removed or replaced. For the common case of footer addition, copy-range instructions are compact. However, when an intermediary removes content - including attachments stripped by antivirus gateways, cloud security gateways performing DLP inspection or mailing list managers applying size or content-type policies - the removed content must be represented as literal data in the recipe. A removed attachment of n bytes produces a recipe of approximately n bytes, which then travels as a base64-encoded JSON structure in the Message-Instance header to all downstream recipients. This is the inverse of the intended purpose of attachment removal. When a removed attachment is represented as literal data in a recipe, the resulting Message-Instance header may reach sizes comparable to the removed content itself. Production MTA header size limits MTA implementations and milters that enforce header size limits - as most production systems do for operational reasons - may truncate or reject Message-Instance headers that exceed those limits, silently corrupting the recipe chain for all downstream verifiers. Postfix enforces a default header_size_limit of 102400 bytes per individual header; Sendmail enforces a default MaxHeadersLength of 32768 bytes for the total header block. A recipe containing a removed attachment of even modest size may exceed these limits on default-configured systems. The recipe size limits discussed in this section are therefore not merely a denial-of-service mitigation but a practical necessity imposed by the constraints of existing MTA infrastructure. However, any size limit that is low enough to be operationally safe is also low enough to exclude legitimate use cases involving common attachment removals and any limit high enough to accommodate those cases creates unacceptable memory pressure on constrained systems. Maximum header line count Operators with MTA configurations that enforce limits on header count or total header size MUST be aware that accumulated Message-Instance headers across multiple hops can exceed these limits, causing silent truncation that will break recipe chain verification downstream. The one concrete data point currently available is from an implementation demonstrated during the development of this specification: a message of six lines of plain text with a footer added produces a compact recipe. However, messages containing base64-encoded attachments require recipe content that describes base64 line-width re-alignment, which can produce Message-Instance headers substantially larger than the modified content itself. At the time of writing, no quantitative analysis of overhead across representative message types has been produced. Operators should evaluate this overhead against their specific traffic profiles before committing to DKIM2-extended deployment. The absence of a viable solution for attachment removal was confirmed during working group discussion at the April 2026 interim meeting . The base specification authors proposed per-MIME-part hashing as a potential mechanism to allow cryptographic elision of removed attachments without null recipes. This approach was subsequently described by the lead author of the base specification as "super expensive" and "not worth the candle" - an acknowledgment that the body recipe mechanism as currently defined does not cover a fundamental use case and that the proposed alternative is operationally impractical. At the same meeting, Allen Robinson of Google confirmed that Google Workspace performs attachment removal actively in production - directly contradicting the characterization of this scenario as rare or legacy. It is worth noting that all four limits defined above are operationally motivated values derived from implementation experience rather than from principled bounds inherent in the protocol design. DKIM1 and ARC require no equivalent limits because their tag-value structure has bounded complexity by design: a tag-value list of N items has exactly N items, no recursive structures and no parser state beyond the current position in the list. The fact that DKIM2-extended requires explicit limits to prevent denial of service attacks is evidence that the recipe format introduces complexity that cannot be bounded by the protocol design itself. This is a qualitative difference from all previous email authentication protocols and should be evaluated as such by operators and implementers. These limits are stated as recommendations because the mechanism they bound is defined in , which specifies none. Normative limits on recipe object count, nesting depth and total size belong in that document: without them each implementation chooses its own and a recipe accepted by one verifier is rejected by another. The values given here are operationally motivated defaults, not principled bounds, and are offered as a starting point for such a definition. The implementations have since adopted a bound of their own. A design document in the working group interoperability repository, dated 9 October 2026, records that every body recipe generator then in existence had unbounded worst-case cost: two production generators and two test generators were quadratic or worse, one of them measured at 3.7 seconds for 4000 lines on an adversarial input, and the remaining one was linear at the price of emitting one literal line for every line of the body. The remedy adopted is a cap of 1000 literal lines per recipe together with a work budget of four million units, both configurable. This is a bound on the code that computes the recipe and not on the protocol. The base specification sets none: its Section 20 states that it "places no limits on the complexity of Recipes. Even if limits were set, malicious messages could ignore them". The point at which a body stops being recoverable is therefore set by each implementation configuration rather than by the mechanism. Beyond CPU cycles, the requirement to reassemble Base64-encoded JSON buffers fragmented across folded header lines - folding splits a single logical header value into multiple physical lines joined by CRLF plus whitespace - forces MTAs to move from a zero-copy or stream-oriented header processing model to a buffered model, significantly increasing the per-connection memory footprint and the pressure on memory allocation subsystems at scale. DKIM1, ARC and DKIM2-core tag-value headers can be processed in a streaming fashion with constant memory per header - each tag is read, processed and discarded. DKIM2-extended recipe processing requires accumulating the complete recipe content before any verification can begin. At tens of thousands of transactions per second, even a modest increase in per-message processing time - one millisecond of additional JSON parsing - translates to hundreds of core-seconds per second of additional load. On a server processing 50,000 messages per second, one additional millisecond per message requires 50 additional CPU cores dedicated exclusively to recipe processing. Containerized architectures support horizontal scaling to absorb this load, but scaling has latency. An attacker who sends a burst of messages with complex recipes can saturate the processing pool before the autoscaler responds. Operators running on-premise infrastructure without horizontal scaling - including universities, regional ISPs and small businesses, precisely the operators for whom milter-based deployment is most important - have no autoscaling fallback. The fundamental issue is that DKIM2-extended introduces a protocol component whose computational cost is controlled by potentially adversarial input - the recipe content - rather than being bounded by the protocol design itself. DKIM1 and ARC do not have this property.

Base64 Re-encoding and Recipe Complexity Working group discussion has identified the need for additional recipe types beyond the initial design, including base64-decode-and-copy operations to handle transfer encoding changes. Each additional recipe type increases parser complexity and attack surface. This pattern of complexity growth under contact with real-world deployment scenarios is consistent with the general concern raised in this section about unbounded complexity. Base64 re-encoding with different line widths changes the body hash under both simple and relaxed canonicalization equally. Relaxed canonicalization per Section 3.4.2 addresses trailing whitespace and internal whitespace compression but does not affect the CRLF line separators that determine base64 line boundaries. Re-wrapping base64 content at a different line width inserts CRLF sequences at different positions, producing a different hash regardless of canonicalization algorithm. The complexity of base64 re-wrapping in recipe generation has been acknowledged by the authors of the base specification. Maintaining synchronization between original and modified base64 line boundaries requires tracking both representations simultaneously and fails when the original line boundary information is unavailable due to prior intermediary processing. In practice, such cases are expected to produce null recipes.

Non-UTF-8 Content and Recipe Literals JSON strings are sequences of Unicode characters, not octets. A message body transferred as 8bit in a legacy character set such as ISO-8859-1 contains octet sequences that cannot be represented in a conformant JSON string, so a body recipe that must emit such a line as literal data cannot be generated at all. This was raised in the working group in January 2026 and remained open when it was raised again in September, at which point the authors of the base specification acknowledged it. Two remedies were considered. The first is to restrict 8BITMIME handling to content that is UTF-8 or a subset of it, which excludes message populations that are not in decline. The second is to carry lines containing non-representable octets as base64 under a separate recipe label, which the authors described as producing a doubly encoded value and as not elegant. Either way the escaping problem that structure was introduced to avoid returns within the structure itself and for body content it returns in full: the base specification records envelope addresses as base64 inside tag-value fields for the same reason. The second remedy has since been adopted. It adds a third recipe step type alongside copy and emit-data, and an implementer of the base specification stated its cost directly: the content is base64 encoded twice, once within the JSON strings of the new step and once again in the serialization of the whole recipe. Detecting which of the two forms applies is not expensive: deciding whether a byte string is valid UTF-8 is a small deterministic automaton, whose states remain in single figures even when overlong encodings, surrogate code points and out-of-range sequences are rejected, as a strict validator must reject them. The cost is not in the detection. The recipe format acquires two ways to express the same line, the generator chooses between them per line and every implementation must handle the second form even though its application is expected to be rare. A code path that is mandatory to implement and rarely exercised in production is the one most likely to be wrong when it is finally reached. Where an implementation carries literal data in recipes, encoding every literal uniformly rather than only those lines that require it removes a decision that must otherwise be taken per line, removes the need to detect representability before generating a recipe and removes the second representation of the same content. Uniform encoding is not free. It expands every literal by a third, including the literals that would have needed no encoding at all, where the conditional form expands only the lines that require it. The choice is therefore between a constant cost in bytes and a conditional cost in implementation complexity. The first falls only on messages that carry literal data while the second falls on every implementation that might one day receive one. A generator that omits that detection step does not fail visibly and the divergence is reported from deployment rather than hypothesized: an implementer of the base specification stated that the JSON library in use can emit non-UTF-8 inside JSON strings, that other parsers reject what it emits and that separate utilities are therefore required to check validity before the recipe leaves the generator. Where a generator instead substitutes a replacement character, it produces a recipe that reconstructs a body the signer never held and the failure appears downstream as a hash mismatch indistinguishable from tampering. The advice that a verifier should treat the body as an undifferentiated sequence of octets is not what implementation requires: an implementer reported needing line semantics for copy steps and checks for stray CR and LF both in the body and inside emitted literals. Each of those checks is a point at which two verifiers can diverge on the same recipe.

Security Considerations for Body Recipes The body recipe mechanism introduces security considerations beyond those of DKIM2-core. Three categories of concern are relevant to deployment decisions: JSON parsing attack surface - recipe processing introduces a JSON parser in the delivery critical path that processes untrusted external input. This creates attack surface that does not exist in DKIM2-core or DKIM1. The need for explicit resource limits, discussed in Section 4.4.1, is evidence that this attack surface is real. Recipe chain integrity - a malicious intermediary can construct a recipe that presents a clean original message to verifiers while delivering modified content to recipients. This attack is feasible for any compromised node in the chain. Recipe stripping - operators may strip recipe content for operational or compliance reasons, removing information that downstream verifiers depend on. These concerns are addressed in detail with normative requirements in Section 8.3.

The Null Recipe and Its Implications A null recipe declares that a modification was made to the message body but that the previous state cannot be reconstructed. Null recipes are the correct response for several categories of intermediary that are common in real-world deployment:

• Security gateways that rewrite URLs - the original URLs may be sensitive and should not be reconstructed
• Antivirus gateways that remove malicious attachments - the removed content should not be preserved or transmitted
• DLP systems that redact sensitive content - reconstruction would defeat the purpose of the redaction
• Legacy MTAs that perform 7bit/8bit conversion - the conversion may not be perfectly reversible
• Mailing list managers that strip attachments or filter content - Mailman supports configurable MIME type removal natively via its filter_content and filter_mime_types parameters, accessible to any list administrator without server-level configuration. Sympa supports attachment removal through custom delivery scenarios. Both represent active deployment options, not legacy configurations. A common operational variant replaces removed attachments with a URL pointing to a shared repository, preserving message flow while eliminating large or problematic content. The suggestion that lists simply reject messages containing attachments rather than stripping them does not reflect common operational practice - rejection is one option among several and stripping is frequently preferred to preserve the communication value of the message body. This is a currently deployed scenario, not a legacy or transitional case.
• Any intermediary that makes modifications it cannot or should not describe in a recipe

These categories collectively represent a substantial fraction of real-world email infrastructure. When any of these nodes is present in the delivery chain, the result is a null recipe at that hop - which provides no additional body accountability beyond the bh= change already available in DKIM2-core. If null recipes are acceptable at the nodes most likely to make substantial body modifications, the incremental benefit of DKIM2-extended over DKIM2-core for body accountability is limited to the cases where all intermediaries cooperate fully - which is the minority of real-world delivery paths. This is the deployment wall for DKIM2-extended: the obstacle is not only at the MTA level but throughout the entire content filtering pipeline. MIMEDefang - a widely deployed Perl-based milter framework for Sendmail used to strip viruses, remove HTML parts, redact content and replace attachments with URLs - exemplifies this class. Under DKIM2-extended, every MIMEDefang filter function that modifies message content would be required to generate a body recipe JSON structure declaring what it changed. A framework designed to make content filtering accessible to mail administrators would need to produce cryptographic diff structures for every modification. The same applies to Amavis, ClamAV integrations and Rspamd content rewriting rules. None of these tools know what a body recipe is and none of them can produce one for the modifications that are their primary function. An entire class of legitimate and widely deployed intermediaries - antivirus engines, DLP systems, encryption gateways, content filters - exists precisely to apply irreversible modifications: remove the malware, redact the sensitive data, encrypt the content. Asking them for a reconstructive recipe is asking them to negate their own function. For antivirus and DLP systems the null recipe is at least technically available, even if it provides no accountability beyond what DKIM2-core already offers via the changed bh= value attributed to the modifying hop. For encryption gateways the incompatibility is structural: a content-bearing recipe would expose the pre-encryption plaintext, defeating the purpose of the gateway, while a null recipe leaves DKIM2-extended with no reconstruction to offer at all. The reconstruction model has nothing to attribute the message to beyond the fact that some transformation occurred. Working group discussion of this scenario surfaced no path that preserves the reconstruction model: the only arrangement compatible with the recipe mechanism specified in is to tunnel the entire DKIM2-signed message as an encrypted MIME container, with the recipient unwrapping and verifying the inner chain after decryption - an approach that requires active support on the recipient side, moves verification from the server to the client and cannot be deployed unilaterally by the gateway. Under DKIM2-core the same gateway raises no special case. It is a Reviser like any other: it declares its modification via DKIM2-Chain-Mod, signs and presents a changed bh= under a certain signing-domain identity. The recipient learns which domain encrypted the message and that it did so - which is what routing accountability requires - without any dependency on reconstructing the pre-encryption body. The recipient's ability to authenticate the original sender is not carried by a recipe in either model; it is carried by the surviving signed attribution in the chain. The alternative - null recipes at every hop - concedes the accountability property that DKIM2-extended exists to provide. DKIM2-core requires none of these tools to change: the signer milter downstream of the entire filter pipeline signs whatever emerges from it. The systematic use of null recipes by security gateways is not a theoretical concern - it has been confirmed empirically by a major gateway vendor participating in this working group. Philip Guenther of Proofpoint, whose products perform substantial alteration of message headers and bodies under customer security policies, has stated explicitly on the working group list that reversibility of those changes is "the opposite of a goal" for their customers and that their products will use the null recipe mechanism "when necessary" - and will not follow the specification at all if null recipes are not available as an option. This confirmation from a major in-path gateway vendor illustrates the structural limitation of the body recipe mechanism: the nodes most likely to make substantial body modifications - security gateways, DLP systems, antivirus engines - are by design and by customer requirement the nodes that will systematically produce null recipes. The forensic value of body reconstruction is therefore unavailable precisely at the hops where attribution would matter most. The answer the mechanism gives to the cases listed above, an attachment an antivirus removes or content a DLP system redacts, is now written into the implementations. A design document in the working group interoperability repository, dated 9 October 2026, caps a body recipe at 1000 literal lines and the diff that produces it at four million units of work, and states what happens beyond the cap: a caller able to rewrite the body stores the previous body in the MIME epilogue, and every other caller emits a null body recipe with the body marked unrecoverable. The callers in the second group include header-only signers, the default path of the production Perl implementation and the egress path of a mailing list manager. A removed attachment becomes literal lines, one for each line it occupied, and at the customary 76 characters a thousand base64 lines carry some 57000 octets, so an attachment larger than roughly 56 kilobytes exceeds the default cap on its own. For the modifications this section is about the cap is therefore the ordinary case rather than the exception, and the null recipe is not only what a gateway chooses but what the diff produces when it is asked to describe a real one. The same plan shows what it takes to keep the most ordinary modification in email out of the null case. Its analysis of the list manager records that the inline path, the one that appends a footer to a single-part text message, works by "decoding and re-encoding the body, often to base64", and draws the consequence: "The inline path rewrites the whole body, so a body Recipe becomes a null Recipe." The remedy adopted is to pre-empt it. The inbound milter converts every single-part post into a one-part multipart/mixed message before the list manager sees it, so that the footer is added as a separate MIME part and the original part survives byte for byte. That conversion is itself a modification and is recorded as a Message-Instance of its own, so a hop is inserted into the chain whose only purpose is to keep the next hop modification describable. Where the arrangement does not work the plan states the outcome plainly: the message is left unwrapped and "its footer will be inline and its Recipe may be null". A separate limitation applies even when reconstruction is technically available. Body recipes, as specified in , reconstruct canonical content, not byte-exact content: reconstruction can differ from the original in the number of trailing empty lines and in the presence or absence of a final CRLF, a difference that is invisible to DKIM2 verification but material to other signature schemes. Re-verifying an end-to-end signature such as S/MIME or PGP against reconstructed content would require the external scheme to use a canonicalization that tolerates exactly this difference - a condition that does not hold for all deployed implementations of those schemes. Beyond this technical constraint lies a practical one: an intermediary that breaks an end-to-end signature is one that modifies the body without regard for it. Producing a recipe that enables reliable reconstruction requires the exact opposite disposition - rigorous tracking of MIME boundaries, transfer-encoding and line-width handling. These two behaviors rarely coexist in the same node. The intermediaries careful enough to produce reversible recipes are largely those that would not have broken the external signature in the first place. The forensic use case attributed to body recipes therefore cannot be relied upon for the re-verification of end-to-end signatures, even in the subset of deployments where null recipes are not used. This is not merely a question of adoption incentives. Allen Robinson of Google, addressing the security properties of body recipes on the working group list, noted that body hash verification is designed to require no trust in intermediaries, since each signature can be checked by reversing all later recipes back to the original content. He stated explicitly that null recipes break this property and "reintroduce the concept of trust to DKIM2," citing this as a reason not to support them. The mechanism therefore admits no resolution: disallowing null recipes is inconsistent with the operational requirements of major security gateway vendors, while allowing them concedes the trust-minimization property that is the stated rationale for body recipes in the first place. Working group discussion in September 2026 settled the character of the mechanism. A co-author of the base specification described the null recipe as a switch from an evidence-based model to a trust-based one. Another participant held that it is acceptable where trust is pre-established between the parties and that it otherwise implies substantially lower trust than a hop that describes its changes. Asked how a receiver is expected to establish that authorization in practice, a further participant answered that the signer is explicitly configured, generally because a business relationship exists with the system performing inbound filtering and that there is no plausible way to establish it without manual verification that the system altering the mail is trusted. This is a coherent design and it is the design of ARC. A mechanism whose correctness depends on bilateral arrangement between each pair of nodes does not extend beyond the relationships that already exist. It works where the modifying gateway sits at the edge of the receiving domain, which is also the case where no downstream party is affected by the modification. For any hop earlier in the path the receiver has no basis on which to authorize the declaration and the reconstruction model provides none. Trust re-enters the model at five distinct points. The base specification states in its Section 13 that a message carrying a null Recipe is not a Fully Verified DKIM2 Message and that whether it is nevertheless acceptable, for example because a contractual relationship is in place, is a matter for local policy. The declaration itself substitutes an assertion for the evidence the mechanism was built to supply. Where verification is deferred rather than performed in line, the practical substitute is reputation: a judgement about who handled the message rather than a check of what was done to it. The question of which declared modifications a receiver should accept has the same shape: the answer offered in discussion was a judgement about the party that made them, with a rewritten link described as probably acceptable when it points at a well-known security vendor and with the accompanying observation that such a heuristic could not be written into the specification. And a message transmitted with an nd= tag in its highest numbered signature must be judged acceptable on out-of-band information, since its envelope cannot be validated at all. None of these is an implementation shortcut. Each is specified or was described as intended behaviour and each is a case in which the receiver decides on the basis of who rather than what. The positions documented in this section define a logical closure. Null recipes are necessary in practice: a major security-gateway operator has stated that reversibility is the opposite of a design goal and that its implementation will either use null recipes or not implement the reconstruction mechanism at all. Yet null recipes reintroduce trust: as recorded above, a major mailbox provider has objected on precisely this ground, holding that null recipes reintroduce the concept of trust that DKIM2 was intended to remove. Null recipes do not suffice for privacy-preserving intermediaries, whose service requires re-origination of the chain regardless of recipe setting. Null recipes do not suffice for encryption gateways: working group discussion acknowledged that the reconstruction model's central promise - the ability to look back through every modification - cannot hold for in-line encryption. Section 3.4 already addressed the fragility of body signatures in DKIM1 through a pragmatic approach: relaxed canonicalization tolerates common modifications such as whitespace replacement and header field line rewrapping, without requiring intermediaries to declare or reconstruct those changes. The recipe mechanism specified in uses a fixed, always-simple body canonicalization with no relaxed alternative, representing a deliberate departure from this pragmatism in favor of a deterministic reconstruction model. The null recipe outcome is the price of that departure: cases that relaxed canonicalization would have handled silently become explicit failures under that mechanism. Operators should evaluate whether the forensic value of body reconstruction justifies this tradeoff for their specific deployment scenario. The mechanism therefore functions cleanly only for modifications whose reversal carries little forensic value - subject tagging, footer appending - while for the transformations most relevant to security and privacy it either cannot be applied, produces null output or requires re-origination that leaves the model entirely. DKIM2-core documents this boundary as a design choice rather than a deficiency. It provides what the reconstruction model cannot provide uniformly: cryptographic attribution of every body-affecting hop through the changed bh= value under a signed domain identity, applied without exception to every intermediary, including those whose modifications are irreversible by construction. This is not a criticism of the body recipe mechanism. It is an accurate characterization of the deployment landscape that operators need to understand before committing to DKIM2-extended infrastructure.

Specification Ambiguity and Implementation Experience The complexity of the body recipe mechanism produces normative ambiguity that translates directly into interoperability failures. Testing across four implementations from three independent parties in July 2026 revealed 14 failures on multi-hop chains in which intermediate hops made no modifications to the message - the simplest possible case. The failures arose from a normative conflict present in draft-ietf-dkim-dkim2-spec-04 (published 2026-07-05): one section stated a MUST requirement for recipe presence on non-originating Message-Instance headers, a second stated SHOULD for the same scenario and a third permitted omitting the header entirely on unmodified hops. The three parties chose three mutually incompatible but each textually defensible readings. The conflict was acknowledged by the specification authors after testing and identified as requiring revision - but not before the working group chair noted that the keyword used did not satisfy the RFC 2119 criterion for its applicability to the case in question. A transparent hop relaying a message unchanged is not an edge case: it is one of the most common scenarios in real mail delivery paths. The readability and interpretability of the DKIM2 specification has been tested empirically. Three independent implementers working on distinct codebases within a three-week window each reported difficulty with the same areas of the base specification. The first is the normative conflict described above, encountered by an implementer of a C milter library. The second was found by an implementer of a Rust mail server: folding whitespace inside base64-encoded header fields, explicitly permitted by the specification, caused parsing failures in two of three reference implementations tested. The third was reported by an implementer working on an encryption gateway, who cited the null recipe and DSN reconstruction text verbatim, stated that it was difficult to follow and requested worked examples. Three codebases, three weeks, three distinct failure modes in the same region of the specification - not an isolated difficulty but a pattern of implementation complexity that the DKIM2-core approach avoids by design.

Privacy Considerations for Body Recipes Body recipes raise data protection concerns that operators in GDPR and equivalent jurisdictions must evaluate before deployment. These concerns are addressed in detail in Section 6. A summary relevant to the deployment decision is provided here. Body recipes create structured, recoverable representations of previous message content that travel in the message to all downstream recipients and archiving systems. For most recipe types - range references, line counts - the privacy implications are limited. However for recipes that contain literal text from the original message or for the specific cases of DLP redaction and URL rewriting, the recipe mechanism may cause personal data or sensitive content to circulate in a form that was not intended by the operator that originally processed it. Operators subject to GDPR should evaluate whether body recipe generation and transmission is consistent with their data minimization obligations under Article 5 and whether their use of null recipes for sensitive content modifications is sufficient to meet their compliance requirements.

Transition and Interoperability

Overview The deployment of DKIM2 will occur incrementally across a heterogeneous ecosystem that includes DKIM2-core nodes, DKIM2-extended nodes, DKIM1-only nodes and legacy nodes that implement no cryptographic authentication. This section describes the expected behavior of each node type in the presence of the others and identifies the properties that are and are not achievable during the transition period.

Node Types and Behaviors DKIM2-core node - implements envelope binding, chain of custody, header accountability, replay prevention and DSN authentication as defined in Section 3. Adds DKIM2-Chain-mf, DKIM2-Chain-rt, DKIM2-Chain-Mod, DKIM2-Chain-Sig and DKIM2-Chain-Results headers - verifies incoming DKIM2 signatures. Passes DKIM2-extended headers through without interpreting them. DKIM2-extended node - implements all of DKIM2-core plus body recipe generation and verification as defined in Section 4. Adds Message-Instance headers with JSON-encoded recipes in addition to all DKIM2-core headers. DKIM1-only node - implements DKIM1 but not DKIM2. Passes DKIM2 header fields through as unrecognized header fields. Does not add DKIM2 signatures and does not extend DKIM2 chains. Where it rewrites the envelope or modifies signed content it breaks the DKIM2 chain while remaining conformant as a DKIM1 node, since DKIM1 binds neither the envelope nor the full header set. ARC node - implements ARC . ARC and DKIM2-core address overlapping problems with different mechanisms. The relationship between ARC and DKIM2-core is described in Section 5.5. Legacy node - implements no cryptographic authentication. Passes all authentication header fields through without interpreting them. Does not add signatures and does not extend DKIM2 chains. Where it rewrites the envelope or modifies the message it breaks the DKIM2 chain, without departing from any requirement that applies to it. Sections 3.7.7 and 5.3 describe those cases.

Chain Continuity and Legacy Nodes The following considerations apply exclusively to non-DKIM2-participating legacy nodes - MTAs that are unaware of the protocol and cannot declare their modifications. A DKIM2-aware intermediary that modifies a message is never a legacy node in this sense; it MUST either declare all modifications via DKIM2-Chain-Mod or re-originate the message as described in Section 6.1.1. A legacy node in the delivery chain does not break the DKIM2 signature chain, it simply passes existing signatures through without adding new ones. A downstream receiver that encounters a message with a valid DKIM2 chain ending at a hop before the legacy node can verify the chain up to that point and apply local policy for the unsigned segment. A legacy node that makes modifications to the message - adding or changing headers, modifying the body, rewriting URLs - represents a more significant gap in the chain of custody than a transparent relay. Such modifications are not declared via DKIM2-Chain-Mod headers and cannot be attributed to any signing domain. A downstream receiver that encounters a changed bh= value or unexpected header differences between two consecutive DKIM2 signatures can identify that a modification occurred between them but cannot determine what was changed or by whom. Receivers that apply strict chain of custody policies SHOULD treat gaps containing undeclared modifications with additional suspicion, even if the signatures on either side of the gap are individually valid. This is a fundamental constraint of any deployment in which DKIM2-participating and non-participating nodes coexist. Operational experience with analogous mechanisms suggests that complete ecosystem participation is never fully achieved - some legacy infrastructure persists indefinitely. The properties achievable end-to-end therefore depend on the composition of each specific delivery path: Replay prevention - fully effective only when every hop adds a DKIM2 signature with envelope binding. A legacy node between the originator and the final recipient means that the DKIM2-Chain-rt value at the last signed hop does not necessarily reflect the actual final recipient. Backscatter prevention - during the transition period, DSN and backscatter handling follow the graduated enforcement model of Section 3.5.2: a chain broken by a non-participating node yields an undetermined-cause result and MUST NOT trigger rejection on that basis alone. Chain of custody - provides attribution for all hops that participate in DKIM2. A hop that does not sign leaves no trace in the i= sequence, which remains contiguous across it, so its presence is inferred from the message rather than read from the numbering: from a mismatch between the envelope values of the highest signature and the transaction in progress or from content that no signature covers. Its absence from the numbering does not invalidate the chain. It means that accountability for that part of the path is absent and that the part itself cannot be located. Header accountability - fully effective for all hops that implement DKIM2-core. Modifications made by legacy nodes are not declared but are detectable as changes in the signed header set between consecutive DKIM2 signatures. The accountability model described above does not depend on establishing whether the i=1 signer is the message's originator in the RFC5598 sense. It depends only on the signing domain at i=1 accepting responsibility for the message state it presents, regardless of whether that domain composed the message, generated it automatically or admitted it into the DKIM2 ecosystem from a DKIM1-only or unsigned source. This is the same property described for re-origination in Section 6.1.1: a receiver has no signal to distinguish these cases and does not need one, because responsibility attaches to the act of signing at i=1, not to a reconstructed notion of authorship. A forwarder that introduces a previously DKIM1-only message into a DKIM2 chain is, for accountability purposes, indistinguishable from any other i=1 signer - and is equally responsible for replay prevention on the segment it introduces.

Coexistence with DKIM1 DKIM2 reuses DKIM1 DNS key infrastructure. A domain that has DKIM1 keys deployed does not need to make DNS changes to support DKIM2 signing by an ESP or MTA acting on its behalf. This is a deliberate design decision in that significantly reduces the barrier to adoption for domain owners. The reuse has one condition. Section 3.2 of that document forbids a verifier to validate a signature made with a key shorter than 1024 bits. The study cited in Section 3.6 found 84% of the keys in its sample to be 1024 bits or shorter, so the part of that population below the threshold does have a record to replace. That property is confined to signing. Working group discussion has since converged on a receiver side check in which the domains on a delivery path declare their participation in the DNS, either in a dedicated record or as a tag in the DMARC record. A co-author of the base specification has stated that this record change is needed by any site that wants full protection and that there is no way to avoid it. Replay protection therefore does require a DNS change and it requires it from the same population documented in Section 3.5.2 as unable to complete a single DNS change under the bulk sender requirements. Messages MAY carry both DKIM1 and DKIM2 signatures, and will do so for as long as DKIM1 remains in use. Receivers that implement only DKIM1 will verify the DKIM1 signature and ignore the DKIM2 headers. Receivers that implement DKIM2 will verify the DKIM2 chain and MAY also verify the DKIM1 signature for compatibility with existing policy frameworks such as DMARC.

Coexistence with ARC ARC and DKIM2-core address overlapping problems with different mechanisms. ARC provides a trust chain for mailing list redistribution by recording the authentication state of a message as it passes through intermediaries. DKIM2-core is a functional superset of ARC - it provides the same modification attribution and trust chain capabilities plus cryptographic envelope binding that ARC lacks. During the transition period, nodes that implement ARC but not DKIM2-core continue to provide ARC chains independently of the DKIM2 chain. The two chains coexist without conflict but do not bridge each other - a gap in the DKIM2 chain caused by a non-participating node remains a gap regardless of whether that node implements ARC. ARC does not compensate for the absence of DKIM2 participation. Operators that have deployed ARC should not remove it during the DKIM2 transition period. ARC continues to provide value for receivers that evaluate ARC chains as part of their local policy, independently of DKIM2 adoption status. The limited adoption of ARC is informative for DKIM2 deployment expectations. reports approximately 10,000 domains observed sending ARC-signed mail against 9.5 million DKIM records found over the same period, measured from the publication of in 2019. ARC is milter-deployable and architecturally simpler than the body recipe mechanism defined in . Its adoption trajectory suggests that even milter-deployable protocols face significant ecosystem inertia. This reinforces the importance of the DKIM2-core profile: reducing deployment complexity to the minimum necessary to achieve the primary objectives of the protocol maximizes the probability of meaningful adoption. ARC also settles what a receiver does with a chain that does not verify, and the answer in deployment is nothing. Section 5.2 requires that a chain whose validation status is fail be treated the same as a message with no chain, so a failed chain removes information and never produces a refusal. Receivers use it in one direction only: the chain is consulted to accept a message that DMARC would otherwise fail, not to refuse one that passes. It is established practice that a message carrying a failed ARC chain together with valid SPF, DKIM1 and DMARC results is delivered, as that specification requires. Ten years of the ARC experiment, which is the span that document describes, have therefore produced a single enforcement model, advisory and additive. DKIM2 reverses the polarity: the chain becomes a precondition for delivery and its failure becomes a verdict. There is no deployed precedent for the second arrangement. DKIM2-core enables a model of trust based on cryptographic chain of custody rather than direct domain alignment - a model that major providers already implement empirically through ARC evaluation. The approach taken in DKIM2-core is consistent with and builds upon experimental work already deployed in production. proposes extending ARC with explicit envelope binding via dara= and darn= tags in the ARC-Seal, signing SMTP recipients at each hop and declaring the forwarding path. This protocol has been implemented in production by Google on Google Groups infrastructure, as evidenced by headers observed in real message flows. DKIM2-core formalizes and extends this approach with stronger cryptographic binding and a complete chain of custody model.

ARC Header Selection in Practice: Google and Microsoft The following ARC-Message-Signature was captured from a live message relayed by Google's MTA during beta testing of a DKIM2-core milter implementation. It illustrates how production infrastructure interacts with DKIM2-core headers without any modification to Google's software: Google's ARC implementation includes dkim2-chain-rt, dkim2-chain-mf, dkim2-chain-sig and dkim2-chain-results in its signed header set without any explicit knowledge of DKIM2. This is the natural consequence of a defensive signing strategy: when an MTA encounters header fields that carry authentication or chain-of-custody semantics, it includes them in its ARC signature to prevent downstream manipulation. The DKIM2-core headers are recognized as structural metadata and protected accordingly. The contrast with Microsoft Exchange Online Protection is instructive. Microsoft's ARC implementation includes vendor-specific diagnostic headers in its signed set: By signing internal diagnostic headers, Microsoft's ARC seal cryptographically binds downstream MTA infrastructure to Microsoft's internal telemetry format. Any system that strips or modifies these headers - as many security gateways do - will invalidate the Microsoft ARC seal, effectively requiring the entire delivery chain to preserve proprietary diagnostic data. This is architecturally unsound: the chain of custody mechanism is being used to enforce transport of vendor-specific payload rather than to protect message identity. The two examples illustrate a principle that applies equally to DKIM2 deployment: a protocol designed around message identity and envelope binding will be adopted and protected by existing infrastructure automatically, because the headers it produces are recognizable as structural metadata. A protocol that embeds implementation-specific complexity in its headers will produce fragile seals that break at the first hop that does not share the same implementation assumptions. This distinction argues for the minimal, identity-focused approach of DKIM2-core over approaches that bind body content or vendor-specific data into the signed set.

Incremental Deployment Path The path to DKIM2-core deployment has two progressions and they are independent of each other. The first concerns what the operator deploys. The second concerns how strictly it acts on the results of inbound verification. They are stated separately because they serve different ends: the deployment steps determine how the operator's own mail is treated by other receivers, while the enforcement phase determines what the operator itself accepts. The only dependency between them is that an operator cannot enforce a verification it does not perform.

Deployment Steps

1. Outbound signing and declaration: deploy the outbound milter to add DKIM2-Chain-mf, DKIM2-Chain-rt and DKIM2-Chain-Sig headers to outgoing messages, update mailing list managers and other modifying components to add DKIM2-Chain-Mod headers for their modifications and place signers with respect to content-modifying components as described in Section 3.7.7. These belong to one step rather than to successive ones: a hop that signs a message it has modified without declaring the modification produces a chain that fails at the next verifier, so signing and declaring are deployed together or not at all.
2. Inbound verification: deploy the inbound milter to verify incoming DKIM2 signatures and record the results in DKIM2-Chain-Results headers.
3. DKIM2-extended MAY be added at any point by operators who require body accountability, subject to the operational considerations described in Section 4.

Establishing the first two steps together lets the operator build chain-of-custody records for downstream receivers and assess the impact of verification before any enforcement is applied.

Enforcement Phases Phase 1 - monitoring: the verifier MUST NOT reject or delay messages based on any verification result. All outcomes are recorded in the DKIM2-Chain-Results header for downstream policy decisions and local monitoring, with delivery proceeding via SMFIS_CONTINUE regardless of outcome. This phase establishes how DKIM2 behaves on the operator's own traffic before any of it is refused. The verifier MUST add a DKIM2-Chain-Results header for every message processed, recording the outcome of chain verification per the format defined in Section 3.5.1. One header is produced per verified hop. Example: where the i= value identifies the hop and the authserv-id is the verifying MTA FQDN. The full set of result values is defined in Section 3.5.1.

• none - no DKIM2-Chain-Sig present in the received message
• neutral - the verifier evaluated at least one signature at the hop successfully and was unable to evaluate another, so the hop is accepted and the record states that the acceptance does not cover every signature present. This is not a failure and is not rejected in any phase
• temperror - a transient error prevented verification, such as a DNS lookup failure for the signing key; the condition may resolve on retry
• permerror - a structural error prevented verification, such as a gap in the chain, a missing required signature or a malformed key record

Phase 2 - policy enforcement: reject only the failures that Section 3.5.2 classifies as structural or as cryptographic proof of dishonesty by a DKIM2-participating node, together with the partial pass of Section 3.6. Every other failure is delivered with its result recorded in the DKIM2-Chain-Results header. This phase requires confidence that the majority of expected senders have deployed DKIM2 outbound signing. The mapping from verification result to milter action is not a simple one-to-one correspondence between dkim2= result and SMFIS action - it depends on the nature of the failure and whether that proof is present. Consult Section 3.5.2 for the complete decision logic. In all cases where SMFIS_REJECT or SMFIS_TEMPFAIL is returned, no DKIM2-Chain-Results header is written, as the message does not reach any downstream processor. Phase 3 - full reliance (terminal phase): reject every failure, per Section 3.5.2. This phase is entered on local evidence that non-participating nodes have become negligible on the operator's inbound paths and it is reversible if that evidence changes. Entering it is a decision to refuse the mail that still traverses such nodes rather than a finding that none remain, since complete participation is never achieved on every path, as Section 5.3 records.

The DMARC p=reject Mailing List Problem The DMARC p=reject mailing list problem is a known limitation of the current email authentication ecosystem that predates DKIM2. It arises from the interaction between DMARC's domain alignment requirement and the routing changes introduced by mailing list redistribution. The problem has been extensively documented, including in , which describes forwarding failures, mailing list failures and various workarounds - none of which provide a satisfactory solution. That document concludes that the workarounds available today all impose unacceptable costs: those that preserve sender identity break DMARC alignment and those that achieve DMARC alignment do so by destroying sender identity or degrading the user experience in ways that make the message unreadable in standard mail clients. DKIM2-core addresses the structural gap that all those workarounds fail to close. The mechanism of failure: DMARC requires that at least one of SPF or DKIM provide a pass with domain alignment to the RFC5322 From: header. When a message passes through a mailing list two failure modes are possible depending on how the list handles the From: header. Case A - list without From: rewriting When a mailing list redistributes a message without modifying the From: header, SPF alignment fails because the mailing list infrastructure is not authorized by the original sender's SPF record. If the list rewrites the envelope-from for bounce handling - as most do - SPF may technically pass for the list's own domain, but that pass is not aligned with the From: domain and DMARC therefore fails. Similarly, DKIM alignment fails because the list's signing domain differs from the From: domain. It should be noted that Case A is only trivially resolved if the mailing list makes no modifications whatsoever to the message. In practice, mailing lists invariably add List-* headers (List-Id, List-Unsubscribe, List-Archive), subject tags and footers. These additions invalidate the original DKIM1 signature through header modification alone, regardless of body integrity - adding List-Unsubscribe: to a message whose DKIM1 signature covers that header field is sufficient to break alignment. Major email platforms including Gmail and Microsoft 365 now require List-Unsubscribe headers with one-click unsubscribe support to avoid messages being classified as spam and to protect the sending domain's reputation - making this header addition a de facto mandate for any mailing list that wishes to reach subscribers at these providers without deliverability penalties. The invariant addition of this header means that the "body unchanged, signature preserved" scenario is operationally irrelevant for any compliant mailing list. The following Authentication-Results header was observed on a message from itb.it that transited Google Groups and was delivered to a Microsoft Exchange recipient: DMARC failed on alignment grounds regardless: even a body-preserving signature from googlegroups.com would still fail alignment against the From: domain itb.it. Microsoft delivered the message via ARC override. Body recipes cannot fix this failure - even with full body reconstruction, the signing domain googlegroups.com is not aligned with the From: domain itb.it. Case A also applies to nested mailing lists - a list that redistributes to another list. Each list adds its own List-* headers and subject tags, producing multiple instances of the same header field. This creates the duplicate header problem documented in Section 3.3.6: signing software that relies on physical header position rather than explicit index values will compute different hashes depending on which instance it selects. This has been observed in production: OpenDKIM signing both instances of a duplicate header while Microsoft Exchange selecting only one, producing a hash mismatch and a DKIM verification failure despite the message being legitimate. DKIM2-Chain-Mod's explicit i= and seq= indexing eliminates this failure mode entirely. Case B - list with From: rewriting When a mailing list replaces the From: header with its own domain, DMARC passes because the list's signing domain is now aligned with the new From: domain. The following Authentication-Results header was observed on a message from vittorio.moccia@gmail.com that transited a mailing list on itb.it and was delivered to a Microsoft Exchange recipient: DMARC passed completely. But the original sender's identity was destroyed - the recipient sees "Lista Utenti utenti@itb.it" instead of the original author. This is the architectural hack that makes DMARC work today for mailing lists - and it is unsound because it destroys sender identity to achieve alignment, breaking the accountability chain that DKIM2 is designed to establish. In Case B, DMARC alignment is achieved at the cost of sender attribution. If the goal of DKIM2 is to enhance authentication, a solution that requires destroying the primary identity marker - the From: header - to function is self-defeating. Body recipes do not resolve this problem. DMARC fails due to an alignment failure - the signing domain does not match the From: domain. Body recipes address integrity - whether the body has been modified. These are orthogonal problems. In Case A, DMARC fails on domain alignment - a problem in the header and envelope layer that body reconstruction cannot address. In Case B, DMARC passes only because the From: header was replaced - a header modification that has nothing to do with body integrity. In neither case does body reconstruction affect the DMARC outcome. DKIM2-core offers a third path that neither Case A nor Case B provides today. A mailing list implementing DKIM2-core can:

• Retain the original From: header - preserving the original sender's identity
• Declare the addition of List-* headers and any Subject: modifications via DKIM2-Chain-Mod headers
• Sign with its own DKIM2 key, cryptographically binding the envelope and the chain of custody
• Provide receivers with a verifiable record that the list handled the message and what modifications were made

This allows a receiver that evaluates the chain of custody to make an informed trust decision without requiring From: rewriting or body reconstruction. The fields that decision rests on are already protected in transit by infrastructure that knows nothing of the protocol: Google's ARC implementation includes the DKIM2-Chain fields in its signed header set, as Section 5.5 records. Critically, it achieves this without requiring new DNS records or SMTP capabilities. The concrete mechanism is not an override of DMARC but a transformation of the trust decision from probabilistic to deterministic. Today, receivers that accept mailing list messages despite DMARC failure do so based on reputation heuristics - an implicit judgment that the list infrastructure is trustworthy. This judgment cannot be verified cryptographically. DKIM2-core provides the substrate for a verifiable equivalent: the mailing list signs the message with its own DKIM2 key, binding its identity to the specific SMTP transaction via DKIM2-Chain-mf and DKIM2-Chain-rt and declaring any header modifications via DKIM2-Chain-Mod. The body hash bh= at each hop is not an isolated integrity check but a cryptographically attributed statement - any intermediary that modifies the body must sign the new hash with its own domain, making body modification traceable to a specific accountable identity in the chain. The receiver can then verify not just that a trusted party claims to have handled the message, but that a specific identifiable domain handled this specific message to this specific recipient with these specific declared modifications - a chain of custody that is cryptographically verifiable rather than reputationally assumed. If the intermediary is trusted, the chain confirms the message transited through known hands. If the intermediary is not trusted, the chain identifies exactly who touched the message. In both cases the decision is based on cryptographic proof of the transit path, not on body content or reputation alone. By utilizing the i= index and the DKIM2-Chain-rt header fields, DKIM2-core establishes a verifiable cryptographic link between the original message and the modified version distributed by the list. Trust is derived from the verifiable path of the message rather than from an obsolete and hidden body state. This approach maintains the "What You See Is What Was Authenticated" principle, which is abandoned by the body reconstruction mechanism. DKIM2-core provides the cryptographic substrate necessary for an evolved DMARC policy evaluation that can recognize transitive trust through a verified chain of custody. This allows receivers to distinguish between messages that fail DMARC due to spoofing and those that fail due to legitimate mailing list redistribution where the original sender's authentication chain remains intact - a distinction that current DMARC cannot make. The trust model is not theoretical: major providers already apply equivalent heuristics empirically today when evaluating forwarded mail, accepting messages that fail strict DMARC alignment when the handling chain is verifiable. DKIM2-core formalizes and strengthens this existing practice by adding cryptographic envelope binding that makes the trust decision verifiable through cryptographic proof rather than dependent on external reputation systems or allow lists. That evolution has since been proposed. updates so that the policy applied is that of the author domain recovered from the From header field at i=1 rather than that of the apparent author in the field as delivered. The proposal asks the verifier to recover the author domain by the procedure of the base specification, which reads it back through the Recipes. It requires in addition that the entire chain of custody be validated before the evaluation stands. This profile satisfies both. It reaches the first without rebuilding anything, since the value the field held at origination is read from the declarations of Section 3.2, as Section 3.1.2 describes. Verification of every hop is required here in any case, with none of the shortened path that Section 4.3 describes. The ongoing tightening of DMARC enforcement by major providers - including the adoption of strict alignment requirements that mandate exact domain matches rather than subdomain tolerance - makes the mailing list problem more acute over time. Solutions based on From: rewriting become less viable as strict alignment prevents subdomain matches that relaxed alignment would have tolerated. Body reconstruction addresses neither strict nor relaxed alignment failures. DKIM2-core chain of custody provides the only path that preserves original sender identity while remaining compatible with evolving DMARC enforcement requirements. Ultimately, DKIM2-core restores DMARC interoperability with mailing lists by authenticating the modification path, whereas DKIM2-extended fails to address the root cause of misalignment while introducing significant privacy and security overhead. Working group review of the companion best current practices document () identified this gap. The base specification has since addressed it: Section 11 requires the From: header field to be Authentic, which holds where there is a relaxed domain match between the address in the From: field and the signing domain of the relevant signature. Where the From: field has not been altered since the message was first signed, the relevant signature is the one at i=1. Where another system replaces it, the relevant signature is the lowest numbered one at or after the Message-Instance whose Recipe records the replacement, which a verifier establishes by inspecting the Recipes. Its Section 12.4 places the duty on the signer: where the original message is being signed or the From: field has been modified, the signing domain must be chosen so that the From: field is Authentic, which combines with the existing requirement that it match the MAIL FROM domain, so a signer presenting an envelope must satisfy both. The second requirement does not apply where the signature carries no envelope, which its Section 7.1 states for a null MAIL FROM and for a signature carrying nd=. The definition reaches a blunt outcome for two constructs. A From: field carrying more than one mailbox is declared never to be Authentic, without reference to the Sender: field that Section 2.1 requires where the mailbox specifications number more than one. A From: field using the group syntax that same document permits may carry no mailbox at all, so no domain is available to match. In both cases the agent responsible for the transmission is named in the Sender: field where one is present and that is the identity available to be checked. Section 3.1.2 of this profile makes the comparison against that field for both constructs, so each has a defined outcome here. For a From: field using a domain literal this profile reaches the same conclusion as the base specification: there is no domain to compare and no comparison is defined.

Privacy Considerations This section addresses privacy implications of DKIM2-core and DKIM2-extended in accordance with , which provides guidance on privacy considerations in Internet protocol design.

DKIM2-core Privacy Properties DKIM2-core adds the following information to messages in transit: DKIM2-Chain-mf and DKIM2-Chain-rt headers - these fields carry the SMTP envelope values, which may include email addresses not present in the RFC5322 headers. In the common case of direct delivery, these values are already implicit in the message routing. For mailing list redistribution, the rt= value at each hop reveals the address of the individual subscriber receiving that copy of the message. This is not new information - the SMTP envelope already contains this information - but it is now carried in a signed header field that persists in the message and may be archived by downstream systems. DKIM2-Chain-Mod headers - these fields carry previous values of modified header fields. For header modifications that involve personal data - for example a From: header that is rewritten by a mailing list - the original value is preserved in a signed header that travels with the message. Operators that modify headers containing personal data should be aware that the original values will be visible to all downstream recipients and archiving systems. This pattern is already practiced informally in the ecosystem, as described in Section 3.2.4. Authentication-Results headers - these fields record the outcome of DKIM2 verification at each hop. They do not contain message content or personal data beyond what is already present in the message headers. The privacy impact of DKIM2-core is limited and proportionate to its functional objectives. The additional data carried in DKIM2-core headers is necessary for the envelope binding and chain of custody mechanisms and does not represent a material increase in the personal data surface of the message beyond what is already present in the SMTP transaction.

Re-origination by Privacy-Preserving Intermediaries This profile recognizes intentional re-origination by privacy-preserving intermediaries as a legitimate deployment pattern. Some intermediaries exist specifically to remove identifying information from messages - relay services that strip tracking content and redact sender identity or alias and forwarding services with similar goals. For these intermediaries the chain of custody model described above is structurally unavailable at any recipe setting. A content-bearing recipe would disclose exactly the information the service exists to remove. A null recipe does not avoid this either: as noted above, mf= and rt= persist in signed header fields and may be archived by downstream systems, so retaining prior DKIM2-Chain-Sig header fields still exposes the originating envelope addresses and signing domain to every recipient. The correct behavior in this case is re-origination: the privacy-preserving intermediary terminates the inbound chain and signs as a new i=1, using its own domain and envelope. This was confirmed in working group discussion of an equivalent case: an intermediary that deliberately does not provide chain of custody through its systems is not extending the original message under DKIM2, but creating a new message from selected content, and is correctly treated as the originator of that new message once it re-enters the network. This is distinct from chain termination to conceal a modification, where the original message is forwarded without its provenance rather than replaced by a new message. This profile requires the re-originating intermediary to remove all prior DKIM2 header fields - DKIM2-Chain-Sig, DKIM2-Chain-mf, DKIM2-Chain-rt, DKIM2-Chain-Mod and DKIM2-Chain-Results - before signing as the new i=1. Retaining any of them would misrepresent a newly originated message as a continuation of the prior chain, defeating the purpose of re-origination. A re-originating intermediary signing at i=1 is indistinguishable from any other first-hop originator: the absence of a prior chain is the normal state of any message entering the DKIM2 ecosystem for the first time. This indistinguishability is not a limitation of the model but a correct property of it. A recipient cannot and need not identify whether a given i=1 message was composed by a human user, generated by an automated system or re-originated by a privacy-preserving relay - in all three cases the signing domain takes full accountability for the message it presents. Requests for special receiver treatment of re-originating services - such as a normative preference based on the absence of a prior chain - are therefore not implementable: the receiver has no signal to act on. The absence of a prior chain MUST NOT be treated as a negative indicator in enforcement policy; it is the expected state of any message that legitimately begins its DKIM2 chain at the current hop.

DKIM2-extended Privacy Considerations DKIM2-extended raises privacy concerns that are qualitatively different from those of standard email processing. Email messages already transit through systems that read, analyze and archive them - existing data protection frameworks address this reality. What DKIM2-extended adds is the systematic creation of structured, cryptographically signed records of previous versions of message content that did not previously exist as discrete data objects. A standard email message represents the current state of a communication. A message with body recipes represents both the current state and a signed history of previous states distributed to every downstream recipient and archiving system in cryptographically immutable form. This distinction is relevant to data protection law in the ways described below.

The Null Recipe Mechanism The null recipe is the primary technical instrument available to intermediaries for managing privacy risk in DKIM2-extended deployments. An intermediary that modifies message content may declare null rather than generating a content-bearing recipe, signalling that a modification occurred and who made it without creating any structured record of the previous content. The null recipe preserves the core accountability property of DKIM2 - the modification is declared and attributed - while avoiding the creation of personal data records that would otherwise travel with the message to all downstream recipients and archiving systems. It is the correct response in any situation where generating a content-bearing recipe would conflict with data protection obligations or organizational security policy. The current specification does not provide normative guidance on when intermediaries are obligated to use null recipes. This document addresses that gap for specific deployment scenarios in the sections that follow.

Data Minimization GDPR Article 5(1)(c) requires that personal data be adequate, relevant and limited to what is necessary for the purposes for which it is processed. The primary operational objectives of DKIM2 - replay prevention, backscatter mitigation, modification attribution - are achievable without body recipes as argued in Section 4.6. Body recipe data collection may therefore not meet the necessity test under Article 5(1)(c). The specific minimization problem of body recipes is not that personal data is processed - it is that body recipes create a new category of structured data that did not previously exist: recoverable representations of previous message content, distributed in signed form to all downstream systems. This is qualitatively different from the processing that occurs in standard email transit and raises minimization questions that do not arise for DKIM2-core. This is not a definitive legal assessment. Operators subject to GDPR should seek legal advice on whether their specific use of body recipes is consistent with their data minimization obligations.

Data Retention GDPR Article 5(1)(e) requires that personal data be kept in a form that permits identification of data subjects for no longer than necessary. Body recipes travel in the message and may be archived by any system that receives or intercepts it - including the final recipient's mail store, compliance archiving systems and, in some jurisdictions, systems operated under lawful interception or judicial oversight obligations. Unlike the message body itself, body recipes embedded in signed headers cannot be selectively removed without invalidating the signature chain. This creates a retention problem that has no clean technical resolution: the data persists in signed form in every copy of the message held by any system that archived it, regardless of the originating organization's retention policy. Furthermore, intermediaries that implement DKIM2-extended may find that the body recipe itself constitutes an audit trail of modifications - and in many jurisdictions, audit records are subject to mandatory retention obligations that may exceed the retention period applicable to the communication content itself. An intermediary may therefore find itself obligated to retain recipe content as an audit record for extended periods, regardless of its normal data retention policy. This obligation did not exist before DKIM2-extended because no structured modification record was created during transit. Operators should evaluate whether their archiving systems can handle recipe content consistently with applicable obligations under Article 5(1)(e) and any sector-specific retention requirements in their jurisdiction.

DLP Systems and Body Recipes A Data Loss Prevention system that redacts sensitive content does so precisely because that data must not circulate. A body recipe that allows reconstruction of the content before redaction creates a structured record of the very data the DLP system was designed to protect - a structural contradiction between the purpose of the system and what DKIM2-extended asks it to generate. Operators deploying DLP systems in conjunction with DKIM2-extended MUST use null recipes as described in Section 6.2.1 for all modifications that involve redaction of sensitive content.

Antivirus Gateways and Body Recipes When an antivirus gateway removes a malicious attachment, the removed content should be eliminated, not preserved. A content-bearing recipe for such a removal creates a structured record of content that should not exist downstream. Operators deploying antivirus gateways in conjunction with DKIM2-extended MUST use null recipes as described in Section 6.2.1 for all modifications that involve removal of malicious or suspicious content.

URL Rewriting and Body Recipes Security gateways that rewrite URLs generate recipes containing the original URLs, which may reveal sensitive communication content or internal infrastructure details not intended for downstream exposure. Operators who cannot expose original URLs in recipe content MUST use null recipes as described in Section 6.2.1.

Encryption Gateways and Body Recipes Encryption represents the limiting case of the pattern above. Where DLP, antivirus and URL-rewriting systems face a choice between content-bearing and null recipes, an encryption gateway has no meaningful recipe to generate at all: the content it processes is opaque ciphertext and no reconstruction model - content-bearing or null - can meaningfully describe a transformation the mechanism was never designed to see. Section 4.6 addresses the technical consequences of this gap. From a privacy standpoint the outcome is favorable: because DKIM2-extended cannot represent the encrypted content in the first place, no structured record of plaintext is ever created, regardless of recipe policy.

Compliance with Data Subject Rights GDPR Articles 16 and 17 grant data subjects the right to rectification of inaccurate personal data and the right to erasure. Body recipes create structural conflicts with both rights that manifest differently depending on the stage of the message lifecycle. In addition to GDPR, operators must consider Directive 2002/58/EC (ePrivacy Directive) , which mandates the confidentiality of communications. By creating structured, cryptographically signed records of previous body states that are durably embedded in the message itself, DKIM2-extended converts transient communication content into a verifiable content history that travels with the message to every downstream system. This conversion raises questions about the applicability of mere conduit exemptions under Article 12 of the e-Commerce Directive and its successor provisions, which condition that exemption on the intermediary not modifying the information transmitted. Generating a body recipe may be considered a form of content processing that goes beyond mere transport, potentially requiring an explicit legal basis for the creation and retention of such records at intermediate hops. The erasure problem - the null recipe described in Section 6.2.1 is a preventive instrument: if applied consistently before personal data enters the recipe, no erasure conflict arises. However it is not a remedial instrument. Once a content-bearing recipe has been generated and distributed, the Right to Erasure under Article 17 GDPR becomes technically unenforceable: the organization that generated the recipe can delete its own copy, but the recipe exists in cryptographically signed form in every downstream copy of the message. GDPR Article 17 imposes an obligation on the controller to erase data - but it provides no mechanism to compel deletion from systems in other administrative domains, other jurisdictions or operated by parties who are not data controllers under the same legal framework. Furthermore, an intermediary that generated a recipe may itself face conflicting obligations: the erasure request requires deletion, but audit trail or documentary evidence obligations - contractual, regulatory or legal - may require retention of records of modifications made. These two obligations cannot be simultaneously fulfilled. This conflict is not a gap in the legal framework - it is a structural consequence of DKIM2-extended creating cryptographically immutable records at transit nodes. The rectification problem - the rectification conflict is structurally irresolvable and arises specifically when the message is in archival state. During transit the message exists transiently and the problem does not arise. The problem emerges when the message is archived - by any system at any point in the delivery chain - with a recipe containing inaccurate personal data. At that point three obligations come into direct conflict. First, GDPR Article 16 requires that the inaccurate personal data be corrected. Second, correcting the value in the recipe invalidates the cryptographic signature of the hop that generated it, which cascades through all subsequent signatures in the chain. Third, if the archive is used as certified documentary evidence - for compliance, audit or legal purposes - its integrity must be preserved. Modifying it to fulfill the rectification request destroys its evidentiary value. Not modifying it violates the data subject's right. This three-way conflict between data subject rights, cryptographic integrity and documentary evidence obligations has no technical resolution within the current DKIM2-extended architecture. It does not arise in standard email archiving, where an organization can modify or delete its own archives without affecting cryptographic chains, because standard email archives do not carry immutable signed records of previous content versions. Joint controllership - an intermediary that generates body recipes is no longer merely transporting the message - it is creating a new structured record of personal data by determining what previous content to include in the recipe and ensuring its persistence through cryptographic binding. This may constitute joint controllership under GDPR Article 26, with associated obligations including the potential requirement for a Data Protection Impact Assessment under Article 35. Operators should evaluate whether their recipe generation activities trigger these obligations.

Privacy Review Recommendation At the time of writing, includes a Security Considerations section, added in its revision 07, and no Privacy Considerations section. The concerns raised here follow discussion on the ietf-dkim mailing list initiated in March 2026. For a specification intended to become an IETF Standards Track document, privacy and security considerations are required per (BCP 72). This document provides suggested privacy considerations text based on for consideration by the working group as a contribution to the base specification. Note on : this is an IAB document rather than an IETF document. However IAB documents on protocol design are explicitly relevant to IETF Standards Track work - the IAB and IETF coordinate on architectural and privacy matters as part of the overall Internet standards process. The privacy considerations in this document are consistent with both and the security considerations requirements of .

Architectural Conclusion The privacy considerations described in this section lead to a clear architectural conclusion: DKIM2-extended MUST remain optional and loosely coupled to DKIM2-core. This is not merely a deployment preference - it is a requirement derived from data protection principles. An operator subject to and who activates DKIM2-extended takes on explicit data processing obligations for the personal data contained in body recipes, including obligations that may not arise under standard email processing - among them the creation of audit-trail records at transit nodes, potential joint controllership under GDPR Article 26 and questions about mere conduit exemptions under the e-Commerce Directive. An operator who implements only DKIM2-core has no such obligations beyond those that exist today for standard email processing. The optional nature of DKIM2-extended is therefore not a technical convenience but a legal necessity for a significant portion of the global email infrastructure. The interoperability dimension of this concern extends beyond individual operators. The Digital Markets Act (DMA) requires gatekeepers to ensure interoperability with third-party services and prohibits technical measures that create barriers to entry for smaller operators. An email authentication standard that is only practically implementable by large providers with dedicated engineering teams and legal resources to manage GDPR obligations for body recipe processing raises questions about compliance with DMA interoperability requirements. DKIM2-core, by contrast, is implementable by any operator regardless of size and imposes no data processing obligations beyond those that exist today. DKIM2-core and DKIM2-extended are designed to coexist cleanly. A DKIM2-core-only node passes Message-Instance headers through as opaque signed content without interpreting them, preserving the integrity of the chain without requiring participation in body recipe processing. A DKIM2-extended node adds full body recipe functionality on top of the core. This is a deliberate application of graceful degradation: a core-only deployment does not break DKIM2-extended deployments - it simply does not extend them. The chain of custody remains intact, the envelope binding remains verifiable and the signed header accountability remains functional. Operators who cannot or choose not to implement body recipe processing - whether for technical, operational or legal reasons - remain full participants in the DKIM2 ecosystem. Activating DKIM2-extended adds capabilities; not activating it does not degrade the core functionality in any way. This clean separation is the architectural property that makes DKIM2 deployable across the heterogeneous ecosystem and across jurisdictions with different data protection requirements.

Implementation Status Note to RFC Editor: please remove this section, and the reference to , before publication. This section records the status of known implementations of the profile described in this document, per . Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. This section covers implementations of the specific deployment profile described in this document; implementations of other aspects of the DKIM2 ecosystem, such as body recipe tooling, are out of scope here and are not surveyed.

DarkChain / DarkChains Organization: Independent Implementation: https://github.com/darkglobe-project/darkglobe-suite Description: DarkChain (verifier) and DarkChains (signer) implement the DKIM2-core profile described in this document as two independent milter processes. Written in C against libmilter, deployed on live mail infrastructure with Sendmail. No MTA core modifications required. Coverage: Envelope binding via DKIM2-Chain-mf and DKIM2-Chain-rt with per-recipient granularity. Chain of custody verification hop-by-hop. Header modification tracking via DKIM2-Chain-Mod (signing and verification of declarations produced by modifying components). Header integrity hash (hh=). SRS envelope rewriting for forwarding via smfi_chgfrom(). Full optional attestation mode (pre/post mailing list signing). Configurable X-* prefix exclusion. Level of maturity: Beta, deployed on live mail infrastructure processing traffic from Microsoft Exchange Online and Google MTA infrastructure. Licensing: Apache 2.0

Security Considerations

Security Properties of DKIM2-core Replay prevention - a valid DKIM2 signature cannot be reused for a different recipient without breaking the chain. The cryptographic binding of RCPT TO values in DKIM2-Chain-rt to the signature at every hop makes replay attacks detectable by any conformant verifier. DKIM2-core envelope binding uses one DKIM2-Chain-rt header per recipient address. A verifier checks that the RCPT TO of the current SMTP session matches exactly the addr= value of one of the DKIM2-Chain-rt headers at the highest hop index. A message signed for recipients A, B and C cannot be made to appear as though it had been signed for recipient A alone, because the header carrying addr=A was signed as part of a set that also includes the headers for B and C and none of them can be removed without breaking that hop's signature. This is a structural improvement over designs that aggregate all recipients in a single signed blob, where a subset of recipients could be used without breaking the signature. The base specification addresses this risk through an optional "exploded" flag (Section 10.10) that signals a message was sent to multiple recipients, and which its Section 12.5 forbids on the signature at i=1. However this mitigation has structural weaknesses: the flag is optional and depends on the signer including it and if the signer omits it or an attacker removes it, the protection fails. The flag also does not prevent replay to a subset of the original recipients - it only signals that multiple recipients existed. DKIM2-core's one-header-per-address design removes the dependency on an optional flag: the signed set of DKIM2-Chain-rt headers is cryptographically bound to the chain and a transaction for a recipient that no hop committed to produces a verifiable mismatch. Sender accountability - the signing domain at each hop is cryptographically bound to the message and the envelope. A receiver can establish a verifiable chain of custody from originator to final recipient, identifying every entity that handled the message and declared its modifications. Backscatter prevention - DSN generation is authenticated through the chain of custody. A receiver that rejects a message during the SMTP session directs the rejection to the connected peer, never to the envelope sender. This prevents backscatter to innocent sender domains. Header integrity - modifications to header fields are declared via DKIM2-Chain-Mod headers and are covered by the signature of the modifying hop. Undeclared header modifications are detectable as inconsistencies between the signed header set and the declared modifications. Body integrity - the bh= value at each hop provides a hash of the current message body. Changes in bh= between consecutive signatures identify hops where body modifications occurred and attribute them to the signing domain. Full body reconstruction is not provided in DKIM2-core and is not required for the primary security objectives.

The Binary Trust Model The three-outcome model described in this section applies to messages that have transited an entirely DKIM2-participating chain. When a non-participating legacy node is present in the delivery path and has modified the message, the resulting verification failure does not fall into any of these three categories: the verifier cannot attribute the modification to any signing domain and the graduated enforcement model defined in Section 3.5.2 applies instead. The binary trust model described here is therefore a property of mature deployment environments, not of the transition period. The security model of DKIM2 relies on the chain of custody established by envelope binding. In operational environments, trust in an intermediary is a binary decision based on reputation and verifiable identity - there is no partial trust in email authentication. This has a direct consequence for the role of body recipes in security decisions. If a receiver does not trust intermediary B, body recipes provide no additional assurance. B could have inserted malicious content, removed a legal disclaimer or rewritten URLs to phishing sites - a JSON recipe documenting those changes does not make them safe. As the authors of the base specification have acknowledged, recipes "don't stop B from adding bad things." If a receiver does trust intermediary B, the chain of custody established by DKIM2-core is sufficient. The cryptographic binding of MAIL FROM and RCPT TO at every hop, combined with DKIM2-Chain-Mod declarations for header modifications, provides the verifiable path that enables the trust decision. This is precisely the model that Microsoft and Google already apply empirically today when evaluating forwarded mail. Body recipes are a descriptive capability for forensic and archival purposes. Envelope binding is the mandatory security foundation. Furthermore, body recipes provide zero protection against replay attacks where the content remains identical - only the envelope binding of DKIM2-core addresses this fundamental vulnerability. In summary: if trust is binary, recipes are a descriptive luxury, not a security necessity. The separation between DKIM2-core and DKIM2-extended reflects this distinction: core provides the security properties that matter for delivery decisions, extended provides additional accountability for operators who need it and can afford the operational cost. DKIM2 verification produces three qualitatively different outcomes that operators must distinguish in their delivery policy. A message that transits the chain without body modifications and with a complete chain of valid signatures provides the strongest assurance - full cryptographic accountability from originator to recipient. A message with body modifications declared via recipes provides weaker assurance - the modifications are attributed and reversible, but the displayed content differs from what was originally signed. A message with null recipes at one or more hops provides assurance equivalent to DKIM2-core: the chain of custody and envelope binding are intact, but no body reconstruction is possible for those hops. These three outcomes have different risk profiles and MUST NOT be treated equivalently in delivery policy. In particular, the second and third outcomes do not provide the same level of assurance as the first for purposes of domain reputation, BIMI display or any policy that depends on content integrity rather than transit accountability. DKIM2-core provides the properties common to all three outcomes - envelope binding, chain of custody, header accountability - without requiring operators to distinguish between them or to deploy the additional infrastructure that the second outcome requires. DKIM2-extended adds the distinction between the second and third outcomes at the deployment cost documented in Section 4 - a cost that is only justified for operators with the infrastructure to benefit from body reconstruction data.

Implementation Robustness and Reduced Attack Surface DKIM2-core uses the tag-value syntax of DKIM1 throughout, without nested or opaque data structures such as JSON-encoded values within header fields. This design choice has direct security implications. The elimination of multi-layered parsing - JSON-in-base64 embedded in header fields - removes a category of attack surface that does not exist in DKIM1 or ARC. Parser vulnerabilities in JSON libraries, including memory exhaustion and type confusion attacks, cannot be triggered by DKIM2-core header processing. This is consistent with the attack surface analysis in Section 8.3.1. All DKIM2-core declarations - envelope binding, modification attribution, chain of custody - are in cleartext tag-value format, directly inspectable in mail logs without specialized tooling. This transparency supports real-time threat detection and incident response in ways that base64-encoded opaque blobs do not. The need for dedicated tooling to render DKIM2 header fields in human-readable form confirms that the current encoding is not suitable for operational diagnostics without specialised software, a property that tag-value encoding does not share. The interoperability failures documented above - tag ordering within DKIM2-Signature fields (Section 3.3.6) and JSON key case sensitivity in header recipes ( Section 5) - share a common cause: multi-layered, order-sensitive or case-sensitive encoding creates ambiguity that independent implementations resolve differently even when each is acting in good faith. DKIM2-core's use of explicit i= and seq= index values in cleartext tag-value format eliminates this category of implementation ambiguity entirely. The practical consequence of these design choices is immediate implementability. DKIM2-core header processing requires only the tag-value parser already present in every DKIM1 and ARC implementation - no new libraries, no new data structures, no new parsing infrastructure. A conformant DKIM2-core milter can be built by extending an existing ARC milter with envelope binding and modification declaration. The incremental implementation cost above a working ARC milter is measured in a few weeks, not months. This stands in contrast to DKIM2-extended, which requires JSON parsing infrastructure, stateful message buffering and persistent shared storage, none of which are present in existing DKIM1 or ARC implementations.

Security Limitations of DKIM2-core Legacy node gap - a legacy node in the delivery chain does not extend the DKIM2 chain. Modifications made by legacy nodes are not declared and cannot be attributed to any signing domain. The gap is not visible as a sequence discontinuity - legacy nodes do not add DKIM2-Chain-Sig headers and do not increment i=. The gap manifests instead as a mismatch between the current message state and the last DKIM2 signature: a changed bh= value, an hh= mismatch or a rollback failure at the final signed hop. The verifier knows that something changed after the last DKIM2-participating node but cannot determine what was changed or by whom. The graduated enforcement model defined in Section 3.5.2 governs how receivers handle this case. Key compromise - compromise of a signing key allows an attacker to generate valid signatures for that domain. Key rotation procedures as defined in apply to DKIM2 keys. The i= sequence provides some mitigation - an attacker who generates a forged signature must insert it into a plausible position in the chain. DNS security - DKIM2 inherits the DNS security properties of DKIM1. Key publication relies on DNS, which is subject to cache poisoning and other attacks unless DNSSEC is deployed. Operators SHOULD deploy DNSSEC for their signing domains. Relaxed domain match - the relaxed domain match algorithm for DKIM2-Chain-mf allows subaddress schemes used for bounce handling. Operators should be aware that this algorithm permits signatures from subdomains of the MAIL FROM domain, which may be exploitable if subdomain delegation is not carefully controlled.

Security Considerations for DKIM2-extended DKIM2-extended introduces additional attack surface beyond DKIM2-core. Operators considering DKIM2-extended deployment should evaluate the following.

JSON Parsing Attack Surface Message-Instance headers contain base64-encoded JSON that must be decoded and parsed at every verifying hop. JSON parsers process untrusted external input in the delivery critical path and are subject to algorithmic complexity attacks that cause excessive CPU consumption, memory exhaustion through deeply nested structures, parser inconsistency across implementations and buffer overflows in poorly implemented parsers. A specific concern is Type Confusion: differences between JSON parser implementations can cause a recipe to be interpreted differently by intermediaries and final recipients. The base specification closes one of these cases in its revision 07, where its Section 5 requires that property names be unique within any JSON object. That constraint cannot be expressed in the schema, so it holds only where each implementation enforces it in code. The divergence lives in the reconstruction, so it surfaces only where a verifier parses a Recipe that another party produced. A verifier that checks the most recent signature alone surfaces one case, that of its predecessor, and there it can invalidate a signature the predecessor presented as valid. A verifier that walks the chain undoes the Recipes of the hops above each signature it checks. At every step its own parser decides what the earlier state was. Wherever that resolution differs from the one the producing hop used, the signature under examination can fail here and have passed there. Two consequences follow. The same signed bytes can be valid on a path whose hops share a parsing resolution and invalid at the first hop of a path that does not, so delivery is selective rather than uniform. And at one node the same message can pass the check of the most recent signature and fail a traversal of the whole chain, so the verdict depends on the depth that node chose, which the base specification leaves to it, as Section 4.3 of this profile describes. The surface is the set of rules the schema does not express. The base specification says of the key rules that they "cannot be expressed within the JSON schema, so implementations will need to take other steps to ensure conformance" and that "particular care needs to be taken to ensure uniqueness". It says the same of the restriction on CR and LF inside a decoded "u" step. It notes that "a Body Recipe can conform to the JSON schema and still break the restrictions in this section". Each of those rules is re-implemented by hand in every port. Conformance to it is a property of the installation that the message does not reveal. The report recorded in Section 4.4.2 is an instance: a library emitted strings that other parsers reject, so separate utilities were required to check validity before the Recipe left the generator. In a protocol whose purpose is authentication, a verdict that depends on the implementation and on the depth of the check rather than on the message is a missing guarantee rather than a vulnerability. The JSON recipe syntax also exhibits semantic ambiguity: the same construct - an empty array [] - is used in different contexts with different meanings. In backward-looking recipes it declares that a header field was added by the current hop and had no previous value. In forward-looking recipe proposals discussed in the working group, the same construct declares that a header field should be ignored during verification of a future message. This dual meaning requires implementations to determine the correct interpretation from context, introducing a category of parser confusion that does not exist in the tag-value formats used by DKIM1 and DKIM2-core. The need to define explicit limits on object count, nesting depth and total recipe size - as discussed in Section 4.4.1 - demonstrates that this attack surface has been recognized. Operators MUST ensure that their JSON parsing implementation enforces strict resource limits on input size, nesting depth and object count appropriate to their operational environment. Implementations SHOULD use a JSON parser that strictly conforms to and rejects input that is ambiguous under that specification - in particular, implementations MUST reject JSON objects with duplicate keys rather than silently selecting one value. Sandboxing the JSON parser from the MTA delivery process is RECOMMENDED where operationally feasible. The properties that make JSON processing safe are properties of the parser and not of the format: iterative rather than recursive parsing, a bounded nesting depth, no hash table for object keys, continuous fuzzing. A specification that prescribes the format and leaves those properties to each implementer has allocated the requirement to the implementation and the same format is then processed safely by one deployment and unsafely by the next.

Recipe Chain Integrity A malicious intermediary that controls a node in the delivery chain can construct a recipe that presents a clean original message to the verifier while the delivered content is malicious. This attack requires control of a node in the chain and the ability to generate a valid signature for that node's domain, but is feasible for a compromised or malicious intermediary. Verifiers MUST validate the complete recipe chain from originator to final recipient and MUST NOT rely on individual recipes in isolation. That is a requirement of this profile and not of the base specification, which as Section 4.3 of this profile describes leaves the depth of verification to the verifier.

Semantic Gap Between Verification and Visualization DKIM2-extended introduces a structural discrepancy between the reconstructed body - the previous state that is cryptographically verified - and the transferred body - the modified state that is rendered to the end user. This creates a semantic gap that undermines the fundamental premise of email authentication: that the content being displayed is the content that was authenticated. When a receiver applies a body recipe to validate a DKIM signature on a version of the message that is no longer present, a verification pass result is semantically ambiguous. The user is presented with a verified status - a positive Authentication-Results header or a trust indicator in a mail client - but the content displayed does not correspond to the cryptographically covered data. This gap is a vector for social engineering. A compromised intermediary can craft modifications that are functionally malicious while providing a valid reconstruction recipe that produces a clean original. The receiver's verification passes on the ghost version; the user sees and acts on the malicious version. There is no standardized mechanism to communicate a "reconstructed authentication" state to human recipients without creating UI confusion or warning fatigue. The DKIM2-extended body recipe mechanism therefore constitutes a departure from the "What You See Is What Was Signed" principle. It should be treated as a specialized tool for automated forensic processing rather than a general-purpose body integrity mechanism for end-user trust decisions. This concern is distinct from but related to the attack described in Section 8.3.2, where a recipe presents a clean original while the delivered content is malicious. That attack exploits the gap to authenticate a stolen message. The semantic gap concern exists even without malicious intent - any legitimate body modification creates a divergence between what was authenticated and what is displayed.

Attribution of Change vs. Verification of State It has been argued that body recipes provide attribution for modifications. However, attribution of a state change is not equivalent to verification of the previous state. In mixed environments (DKIM1/DKIM2), an intermediary can provide a cryptographically consistent recipe for a state that never existed, effectively signing a fabrication. As long as the fabrication is consistent with a previously obtained DKIM1 signature, the mechanisms described in the DKIM2-extended profile validate the lie as truth. The attack proceeds as follows: a malicious intermediary in possession of a stolen DKIM1-signed message receives a legitimate but unsigned message. It provides a signed recipe that, when applied to the legitimate message, reconstructs the stolen DKIM1 message. The intermediary's DKIM2 signature validates the recipe's integrity. The recipe validates the stolen message's DKIM1 signature. The receiver sees a valid chain and believes the trusted domain sent the stolen message in the current delivery. Revision 08 of the base specification invites that assessment: its Section 13.4 states that a receiving system may wish to assess the original form of the message and that all the Recipes could be undone in order to do so. DKIM2-core avoids this entirely. An intermediary declares what it received and what it changed - attestation of flow, not reconstruction of state. There is no recipe mechanism that can be used as a payload injector because there is no mechanism for claiming what the previous state was. DKIM2-core provides a stateless chain of custody over message headers and body content as transmitted. This property is well-suited to general Internet mail flow across administrative boundaries. DKIM2-extended introduces stateful body reconstruction across those same boundaries, with the verification limitations described above. Implementers SHOULD carefully evaluate the operational, security and legal implications of deploying DKIM2-extended before adoption and MUST NOT treat a passing DKIM2-extended verification result as equivalent to verification of the reconstructed prior message state.

Null Recipe Ambiguity A null recipe declares that a modification was made but provides no information about the nature or extent of the modification. A malicious intermediary can use a null recipe to conceal arbitrary body modifications while remaining nominally compliant with the protocol. Receivers that rely on body recipe verification for security decisions MUST treat null recipes as untrusted modifications equivalent to a complete body replacement.

Recipe Stripping An intermediary that strips body recipe content from a message removes information that downstream verifiers depend on. Revision 08 of the base specification defines the outcome in each form that leaves a trace. A Message-Instance header field removed from the sequence leaves a gap in the numbering, which that document states in two places makes the message not a Fully Verified DKIM2 Message. A recipe whose content is malformed gives a permanent error with an error string of its own. What no mechanism distinguishes is the removal of the whole chain: a message stripped of every DKIM2 header field is indistinguishable from one that never carried any, which is the case Section 6.1.1 of this profile requires a receiver not to treat as a negative indicator. Implementations MUST handle each of these cases without producing incorrect verification results.

Stateful Milter Attack Surface The persistent shared storage required by stateful DKIM2-extended milter implementations is an additional attack surface. Compromise of the shared storage allows an attacker to manipulate cached message state and cause the milter to generate incorrect recipes or signatures. Operators MUST apply appropriate access controls to stateful milter storage and MUST monitor for unexpected modifications.

Cryptographic Agility DKIM2-core mandates support for RSA-SHA256 and Ed25519-SHA256, as specified in Section 3.6. DKIM2-core evaluates the body hash independently of signature generation: the bh= value is computed first and included as a tag in the DKIM2-Chain-Sig header, which is then signed as a whole. This pre-hashed input model is essential for streaming processing of message bodies and must be preserved by any future signing algorithm. Working group discussion has confirmed this constraint in the context of seeking post-quantum algorithm guidance from the Crypto Forum Research Group. Some post-quantum signature schemes incorporate their own hash function and do not accept pre-hashed input, which would be incompatible with this architecture. The tag-value format of DKIM2-Chain-Sig imposes no constraints on the signing algorithm beyond producing a binary output encodable in base64 and accepting pre-hashed input. This ensures forward compatibility with post-quantum algorithms that meet these requirements when they are standardized for use in email authentication. Operators should monitor the development of post-quantum algorithm standards and be prepared to add support for new algorithms as they are standardized. The base specification's chain matching model binds mf= and rt= as tags within DKIM2-Signature itself, alongside d=, s=, a=, b=, bh= and optional flags. A prior working group proposal to carry sender and recipient binding in separate plaintext header fields was not adopted. Combined with the working group's direction toward dual-algorithm signing - a classical algorithm alongside a post-quantum algorithm - within a single DKIM2-Signature header, this concentration of content into one field compounds under size pressure: post-quantum signature material must coexist with envelope binding tags and modification flags in the same field. A DKIM2-Signature carrying RSA-SHA256 and ML-DSA-44 signatures together with mf=, rt=, d=, s= and flags would exceed 4000 characters in a single header field. With separated envelope binding, each DKIM2-Chain-Sig carries only signature material - approximately 350 characters for RSA-SHA256 or 3300 for ML-DSA-44 - and the envelope headers remain unchanged regardless of algorithm count. DKIM2-core's separation of envelope binding into dedicated header fields (DKIM2-Chain-mf, DKIM2-Chain-rt) avoids this concentration - a second algorithm is accommodated by an additional DKIM2-Chain-Sig header field carrying only signature material, not by enlarging a single field that also carries envelope and modification state. The use of both RSA-SHA256 and Ed25519-SHA256 in parallel is RECOMMENDED during the transition period to provide cryptographic agility. Ed25519 signatures are significantly shorter than RSA signatures and impose lower computational overhead at scale.

Timestamp Handling DKIM2 signatures include a timestamp. A signature with a timestamp more than 5 minutes in the future MUST NOT be treated as valid. This prevents pre-generated signature replay while accommodating normal clock skew between NTP-synchronized systems. A tolerance of 5 minutes is sufficient for any NTP-synchronized infrastructure and eliminates the replay window that a looser future timestamp check would create. Signatures with timestamps more than 15 days in the past SHOULD be treated as potential replays and rejected subject to local policy. The 15-day threshold accommodates legitimate redistribution delays including mailing list queuing, temporary delivery failures and held messages without creating an excessive replay window. Note that mailing list redistribution introduces a new signature at the time of redistribution - the relevant timestamp is when the list signed the message, not when the original sender signed it. Operators SHOULD NOT configure thresholds beyond 15 days without explicit operational justification.

Header Inclusion in hh=: Functional Classification The DKIM2 base specification excludes all X-* header fields from the signed header set. The hh= mechanism defined in this profile takes a more granular approach based on the functional role of each header, not its prefix alone. The critical constraint is interoperability: the classification of any given header as included or excluded in hh= MUST be consistent across all DKIM2-participating nodes. A header included by one verifier and excluded by another will produce hh= mismatches between conforming implementations on unchanged messages, indistinguishable from a real modification. The classification is therefore not a per-deployment choice but a normative requirement that applies uniformly. The authoritative list will be defined in the base specification or a companion document; this profile documents the functional principle and provides a working default for the current deployment period. The classification operates at three levels with explicit priority: Level 1 - Structural exclusions (always active, not overridable): headers managed by the authentication protocol itself and headers that change legitimately at every hop. These include DKIM2-Chain-Sig, DKIM2-Chain-mf, DKIM2-Chain-rt, DKIM2-Chain-Mod, DKIM2-Chain-Results, DKIM-Signature, ARC-*, Received, Return-Path and Authentication-Results. Including these would create circular dependencies or cause verification failures on every legitimate hop regardless of implementation choices. Level 2 - Functional exclusions (normatively defined, uniform across implementations): headers whose function is exclusively internal to the operator that adds them - vendor-specific diagnostic telemetry, tracing identifiers and operational metadata that does not cross organizational boundaries. These are legitimately stripped at domain boundaries and have no security relevance to downstream receivers. The category is not limited to the X-* prefix: any header whose function is purely internal to the adding operator belongs here regardless of its naming convention. Examples include vendor-internal X-MS-* diagnostic headers (Microsoft Exchange Online Protection), X-GM-* (Google internal tracing) and equivalent vendor-internal namespaces. The authoritative list of excluded prefixes and header names is not a per-deployment configuration - it must be agreed upon across the ecosystem and defined normatively. Level 3 - Cross-organizational inclusion overrides (normatively defined, take precedence over Level 2): individual headers that, despite carrying a vendor-associated prefix, serve a function that crosses organizational boundaries - abuse reporting mechanisms, feedback loop identifiers, authenticated identity assertions used across organizational perimeters. These MUST be included in hh= regardless of any prefix-based exclusion at Level 2. The structural exclusions of Level 1 are not overridable by Level 3. This three-level model resolves an apparent contradiction in the evidence: X-MS-Exchange-SenderADCheck carries a prefix (X-MS-) whose vendor-internal instances Level 2 excludes, but its function - recording an authentication check result consumed across organizational boundaries - places it in Level 3. The security relevance of this category is not hypothetical. A message carrying to the working group the position that X- headers are "generally specific to services" and should not be signed was itself authenticated with a DKIM1 signature whose h= tag includes X-MS-Exchange-SenderADCheck - a vendor-specific header carrying authentication-relevant information that Microsoft itself treats as significant enough to sign, yet that the proposed blanket exclusion would leave unprotected. The contradiction is contained within a single artifact: the body of the message argues that this class of header lacks security relevance while the header set of that same message places one such header under cryptographic protection. The contradiction is not in the model; it is in treating the entire X-* namespace as functionally uniform when it manifestly is not.

Security Relevance of the Distinction All headers not excluded at Level 1 or Level 2 are included in the hh= computation. This is a deliberate security decision. Headers with cross-organizational or security-relevant functions carry metadata between trusted components across operator boundaries: antispam scores, phishing detection results, authenticated user identities, original envelope information, abuse complaint addresses, feedback loop tokens and compliance annotations. An attacker who can inject such a header without detection can attempt to influence downstream security decisions. Including them in hh= closes this attack surface: any undeclared addition or modification will cause the rollback check to fail at the next honest verifying hop. The position that the X-* namespace has no security implications outside the organizations that add the headers is contradicted by current production practice at four independent operators, on four continents, covering four distinct use cases: Google signs X-Original-Sender for identity preservation, Microsoft signs X-MS-Exchange-SenderADCheck for authentication result, Mailjet signs X-CSA-Complaints and X-REPORT-ABUSE-TO for abuse compliance, LinkedIn signs X-LinkedIn-fbl as a feedback loop identifier. In each case the operator has judged the header significant enough to place under cryptographic protection. The same LinkedIn message that carries the cross-organizational X-LinkedIn-fbl also carries X-LinkedIn-Class, X-LinkedIn-Template and X-LinkedIn-Id - all signed together. The first three are Level 2 (internal telemetry); the fourth is Level 3 (cross-organizational mechanism). A blanket exclusion cannot make this distinction. X-CSA-Complaints is administered by a third party (eco.de) and used cross-organization for abuse reporting. X-LinkedIn-fbl is returned by recipient providers to LinkedIn when a user marks a message as spam. A feedback loop that did not cross organizational boundaries would not be a feedback loop. If these headers have no cross-organizational security relevance, the category is empty. The IETF DKIM working group's own mailing list infrastructure adds X-Spam-Status, X-Virus-Scanned and X-Original-To to every message it processes - on infrastructure operated by participants in the same discussion that proposed excluding them. A major mailbox provider operating at global scale confirmed in working group discussion that these headers exist because multiple parties introduce them for legitimate delivery-path purposes and that they are subject to attack in practice. Body recipes do not close this gap. A recipe declares a voluntary modification. An attacker injecting a forged header has no incentive to declare it and the specification provides no mechanism to compel or detect an undeclared injection independently of hh=.

Standardization Gap The three-level model described in this section addresses a gap in the base specification. Working group discussion has surfaced proposals to introduce explicit normative tag namespaces - vendor-diagnostic prefixes and trace-field designators - that would allow the exclusion and inclusion rules to be expressed formally rather than derived from functional analysis. Until such normalization is achieved, no implementation can correctly determine which headers belong in the signed set by relying on prefix alone: the X-* namespace contains both internal diagnostic telemetry and cross-organizational security mechanisms that require opposite treatment and the same applies to other vendor-associated header conventions. The functional three-level model described in this section provides the principled basis for a future normative classification. Operators who use headers for internal trust signals between their own components MUST ensure these headers are stripped before external delivery, independently of DKIM2.

IANA Considerations Header field names defined in this profile use the DKIM2- prefix in preference to X- in accordance with . This document requests the registration of the following header fields in the Provisional Message Header Field Registry maintained by IANA in accordance with : DKIM2-Chain-Sig, DKIM2-Chain-mf, DKIM2-Chain-rt, DKIM2-Chain-Mod and DKIM2-Chain-Results. These header fields are defined by this profile and appear in messages in transit.

DKIM2-Chain-Sig

• Header field name: DKIM2-Chain-Sig
• Applicable protocol: mail
• Status: provisional
• Author/Change controller: V. Moccia
• Specification document: this document, Section 3.3.1
• Related information: carries the signature of one hop over the signed header set defined in Section 3.3.2, with the tags i=, v=, d=, s=, a=, c=, h=, bh=, b=, hh= and t=. One or more header fields are present per hop, one per signing algorithm, ordered by v=. The bh= and hh= values are computed with the hash named in a=, so they may differ between the header fields of one hop while covering the same content

DKIM2-Chain-mf

• Header field name: DKIM2-Chain-mf
• Applicable protocol: mail
• Status: provisional
• Author/Change controller: V. Moccia
• Specification document: this document, Section 3.1
• Related information: carries the SMTP MAIL FROM value bound to a DKIM2 signature at a specific hop, indexed by i=

DKIM2-Chain-rt

• Header field name: DKIM2-Chain-rt
• Applicable protocol: mail
• Status: provisional
• Author/Change controller: V. Moccia
• Specification document: this document, Section 3.1
• Related information: carries exactly one SMTP RCPT TO address per header, bound to a DKIM2 signature at a specific hop. Multiple recipients use multiple headers with incrementing v= sequence index. Indexed by i= for hop and v= for recipient sequence.

DKIM2-Chain-Mod

• Header field name: DKIM2-Chain-Mod
• Applicable protocol: mail
• Status: provisional
• Author/Change controller: V. Moccia
• Specification document: this document, Section 3.2
• Related information: declares a modification made to a header field by a Reviser node, using:
  • field= - identifies the modified header field name
  • del= - previous value, present for removals and modifications
  • new= - new value, present for additions and modifications
  • fr= - optional frame index for splitting long values across multiple headers
  • i= - hop index
  • seq= - field instance index
  • del= and new= MUST appear on separate header lines and MUST be last in the header field value

DKIM2-Chain-Results

• Header field name: DKIM2-Chain-Results
• Applicable protocol: mail
• Status: provisional
• Author/Change controller: V. Moccia
• Specification document: this document, Section 3.5.1
• Related information: records the outcome, at the hop named by i=, of verifying the chain as it arrived there, which is the signature at hop i-1. Carries i= (hop index), authserv-id (verifying MTA FQDN) and dkim2= result (pass, fail, none, neutral, temperror, permerror). One header is produced per verified hop. Part of the signed header set at every hop, cumulative from i=1 (Section 3.3.2). Excluded from the hh= computation.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This specification defines registration procedures for the message header fields used by Internet mail, HTTP, Netnews and other applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes the commonly used base 64, base 32, and base 16 encoding schemes. It also discusses the use of line-feeds in encoded data, use of padding in encoded data, use of non-alphabet characters in encoded data, use of different encoding alphabets, and canonical encodings. [STANDARDS-TRACK] Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] This document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol for "split-UA" (User Agent) mail reading systems and mobile environments. [STANDARDS-TRACK] This document specifies the Internet Message Format (IMF), a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. This specification is a revision of Request For Comments (RFC) 2822, which itself superseded Request For Comments (RFC) 822, "Standard for the Format of ARPA Internet Text Messages", updating it to reflect current practice and incorporating incremental changes that were specified in other RFCs. [STANDARDS-TRACK] This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. [STANDARDS-TRACK] This document specifies an SMTP extension for transport and delivery of email messages with internationalized email addresses or header information. [STANDARDS-TRACK] DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message. This can be an author's organization, an operational relay, or one of their agents. DKIM separates the question of the identity of the Signer of the message from the purported author of the message. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. Message transit from author to recipient is through relays that typically make no substantive change to the message content and thus preserve the DKIM signature. This memo obsoletes RFC 4871 and RFC 5672. [STANDARDS-TRACK] Historically, designers and implementers of application protocols have often distinguished between standardized and unstandardized parameters by prefixing the names of unstandardized parameters with the string "X-" or similar constructs. In practice, that convention causes more problems than it solves. Therefore, this document deprecates the convention for newly defined parameters with textual (as opposed to numerical) names in application protocols. This memo documents an Internet Best Current Practice. The Internet Message Format (RFC 5322) allows "group" syntax in some email header fields, such as "To:" and "CC:", but not in "From:" or "Sender:". This document updates RFC 5322 to relax that restriction, allowing group syntax in those latter fields, as well as in "Resent-From:" and "Resent-Sender:", in certain situations. JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. The Authenticated Received Chain (ARC) protocol provides an authenticated "chain of custody" for a message, allowing each entity that handles the message to see what entities handled it before and what the message's authentication assessment was at each step in the handling. ARC allows Internet Mail Handlers to attach assertions of message authentication assessment to individual messages. As messages traverse ARC-enabled Internet Mail Handlers, additional ARC assertions can be attached to messages to form ordered sets of ARC assertions that represent the authentication assessment at each step of the message-handling paths. ARC-enabled Internet Mail Handlers can process sets of ARC assertions to inform message disposition decisions, identify Internet Mail Handlers that might break existing authentication mechanisms, and convey original authentication assessments across trust boundaries. Informative References This memo gives a mission statement for the IETF, tries to define the terms used in the statement sufficiently to make the mission statement understandable and useful, argues why the IETF needs a mission statement, and tries to capture some of the debate that led to this point. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Full use of electronic mail throughout the world requires that (subject to other constraints) people be able to use close variations on their own names (written correctly in their own languages and scripts) as mailbox names in email addresses. This document introduces a series of specifications that define mechanisms and protocol extensions needed to fully support internationalized email addresses. These changes include an SMTP extension and extension of email header syntax to accommodate UTF-8 data. The document set also includes discussion of key assumptions and issues in deploying fully internationalized email. This document is a replacement for RFC 4952; it reflects additional issues identified since that document was published. [STANDARDS-TRACK] Internet mail was originally limited to 7-bit ASCII. MIME added support for the use of 8-bit character sets in body parts, and also defined an encoded-word construct so other character sets could be used in certain header field values. However, full internationalization of electronic mail requires additional enhancements to allow the use of Unicode, including characters outside the ASCII repertoire, in mail addresses as well as direct use of Unicode in header fields like "From:", "To:", and "Subject:", without requiring the use of complex encoded-word constructs. This document specifies an enhancement to the Internet Message Format and to MIME that allows use of Unicode in mail addresses and most header field content. This specification updates Section 6.4 of RFC 2045 to eliminate the restriction prohibiting the use of non-identity content-transfer- encodings on subtypes of "message/". [STANDARDS-TRACK] This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. This document specifies a message header field called "Authentication-Results" for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), can use this header field to relay that information in a convenient and meaningful way to users or to make sorting and filtering decisions. This document obsoletes RFC 7601. This second document defines the general structure of the MIME media typing system and defines an initial set of media types. [STANDARDS-TRACK] The cryptographic algorithm and key size requirements included when DomainKeys Identified Mail (DKIM) was designed a decade ago are functionally obsolete and in need of immediate revision. This document updates DKIM requirements to those minimally suitable for operation with currently specified algorithms. This document describes the Domain-based Message Authentication, Reporting, and Conformance (DMARC) protocol. DMARC permits the owner of an email's Author Domain to enable validation of the domain's use to indicate the Domain Owner's or Public Suffix Operator's message handling preference regarding failed validation and to request reports about the use of the domain name. Mail-receiving organizations can use this information when evaluating handling choices for incoming mail. This document obsoletes RFCs 7489 and 9091. Google The updated DomainKeys Identified Mail (DKIM2) permits an organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message through a digital signature. This is done by publishing to Domain Name Service (DNS) of the domain a public key that is then associated to the domain and where messages can be signed by the corresponding private key. Assertion of responsibility is validated through a cryptographic signature and by querying the Signer's domain directly to retrieve the appropriate public key. This document describes DKIM2 DNS record format and how to find the record. Over its thirty-five-year history, Internet Mail has changed significantly in scale and complexity, as it has become a global infrastructure service. These changes have been evolutionary, rather than revolutionary, reflecting a strong desire to preserve both its installed base and its usefulness. To collaborate productively on this large and complex system, all participants need to work from a common view of it and use a common language to describe its components and the interactions among them. But the many differences in perspective currently make it difficult to know exactly what another participant means. To serve as the necessary common frame of reference, this document describes the enhanced Internet Mail architecture, reflecting the current service. This memo provides information for the Internet community. This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content. European Union European Union

Implementation Notes (Informative)

DKIM2-Chain-Mod Header Representation A DKIM2-Chain-Mod header declaration maps directly to a simple flat data structure. The following Go example illustrates a complete representation: Note: the ModificationType function treats empty string as absence of the tag, which is consistent with the ABNF definition dkim2-chain-mod-value = DQUOTE 1*dkim2-chain-mod-octet DQUOTE that requires at least one octet between the delimiters. A del= or new= tag with an empty value is not valid per the grammar and MUST be rejected by parsers. The "invalid" return value covers this case and any other combination where both DelValue and NewValue are empty. All fields are primitive types. No JSON parser, no base64 decoder, no recursive structures. The complete state for a hop can be built by iterating the message headers once in O(n) time with O(1) memory per header.

Comparison: DKIM2-Chain-Mod vs JSON Header Recipe Encoding The current DKIM2 specification encodes header modifications as JSON inside the Message-Instance header. The following is a real example from a working implementation demonstrated during the development of this specification. The r= field decoded from base64 contains: This structure is not directly readable in mail logs - it requires base64 decoding followed by JSON parsing before any field can be inspected. The equivalent declaration using DKIM2-Chain-Mod headers: " DKIM2-Chain-Mod: i=2; seq=1; field=Precedence; new="list" ]]> The Go data structures required for each approach illustrate the implementation complexity difference: The DKIM2-Chain-Mod approach requires only the tag-value parser already present in every DKIM1 and ARC implementation. The JSON recipe approach requires base64 decoding, JSON unmarshaling with dynamic type handling and resource limit enforcement as discussed in Sections 4.4.1 and 8.3.1. The motivation offered for JSON encoding is that it handles arbitrary values without an escaping convention. That motivation does not distinguish the two encodings, because the base specification has already solved the same problem inside tag-value: it records envelope addresses as base64 within tag-value header fields. A document that accepts base64 within tag-value for envelope addresses cannot cite escaping as the reason to leave tag-value for header modifications. The comparison also overstates what the structure is required to express. A header modification is a flat tuple of a field name, a removed value and an added value. It contains no nesting, no arrays of arrays and no heterogeneous value types. The structural capability of JSON is therefore unused, while its costs are paid in full: dynamic typing, undefined behavior on duplicate keys, divergence between parser implementations and the case-sensitivity problem described below. In the encoding defined here no escaping convention is required at all. The del= and new= values are delimited positionally rather than by a scanned terminator and the value between the delimiters is carried as octets, as specified in Section 3.8. An interior double quote is therefore never interpreted and no character requires substitution. The only octets the encoding excludes are those that a header field value cannot contain under the current syntax of . The use of JSON as the recipe encoding format also introduces a class of normative ambiguity that the email ecosystem had already resolved decades ago. RFC 5322 defines header field name matching as case-insensitive - this property has been part of the email stack since its inception and applies to both body recipes and header recipes. By embedding header field names as JSON object keys, DKIM2-extended recreates this problem from scratch: JSON is case-sensitive by specification, so "Content-Type" and "content-type" are distinct keys, yet email header field names are case-insensitive by protocol. The working group found itself in 2026 debating whether to mandate lowercase, uppercase or case-insensitive matching for header field names inside JSON recipe objects - a problem that RFC 5322 resolved in 1982. The practical consequence emerged immediately in interoperability testing: one implementation generated recipes preserving the original header field case, a second implementation expected strictly lowercase keys and rejected mixed case as invalid. Both behaviours were defensible under the specification text as written. The specification has since added text stating that header field names in the JSON keys are matched without regard to case and that the keys themselves MUST be in lower case and unique within any JSON object. This is not an edge case discovered by adversarial testing - it is a divergence between implementations that were each attempting to conform to the same text. The tag-value encoding had a divergence of its own, with three treatments of the trailing semicolon in circulation across the document set. That divergence arose from the proliferation of documents rather than from the encoding and its remedy was a single generic definition referenced by each document. That is the course the documents have taken: the debug header proposal now takes the production from the base specification by reference instead of restating it. The JSON case is different in kind. A case can be named in the text and settled there, as forbidding duplicate keys settles one of them, but settling it moves the burden to each implementation's conformance, which the message does not reveal. Some of the divergences are properties of the parsing libraries rather than of the grammar, as the report recorded in Section 4.4.2 shows. No requirement in a specification changes what a deployed library emits. What text can do is define which resolution applies wherever more than one is conformant, so that the next case is settled before it is found in deployment rather than after.

Milter Implementation Notes (Informative) The following describes the milter callback structure for a DKIM2-core implementation. The structure demonstrates that all mandatory DKIM2-core functionality is expressible within the standard milter interface without MTA core modifications. DKIM2-core requires two separate milter instances: an inbound milter for verification and an outbound milter for signing, positioned respectively first and last in the milter chain.

Inbound milter - verification path dk2_connect, dk2_helo - connection-level callbacks. No DKIM2-specific processing. dk2_envfrom - initializes the per-session private structure and resets all hash contexts and header reservoirs. Stores the MAIL FROM value for later verification against DKIM2-Chain-mf. On connection reuse (RSET), resets all per-message state without freeing the allocated structures. dk2_envrcpt - called once per recipient. Appends each RCPT TO value to a per-session list for later verification against DKIM2-Chain-rt headers. dk2_header - called once per header field. Accumulates each field in a dynamically allocated in-memory reservoir with DoS protection via a configurable maximum header count and a limit on total header memory. Includes removal of other spoofed internal headers arriving from external sources. When fr= fragmentation tags are present in DKIM2-Chain-Mod headers, accumulates fragments for reassembly at dk2_eom. dk2_eoh - end of headers. For RSA-SHA256 implementations MAY initiate DNS key lookup as an optimization, reducing the time spent waiting at dk2_eom. Signing algorithms that require the complete input before verification, including Ed25519-SHA256 and future elliptic curve algorithms, defer all operations to dk2_eom. dk2_body - called in chunks as the body arrives. Updates the body hash incrementally using relaxed or simple canonicalization as specified in the signature. This streaming approach means the milter never holds the message body in memory - only the hash context state is updated at each chunk. A message of arbitrary size imposes no additional memory cost beyond the fixed hash context. dk2_eom - finalizes the body hash, fetches the public key via DNS, reconstructs the signed header input from the reservoir, adds the incomplete DKIM2-Chain-Sig header to the signed input, verifies the signature, checks DKIM2-Chain-mf against the stored MAIL FROM and checks each stored RCPT TO against a corresponding DKIM2-Chain-rt header. Verifies that each DKIM2-Chain-Mod declaration accurately reflects the modification declared at that hop. Returns SMFIS_REJECT for structural failures or when cryptographic proof of dishonesty is present per Section 3.5.2, SMFIS_TEMPFAIL on transient DNS error and SMFIS_CONTINUE otherwise, with the result recorded in DKIM2-Chain-Results. dk2_abort, dk2_close - release all per-session resources including the header reservoir and hash contexts.

Outbound milter - signing path dk2_connect, dk2_helo - connection-level callbacks. No DKIM2-specific processing. dk2_envfrom - initializes the per-session private structure. Stores the MAIL FROM value for construction of DKIM2-Chain-mf. dk2_envrcpt - called once per recipient. Appends each RCPT TO value to a per-session list for construction of DKIM2-Chain-rt headers. dk2_header - called once per header field. Accumulates the field in the reservoir. For RSA-SHA256 implementations, simultaneously updates the signed header digest incrementally, allowing a single-pass streaming implementation. Signing algorithms that require the complete input before signing, including Ed25519-SHA256 and future elliptic curve algorithms, accumulate only in the reservoir and reconstruct the signed header input in dk2_eom. dk2_eoh - no DKIM2-specific processing for the outbound path. dk2_body - called in chunks. Updates the body hash incrementally using relaxed or simple canonicalization as specified in the signature. This streaming approach means the milter never holds the message body in memory - only the hash context state is updated at each chunk. A message of arbitrary size imposes no additional memory cost beyond the fixed hash context. dk2_eom - Finalizes the body hash, constructs DKIM2-Chain-mf with i= and addr= from the MAIL FROM value, constructs one DKIM2-Chain-rt per stored RCPT TO with incrementing v= values, validates any DKIM2-Chain-Mod headers present, adds the incomplete DKIM2-Chain-Sig header to the digest, finalizes and signs, then adds the complete DKIM2-Chain-Sig to the message. For signing algorithms that require the complete input before signing, including Ed25519-SHA256 and future elliptic curve algorithms, the complete signed header input is constructed from the reservoir at this stage and signed in a single operation. dk2_abort, dk2_close - release all per-session resources.

Stateless design confirmation Both milter instances are fully stateless between sessions. The private structure allocated at dk2_connect carries the complete session state - envelope values, header reservoir and hash contexts - and is released at dk2_close. No shared storage between milter instances or between sessions is required at any point. No MTA core modifications are required. DKIM2-core header and body processing is fully streaming - no message content is buffered at any point. The header reservoir holds only header field names and values, not body content. This is a fundamental architectural difference from DKIM2-extended, which requires buffering body content for recipe generation.

Acknowledgements The author would like to thank the participants of the IETF-DKIM mailing list for the rigorous technical exchange that motivated this document. Special thanks to Pete Resnick for his guidance on the IETF process, for encouraging the formalization of these concerns into an Internet-Draft and for clarifying the process by which any contributor may address the architectural and security implications of proposed standards. The author acknowledges Wei Chuang for his independent convergence on the importance of human-readable envelope binding fields and Bron Gondwana for the extensive debate regarding stateful delivery models. Valuable perspectives were provided by Philip Guenther on security gateway deployment requirements and by Steffen Nurpmeso on architectural simplification and attack surface reduction. Hannah Stern contributed detailed technical observations on base64 encoding complexity and recipe streaming limitations and on the canonicalization limits of recipe reconstruction. John Levine and Richard Clayton are thanked for their participation in the working group discussion. R. Latimer is thanked for raising the perspective of MTA implementers and for drawing attention to the Alternate Submission Scenarios. Murray Kucherawy is thanked for his clarification on the scope of interface-level implementability in IETF protocol design.