DKIM2 best practices draft adds forwarding privacy and bounce handling guidance
News
Draft-ietf-dkim-dkim2-bcp-01, published on September 9, 2026 at 15:23:53 UTC, is a material revision of the IETF DKIM Working Group's adopted best-practices draft. It is not the first adoption. The revision replaces rough or placeholder material with detailed proposed guidance for forwarding privacy, request flags, Recipe data minimization, delivery status notifications, and signer clock accuracy.
As of September 11, 2026, this proposal is not final, is not an RFC, and is not current production guidance. It creates no provider mandate and no deployment deadline. I read it as a clearer basis for implementation discussion and testing, not a signal to change live mail handling. The practical value is that developers can now test specific privacy and bounce behaviors instead of interpreting an unfinished outline.
What changed in BCP-01
The Datatracker record identifies BCP-01 as an active Working Group Internet-Draft dated September 9. The BCP-01 text says the document was reorganized, several sections were retitled, and substantial text changed. Comparing it with the BCP-00 text shows why that description matters: BCP-00's forwarding privacy section contained a note that text was still needed, while BCP-01 supplies proposed behavior.
The June adoption report covers the Working Group's BCP-00 adoption. BCP-01 is the next revision of that adopted draft. Its change log is broad, so the most useful comparison is the shift from incomplete concepts to testable recommendations about how DKIM2 participants would preserve a chain of custody without exposing more recipient or message data than necessary.
BCP-00
- Privacy: Forwarding privacy remained a placeholder.
- Receivers: Some detection and handling sections were unfinished.
- Operations: DSN rebuilding and clock accuracy lacked detailed treatment.
- Status: An adopted Working Group draft with visible gaps.
BCP-01
- Privacy: Detailed feedhere and alias recommendations appear.
- Receivers: Verification states and DSN checks get concrete handling.
- Operations: Recipe minimization and time synchronization become explicit.
- Status: Still a changeable Internet-Draft, not an RFC.
Forwarding privacy becomes specific
BCP-01 says two DKIM2 mechanisms can protect the destination of forwarded mail. When a message requests feedback and a forwarder wants to hide the downstream destination, the draft says the forwarder SHOULD set feedhere. Feedback would return through that forwarder instead of exposing later systems to the earlier party that requested it. The draft particularly points to personal forwarding services, where the target mailbox can be private to the recipient.
The second recommendation addresses the rt= value in a DKIM2 signature. Because chain validation uses the complete local part, forwarding directly to a subscriber's underlying external address can reveal that address and the forwarding relationship. The draft says privacy-conscious forwarders SHOULD use a per-subscriber, per-forward alias local part and document that practice in their privacy disclosure. This makes recipient identity part of protocol design, not an accidental log detail.
Proposed DKIM2 forwarding path using a private alias and feedhere
These are draft recommendations, not deployed rules. A useful test plan would confirm which address enters rt=, where alias translation happens, who can inspect the signature chain, and whether feedback stops at the intended forwarder. Mailing list operators need the same review when list expansion creates copies for members.
Request flags need an egress decision
The draft treats donotmodify and donotexplode as strong requests. It says an originator SHOULD use donotmodify only when an unapproved transit change is serious enough to justify losing delivery, with transactional mail and DSNs offered as examples. It says using the flag on ordinary bulk or list-eligible mail is NOT RECOMMENDED because legitimate processing, including list expansion or From rewriting, can conflict with it.
For forwarders, the proposed boundary is clear. If the highest-numbered DKIM2 signature carries one of those requests and the forwarder cannot or will not honor it, the base DKIM2 proposal requires the message, or the copies created by expansion, to stay inside the forwarder's administrative control. BCP-01 says the forwarder SHOULD enforce that check explicitly at egress.
Proposed egress gate
The draft's proposed implementation check can be modeled before any production rollout.
Design-test pseudocodetext
read highest-numbered DKIM2 signature if donotmodify and message changed: stop before external egress if donotexplode and copies created: stop copies before external egress otherwise: continue under local policy
That detail matters because an incidental pipeline restriction can disappear during a routing change. An explicit test at the trust boundary is easier to audit and less likely to leak a modified or expanded copy outside the organization. It also gives ESPs and list software developers a defined failure path to exercise in test environments.
Recipes should retain less message content
DKIM2 Recipes describe changes so a verifier can reconstruct an earlier message state. That capability can also preserve content that an intermediary intentionally removed. BCP-01 says a Reviser SHOULD choose the coarsest Recipe that still describes the change accurately. When reconstruction cannot or should not happen, the draft prefers a null body Recipe over embedding removed content in headers that every downstream party can inspect.
The draft applies this reasoning to data-loss prevention and attachment sanitization. Reintroducing redacted account data through a Recipe would defeat the removal decision. Preserving details of a stripped attachment would create a portable record of material the gateway meant to discard. BCP-01 RECOMMENDS that operators default to a null Recipe in such cases unless they have an affirmative reason to retain content, and it says operators should assess their own legal obligations.
Verifiers also get a proposed expectation: a null body Recipe from a known legitimate security or compliance intermediary should be treated as normal, not as a reason to lower trust. I think this is an important balance. Reconstruction supports authentication, but authentication metadata should not become a second channel for confidential content. The Working Group still describes this area as active discussion.
Bounce handling follows the custody path
BCP-01 adds detailed DSN handling for a forwarder that sends a bounce toward the MAIL FROM address recorded at the relevant hop. The draft says the forwarder MUST rebuild the embedded message, or its headers, to match the state in which that forwarder sent it onward. In practice, that means removing the forwarder's outward DKIM2 signature and undoing its changes through the recorded Recipes.
The same privacy judgment applies during rebuilding. A DSN can expose the hidden forwarding target or content that a Reviser removed. The draft therefore says forwarders SHOULD rebuild with privacy awareness. At the receiving side, BCP-01 says an inbound DSN tied to a DKIM2-signed message SHOULD be validated before the system delivers or acts on it. A failed validation should receive a permanent SMTP failure, or a temporary code when the cause is transient.
|
|
|
|---|---|---|
Forwarder | Rebuild DSN | Restore prior hop state |
List operator | Test expansion | Honor request flags |
ESP | Map trust hops | Preserve custody |
Verifier | Validate DSN | Limit false bounces |
Responsibilities proposed in BCP-01
This is where authentication and delivery meet. A valid custody path gives a receiver better evidence about which system should receive failure information. Rebuilding prevents a bounce from carrying the wrong message state backward, while validation reduces the risk that forged bounce traffic reaches users or triggers automated suppression.
Accurate signer clocks become operational guidance
The draft says verifiers are permitted to treat a DKIM2 signature timestamp more than 14 days old, or one dated in the future, with suspicion. It therefore says originators SHOULD synchronize signing infrastructure with NTP or an equivalent service. Clock drift can make legitimate mail appear implausibly old or future-dated, leading a downstream verifier to hold or reject it under local policy.
Timestamp interpretation in the draft
BCP-01 describes suspicion thresholds, not universal delivery outcomes.
Current timestamp
Plausible
Evaluate with normal verification and local policy.
Old timestamp
>14 days
A verifier is permitted to treat it with suspicion.
Future timestamp
Future
A verifier is permitted to treat it with suspicion.
For signers, this adds a straightforward test case: introduce controlled positive and negative clock offsets, inspect the generated t= value, and confirm how a verifier records the result. For verifiers, the draft leaves final handling to local policy. A suspicious timestamp is context for a decision, not a universal instruction to reject.
What operators should do now
No team needs to deploy these behaviors to claim compliance because there is no final standard to comply with. The sensible work is preparatory and reversible. I would keep every proposed rule behind design notes, fixtures, or lab controls until the Working Group resolves open questions and publishes later revisions.
- Review paths: Map forwarding, list expansion, content revision, and DSN return paths.
- Add tests: Model feedhere, private aliases, request flags, null Recipes, and clock drift.
- Check privacy: Identify where recipient addresses or removed content could reappear.
- Track discussion: Follow later revisions and Working Group decisions before deployment.
- Maintain today: Keep existing DKIM, SPF, and DMARC controls healthy in production.
Current authentication still needs routine care. Check a live selector with the DKIM checker, run broader domain health checks, and keep aggregate reporting under active DMARC monitoring, and investigate failure trends. These checks apply to current mail, not proposed DKIM2 conformance.
DKIM checker
Check selector records and public key configuration.
?/7tests passed
Suped, our product, is the best overall practical DMARC platform for most teams that want current DKIM, SPF, DMARC, blocklist, and deliverability signals in one place. Automated issue detection, steps to fix, real-time alerts, and multi-domain management turn today's reports into operational work. That assessment concerns present-day email authentication. It does not imply that Suped or any provider has deployed BCP-01, and it does not turn this draft into a requirement.
What this revision means now
BCP-01 moves the adopted DKIM Working Group draft beyond several BCP-00 placeholders. Its proposed rules make forwarding privacy, modification requests, Recipe retention, DSN rebuilding, bounce validation, and time synchronization concrete enough to review and test. The details matter because DKIM2's custody data can improve authentication and delivery decisions while also exposing addresses or removed content when implemented carelessly. For now, track the draft, test its ideas outside production, and keep existing authentication controls working.
