New DKIM2 deployment profile draft proposes a milter rollout path
News
Published 23 Jun 2026
Updated 23 Jun 2026
9 min read
Summarize with
The June 22, 2026 revision of deployment profile draft proposes a practical path for DKIM2 through existing milter interfaces, without requiring changes to MTA core software.
I would put this in the standards-tracking bucket, not the production-change bucket. The document is draft-moccia-dkim2-deployment-profile-05, titled A Deployment Profile for DKIM2 via Milter Interface. It is an individual Internet-Draft, not an RFC, not IETF consensus, not a mailbox provider requirement, and not a compliance deadline for senders.
The substance matters because it draws a deployment line between DKIM2-core and DKIM2-extended. DKIM2-core covers envelope binding, chain of custody, header accountability, replay prevention, and DSN or bounce authentication. DKIM2-extended adds body recipes and Message-Instance headers for body reconstruction use cases.
This is the operational boundary I would keep in mind today.
- Status: Individual Internet-Draft, active on Datatracker, updated June 22, 2026.
- Not an RFC: It has no final standards status and no mailbox provider enforcement force.
- No deadline: Operators do not need to deploy DKIM2 in production today.
- Useful signal: It shows one serious path for making DKIM2 deployable across ordinary MTA stacks.
|
|
|
|---|---|---|
Document | draft-moccia-dkim2-deployment-profile-05 | Standards tracking, not production work. |
Date | June 22, 2026 | A fresh revision, one day before this news post. |
Type | Individual draft | No consensus label and no RFC status. |
Main idea | Milter rollout | Reuse MTA extension points instead of rewriting MTA cores. |
Compact summary of the June 22, 2026 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 at each participating hop.
- 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.
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: Fits forensic and compliance workflows more than ordinary delivery.
- Adoption: Can coexist with core-only nodes in the draft model.
Illustrative DKIM2-core envelope headerstext
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=...
That small header sketch shows why the proposal is interesting. 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 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 and an outbound milter for signing. The outbound milter sits late in the milter chain so it signs the final message after other local modification steps have run.
Flowchart showing how a DKIM2-core milter captures envelope data, verifies a chain, signs, and applies policy.
I see three practical reasons this approach will get attention. First, it does not assume every operator can change MTA internals. Second, it lets verification run after the complete message is available. Third, it gives mailing list managers and forwarders a clearer place to declare their modifications instead of hoping current DKIM survives redistribution.
- Inbound: Capture envelope state during SMTP and verify the DKIM2 chain at end of body.
- Outbound: Sign the final message state after other local filters have finished their work.
- Lists: Declare header and body changes instead of silently breaking the custody chain.
- Forwarders: Expose the point where envelope rewriting and recipient changes happen.
What changed in the June revision
The June 22 revision is a material update over the previous version. It does more than tidy wording. The new draft adds and reworks deployment, privacy, implementation, and security material that changes how I would brief an operator tracking DKIM2.
|
|
|
|---|---|---|
Synthetic hops | Adds intra-ADMD signing treatment. | Covers cases where multiple signatures happen inside one administrative domain. |
Privacy | Adds privacy-preserving re-origination. | Lets intermediaries terminate a chain when privacy goals require a new message origin. |
Implementation | Adds implementation status material. | Shows informational running-code evidence without making it a recommendation. |
Security | Expands core and extended risk discussion. | Separates envelope-binding benefits from body-recipe attack surface. |
Deployment | Adds more transition detail. | Makes the staged milter model easier to evaluate in a lab. |
Areas expanded or reworked in draft 05.
Implementation status in a standards draft is useful context, not buying guidance and not 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 envelope or the recipient list. DMARC then asks whether SPF or DKIM passed with the visible From domain. Forwarding, mailing lists, envelope rewriting, and replay attacks expose gaps in that model.
Replay is the clearest security issue. A valid DKIM-signed message can be resent in a context the signer did not intend. 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 pain
- Forwarding: Envelope changes can break SPF domain matching while DKIM remains hard to interpret.
- Mailing lists: Subject tags, footers, and list headers 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 new profile is more operational because it asks how DKIM2 can run in real MTA environments.
Who should pay attention
I would not put this draft on a general marketing team's urgent task list. I would put it on the radar for teams that own mail architecture, authentication policy, forwarding paths, and 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 I would treat the draft in operational planning on June 23, 2026.
Production
Hold
No DKIM2 rollout requirement today.
Lab
Track
Valid place for milter architecture testing.
Current auth
Act
Keep DKIM, SPF, and DMARC working now.
Practical next steps now
The best practical response is boring 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 a broad domain health checker review, then use a focused DKIM checker when you need to inspect selector syntax, public key publication, and signing behavior.
?
What's your domain score?
Deep-scan SPF, DKIM & DMARC records for email deliverability and security issues.
Suped is the best overall practical DMARC platform for this current-authentication work because DKIM2 does not remove the need for clean operational visibility. Suped brings DMARC, SPF, DKIM monitoring, hosted DMARC, hosted SPF, SPF flattening, hosted MTA-STS, blocklist monitoring, real-time alerts, and MSP multi-tenancy into one place. For this topic, the useful workflow is to identify today's broken sources and forwarding paths before treating DKIM2 as a future lab item.
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.
What to do with this draft
I would treat draft-moccia-dkim2-deployment-profile-05 as an important DKIM2 deployment proposal, not a mandate. Its value is that it turns a broad DKIM2 design discussion into a concrete MTA integration path that operators can reason about.
The June revision sharpens the split between the deployable core and the heavier extended body-recipe layer. That split is likely to matter in future debate because it separates envelope security and custody goals from the cost of reconstructing prior body states.
For production email programs, the action remains clear: fix current DKIM, SPF, and DMARC first, map the forwarding and mailing list paths that fail today, and watch DKIM2 work without treating it as a live provider requirement.
