New DKIM2 deployment profile draft proposes a milter rollout path
News
Published 23 Jun 2026
Updated 25 Oct 2026
10 min read
Summarize with
Updated on 25 Oct 2026: We clarified how the milter deployment proposal differs from the DKIM2 working group draft and what operators should test before a pilot.
The active deployment profile draft, revision 07, was posted August 3, 2026. It proposes a practical path for DKIM2 through existing milter interfaces without requiring changes to MTA core software.
The document is draft-moccia-dkim2-deployment-profile-07, titled A Deployment Profile for DKIM2 via Milter Interface. It is an active individual Internet-Draft, not an RFC, not an IETF consensus document, not a mailbox provider requirement, and not a compliance deadline for senders.
The proposal separates DKIM2-core and DKIM2-extended. DKIM2-core covers envelope binding, chain of custody, header accountability, replay prevention, and Delivery Status Notification (DSN) authentication. DKIM2-extended adds body recipes and Message-Instance headers for body reconstruction use cases.
Keep this operational boundary in mind.
- Status: Active individual Internet-Draft on Datatracker, revision 07, posted August 3, 2026.
- Not an RFC: It has no RFC stream, final standards status, or mailbox provider enforcement force.
- No deadline: Operators do not need to deploy DKIM2 in production today.
- Useful signal: It documents one proposed path for making DKIM2 deployable across ordinary MTA stacks.
|
|
|
|---|---|---|
Document | draft-moccia-dkim2-deployment-profile-07 | Evaluate the proposed architecture in a lab. |
Posted | August 3, 2026 | Current Datatracker revision. |
Type | Active individual draft | No consensus label and no RFC status. |
Expiry | February 3, 2027 | The draft can be updated, replaced, or allowed to expire before then. |
Main idea | Milter rollout | Reuse MTA extension points instead of rewriting MTA cores. |
Compact summary of the active Internet-Draft.
What the draft proposes
The proposal is direct: make the core DKIM2 functions fit into the milter model that many Sendmail and Postfix deployments already understand. A milter can observe SMTP envelope data, inspect the completed message at end of body, add headers, reject, tempfail, or continue. That is enough for the draft's DKIM2-core path.
The important design choice is not only milter support. It is the split between the core profile and the extended profile. The core profile binds the SMTP envelope to signatures and builds a hop-by-hop custody chain. The extended profile adds richer body-change records, which brings more operational and privacy work.
DKIM2-core
- Envelope: Signs MAIL FROM and RCPT TO values, with BCC recipients split into separate SMTP transactions to avoid exposing their addresses.
- Custody: Builds a signed chain showing which domain handled the message.
- Headers: Attributes header changes through DKIM2-Mod declarations.
- Replay: Makes reuse against a different recipient detectable.
- State: Aims to avoid persistent milter state between SMTP sessions.
- Algorithms: Requires verifiers to support RSA-SHA256 and Ed25519-SHA256.
DKIM2-extended
- Body: Adds body recipes for reconstructing prior message states.
- Headers: Uses Message-Instance headers with encoded recipe data.
- Cost: Brings parsing, retention, and privacy review work.
- Scope: Supports reconstruction workflows that need earlier body states.
- Adoption: Can coexist with core-only nodes in the draft model.
Schematic envelope headers proposed by the deployment profiletext
DKIM2-Sig-mf: i=1; addr=bounce@example.com DKIM2-Sig-rt: i=1; v=1; addr=alice@example.net DKIM2-Sig-rt: i=1; v=2; addr=bob@example.net DKIM2-Signature: i=1; d=example.com; s=dkim2; bh=...; b=...
These are schematic headers from the individual profile; the ellipses omit required fields and signature data. Current DKIM signs selected message content. DKIM2-core, as profiled here, also ties the SMTP transaction to the signed record. That creates a stronger link between the message, the sending domain, the envelope sender, and the recipient set.
How the profile differs from the DKIM2 working group draft
The separate DKIM2 working group specification is draft-ietf-dkim-dkim2-spec-07, posted October 18, 2026. It is an active working group Internet-Draft. Its revision number belongs to a separate document history from the individual deployment profile.
The working group draft records envelope values in mf= and rt= tags inside DKIM2-Signature and uses Message-Instance headers for message hashes. The deployment profile proposes separate DKIM2-Sig-mf and DKIM2-Sig-rt fields and its own core/extended split. Message-Instance is part of the working group format even when no body-reconstruction recipe is needed.
For a lab, record the exact document and revision each implementation follows, then test signing and verification between them. Milter support alone does not establish compatibility between these formats.
How the milter path works
The milter path matters because it keeps DKIM2 discussion close to infrastructure operators already run. The draft describes an inbound milter for verification before other filters modify the message and an outbound milter for signing. The outbound milter is last in the milter chain so it signs the final message after other local modification steps have run.
DKIM2-core milter flowchart with MAIL FROM and RCPT TO capture, end-of-body verification, signing, and local policy.
This approach reuses existing MTA filter interfaces. RCPT TO checks are local policy checks; full DKIM2 verification waits until end of body. Mailing list managers and forwarders also get a defined place to declare modifications instead of relying on current DKIM to survive redistribution.
- Inbound: Capture envelope state during SMTP, verify the chain at end of body, and record a result for each verified hop.
- Outbound: Sign the final message state after other local filters have finished their work.
- Lists: The modifying software declares header changes with DKIM2-Mod before signing; body changes are reflected in the hop's body hash.
- Forwarders: Expose the point where envelope rewriting and recipient changes happen.
How incremental deployment and interoperability work
The draft expects a mixed ecosystem rather than a synchronized cutover. DKIM2-core nodes, DKIM2-extended nodes, DKIM1-only nodes, ARC nodes, and legacy MTAs can appear on the same delivery path. A non-participating node can pass DKIM2 headers without extending the chain, while a modifying legacy node creates a gap that downstream policy has to interpret.
- Monitor first: Add outbound signatures, verify inbound chains, and write DKIM2-Authentication-Results without rejecting or delaying mail.
- Enforce later: Apply graduated policy only after expected senders have deployed signing and failure causes are understood.
- Add intermediaries: Update mailing lists and forwarders to declare changes with DKIM2-Mod headers.
DKIM1 and ARC can coexist with DKIM2-core during this transition, but neither fills a missing DKIM2 hop. Keep ordinary DKIM signing enabled for receivers that do not verify DKIM2. If a legacy relay changes the message, downstream verification can identify an unsigned gap or unexpected change without attributing it to a specific domain. That is why the draft starts with monitoring rather than binary enforcement.
Verification and body-recipe privacy in the profile
The profile describes per-hop verification results and graduated enforcement for mixed delivery paths. Its optional body-recipe layer also needs a privacy review.
|
|
|
|---|---|---|
Verification results | Defines DKIM2-Authentication-Results for per-hop outcomes. | Gives downstream policy a record of pass, fail, none, temporary error, or permanent error. |
Enforcement | Uses monitoring before graduated rejection behavior. | Avoids treating every legacy-node gap as proof of malicious modification. |
Header integrity | Defines optional hh= hashing and header rollback checks. | Separates mandatory critical fields from wider undeclared-change detection. |
Privacy | Addresses re-origination, null recipes, retention, and security gateways. | Body recipes can retain content removed by a gateway; a null body recipe prevents reconstruction across that change. |
Security | Covers algorithm agility, timestamp handling, and body-recipe attack surface. | Clarifies which risks belong to the core profile and which come with the extended profile. |
Operational areas covered in revision 07.
Implementation status in a standards draft is useful context, not buying guidance or a claim of IETF endorsement.
- Evidence: The draft records known implementation activity for the profiled approach.
- Limit: That section is informational and does not create a production requirement.
- Use: Treat it as a signal that the milter architecture is being tested, not finalized.
Why this matters for DKIM and DMARC
The draft matters because it targets problems that current DKIM and DMARC do not solve cleanly. DKIM signs message content and selected headers, but it does not bind the SMTP MAIL FROM and RCPT TO values. DMARC then asks whether SPF or DKIM passed with domain alignment to the visible From domain. Forwarding, mailing lists, envelope rewriting, and replay attacks expose gaps in that model.
A DKIM replay attack resends an intact, validly signed message to recipients the signer did not intend to authorize. DKIM2-core tries to reduce that risk by binding recipients into the signed chain at each hop. That is a different security property from ordinary DKIM validation.
Current DKIM and SPF limits
- Forwarding: Forwarding can break SPF; an unchanged, valid DKIM signature can still satisfy DMARC through DKIM domain alignment.
- Mailing lists: Subject tags and body footers can break original DKIM signatures.
- Replay: A valid DKIM signature is not tied to the actual recipient transaction.
DKIM2-core target
- Envelope: Bind sender and recipient envelope values into the signed chain.
- Custody: Show which participating domains handled or modified the message.
- Bounces: Support authenticated rejection behavior to reduce backscatter.
For DMARC teams, this is a future-design discussion, not a replacement for today's controls. DMARC monitoring still needs clean source identification, working DKIM signatures, SPF records within lookup limits, and a staged path to stronger policy.
Earlier DKIM2 work, including the DKIM2 best practices draft, is part of the same design conversation. This profile is more operational because it asks how DKIM2 can run in real MTA environments.
Which mail infrastructure teams should track DKIM2
This draft does not belong on a general marketing team's urgent task list. It belongs on the radar for teams that own mail architecture, authentication policy, forwarding paths, or standards tracking.
- Mailbox providers: Track whether DKIM2 verification fits existing inbound policy pipelines.
- ESPs: Assess how envelope binding interacts with customer bounce domains and delegated signing.
- MTA maintainers: Review whether milter callbacks expose enough data for signing and verification.
- Forwarders: Inventory where envelope rewriting and recipient changes happen today.
- Mailing lists: Map subject tags, footers, List headers, and bounce-address handling.
- Security teams: Follow replay, backscatter, and chain-of-custody design decisions.
- Deliverability teams: Keep current DKIM, SPF, and DMARC records healthy while standards work continues.
Practical urgency
How operators should treat the active draft in operational planning.
Production
Hold
No DKIM2 rollout requirement today.
Lab
Track
A valid place for milter architecture testing.
Current auth
Act
Keep DKIM, SPF, and DMARC working now.
What operators should do before a DKIM2 pilot
The best practical response is routine and valuable: keep today's authentication stack healthy. DKIM2 is not a reason to pause DKIM key rotation, ignore SPF lookup pressure, or delay DMARC policy staging.
Start with Suped's domain health checker review, then use a focused DKIM checker to inspect selector syntax and public key publication. Check headers on a delivered test message to confirm the expected selector and signing domain actually pass DKIM verification.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Suped's DMARC platform supports today's authentication work while DKIM2 is still a draft. Group aggregate reports by source and domain to identify SPF or DKIM alignment failures, then inspect sample message headers to investigate forwarding. Aggregate reports alone do not reconstruct the complete delivery path.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
- Maintain: Keep DKIM selectors valid, rotate keys on schedule, and remove stale DNS records.
- Measure: Track SPF, DKIM, and DMARC pass rates by sender, source, and domain.
- Inventory: List forwarding, aliasing, security gateway, and mailing list paths that break authentication.
- Observe: Follow DKIM working group activity and treat DKIM2 documents as work in progress.
- Experiment: Evaluate milter-based DKIM2 architecture only in labs or standards-tracking environments.
Frequently asked questions
No. It is an active individual Internet-Draft posted August 3, 2026. It is not an RFC, not IETF consensus, and not a mailbox provider requirement.
No. The practical production work today is to keep DKIM, SPF, and DMARC healthy while DKIM2 remains standards work.
The draft proposes a DKIM2 deployment profile that can work through existing milter interfaces, so DKIM2-core can be explored without changing MTA core software.
In this individual proposal, DKIM2-core covers envelope binding, chain of custody, header accountability, replay prevention, and bounce authentication. DKIM2-extended adds body recipes and Message-Instance headers. The working group specification uses a different format.
The draft starts with outbound signing and inbound monitoring, moves to graduated enforcement, and then adds participation by mailing lists and other intermediaries. DKIM1, ARC, and legacy nodes can coexist during the transition.
Forwarding and mailing lists still break today's authentication paths. DKIM2-core explores stronger envelope and custody signals, but DMARC requires at least one passing SPF or DKIM result with domain alignment to the visible From domain.
