IETF approves DANE client authentication draft with an SMTP use case
News
The IESG approved draft-ietf-dance-client-auth-17 for publication as a Proposed Standard on November 5, 2026, at 16:18:42 UTC. The DANCE working-group draft describes TLS client authentication using DNSSEC-validated TLSA records, with an explicit SMTP sending-MTA example. The official approval records the publication decision.
As of November 6, 2026 UTC (November 7 in Sydney), this remains an Internet-Draft in the RFC Editor queue. It is a general TLS client-authentication mechanism, not an SMTP-specific mandate. The approval announces neither a mailbox-provider rollout nor a deadline for email operators.
Status: Approved for publication as a Proposed Standard, awaiting RFC publication. This is still a draft, not a published RFC or final production guidance.
What the approval changes
The milestone is the November 5 IESG approval. Revision 17 was submitted on November 4; the November 6 editor status update is a later process event. Neither is the approval date.
The SMTP use case extends the direction of peer authentication. Existing SMTP DANE, specified in RFC 7672, lets the sending MTA authenticate the receiving server. The new draft lets a supporting receiving TLS server authenticate the connecting client MTA when the mechanism is negotiated.
Existing SMTP DANE
The sending MTA checks the receiving server against DNSSEC-protected TLSA data. This authenticates the destination of the SMTP connection.
DANE client authentication draft
The receiving TLS server checks the connecting client against its DNSSEC-protected TLSA data. This authenticates the client peer when supported and requested.
How the SMTP example works
Sections 1 and 3.1 of the version 17 draft establish the scope and SMTP example; sections 6-8 describe signaling and validation. With compatible TLS 1.3 or later, the server requests client authentication and advertises support for DANE Client Identity.
The client then supplies its corresponding certificate or public key, proves possession of the private key, and conveys the exact TLSA owner name. The worked SMTP example uses:
Example client TLSA owner name, not a deployment instructiontext
_smtp._client.mta1.example.com
The server queries that name, validates DNSSEC and checks the credential against the TLSA data. The name alone proves nothing. Authentication depends on the validated binding and proof of key possession.
DNS validation or TLSA matching failures cause the connection to abort, or the client to be treated as unauthenticated where server policy permits. An unauthenticated fallback is not successful DANE authentication. A server requiring this mechanism cannot negotiate below TLS 1.3.
TLS identity does not authenticate the message
An authenticated client MTA is a TLS peer. That result does not establish that the visible From address is authorized, that a message passes DMARC, or that the client has permission to relay mail. Relay authorization remains an application-policy decision.
SPF checks the sending IP against the envelope-sender domain, with HELO used in defined cases. DKIM verifies a message signature under its signing domain. DMARC checks whether a passing SPF or DKIM domain meets its domain relationship rules for the visible From address. None is replaced by this draft.
|
|
|---|---|
Client DANE draft | Connecting TLS peer |
SMTP DANE | Receiving TLS server |
DMARC | From-domain authentication |
Relay policy | Permission to relay |
MTA-STS | Receiving transport policy |
TLS-RPT | Transport failure reporting |
Separate controls address separate email security questions.
MTA-STS remains a receiving-domain transport policy for supporting senders. TLS reporting provides aggregate information about transport-policy delivery failures. Neither authenticates the connecting client through this new extension, and ordinary TLS reports do not establish that the draft mechanism was negotiated.
What operators can assess now
I would keep evaluation in a controlled relay lab while tracking RFC publication and explicit implementation support. A software package supporting existing SMTP DANE or TLS 1.3 does not, by itself, establish support for this client-authentication extension.
Sections 10 and 12 of the draft cover operational and security considerations. For a lab assessment, I would require evidence for each of these points before considering a future deployment:
- DNSSEC and availability: Test validation failures and resolver outages. Check that authentication outcomes and relay permissions remain consistent with local policy.
- Rotation and caches: Exercise key rotation against cached TLSA data. Account for cache timing when testing credential replacement and revocation.
- Failure and fallback: Record why authentication failed and whether the connection continued without authentication. Test that fallback never silently grants relay access.
- Identity disclosure: Assess exposure of the client name to DNS resolvers and authoritative servers. Encrypted TLS handshake messages do not remove the separate DNS disclosure path.
Keep production work on existing controls
This approval calls for no production DNS changes. The next useful evidence is RFC publication and documented, interoperable implementation support. There is no adoption date or operator deadline to plan around.
For existing transport-policy work, Suped's hosted MTA-STS manages policy hosting, and our TLS-RPT reports help investigate delivery failures. Suped's MTA-STS checker audits a current receiving policy and its MX coverage. These workflows address existing transport controls; they do not verify the draft's client-authentication exchange.
Frequency asked questions
No. As of November 6, 2026 UTC, draft-ietf-dance-client-auth-17 has IESG approval for publication as a Proposed Standard and remains in the RFC Editor queue.
No. SMTP is an explicit use case for a general TLS client-authentication mechanism. Its use requires compatible implementations and negotiation; the approval creates no universal SMTP requirement or deadline.
No. TLS client authentication identifies the connecting peer. DMARC evaluates message authentication against the visible From domain. Relay authorization is also a separate policy decision.
