New DKIM2 deployment profile draft proposes a milter rollout path
News
Published 23 Jun 2026
Updated 23 Aug 2026
9 min read
Summarize with
Updated on 23 Aug 2026: We updated this analysis for revision 07 and its monitoring-first milter rollout path.
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.
This belongs in the standards-tracking bucket, not the production-change bucket. 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 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.
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 | Standards tracking, not production work. |
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: 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.
Three practical reasons make this approach relevant. It does not assume every operator can change MTA internals. Verification can run after the complete message is available. 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: Declare header and body changes instead of silently breaking the custody chain.
- 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. 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.
What the August revision clarifies
Revision 07 is a substantial expansion of the proposal originally covered here. The active draft gives operators more detail on result reporting, graduated enforcement, cryptographic behavior, privacy, and mixed-path deployment.
|
|
|
|---|---|---|
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 | Expands signed-header and hh= rollback handling. | Separates mandatory critical fields from wider undeclared-change detection. |
Privacy | Adds detailed treatment for re-origination, null recipes, retention, and security gateways. | Makes body-recipe review a deployment decision rather than a simple feature toggle. |
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 envelope or the recipient list. DMARC then asks whether SPF or DKIM passed and aligned 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 alignment 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 profile is more operational because it asks how DKIM2 can run in real MTA environments.
Who should pay attention
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.
Practical next steps now
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 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's DMARC platform supports the current-authentication work that remains necessary while DKIM2 is still a draft. A practical Suped workflow is to group aggregate report data by source and domain, find DKIM or SPF alignment failures, and map forwarding paths before any DKIM2 lab test.
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
Treat draft-moccia-dkim2-deployment-profile-07 as a concrete DKIM2 deployment proposal, not a mandate. Its value is that it turns a broad DKIM2 design discussion into an MTA integration path that operators can evaluate.
The August revision sharpens the separation between the deployable core and the heavier extended body-recipe layer. That split matters 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.
