This article includes a call to action for M3AAWG members to join the ClientAuth EKU Initiative to work with fellow email experts on a solution.
Overview
The email ecosystem faces an emerging trust gap for SMTP (Simple Mail Transfer Protocol) client certificate authentication due to recent public Web PKI (Public Key Infrastructure) policy changes that have removed future usage of client certificates in public TLS (Transport Layer Security) scenarios. Many senders who rely on client certificates will be impacted by this removal once they attempt to acquire a certificate to be issued after March 15th, 2027.
Organizations that depend on certificate-based SMTP client authentication should be evaluating their exposure, while the industry works together to define interoperable and operationally viable alternatives before future certificate renewals. Some of the questions that need to be addressed include whether the community should create new technical standards and/or a new PKI infrastructure specifically to address sending email via SMTP.
The Change, the Deadline, and the Limitations
Effective March 15, 2027, the Chrome Root Program Policy, version 1.8, §1.3.2, will require subscriber certificates issued under PKI hierarchies included in the Chrome Root Store in the Chrome Root Program to issue only certificates that have only a serverAuth EKU1. Since the root program's inception in 2022, Chrome has communicated that its plan was to move towards restricting its hierarchy to web-only, suggesting to the community that the Chrome Root Program perhaps should not be used for non-browser scenarios or protocols. Chrome's changes apply to hierarchies rooted in that program's root store, not all PKI hierarchies worldwide. Other TLS root programs exist, such as Mozilla, Apple, and Microsoft, and they have not, as of the publication of this article, implemented such restrictions. These others could be used as an alternative to the Chrome root program. March 15, 2027, is an issuance deadline, and this change does not impact certificates issued before that date.
Public TLS server authentication remains available. This is not a forecast that all email will fail: SMTP TLS authentication depends on local policy, and mutual TLS is not universal2. The risk following March 15, 2027 is losing client-authentication capability in certificates used by sending SMTP systems. Replacing a clientAuth certificate with a serverAuth-only certificate may break an enforced clientAuth requirement.
This is a root-program requirement, not a blanket CA/Browser Forum ban. The Forum's Baseline Requirements cover publicly trusted TLS server certificates3; individual root programs can impose their own conditions. These changes do not directly dictate an individual mail server's trust configuration.
All senders should examine their TLS certificate roots to determine if they are impacted by the Chrome root program changes and adjust accordingly, potentially moving to a root included by Apple, Microsoft, and/or Mozilla root stores.
Open Questions for the Email Industry to Solve
There is currently no agreed future state for certificate-based SMTP client authentication. Other root programs such as Mozilla and Apple have hinted at, without formal declarations, a similar interest in dedicating their hierarchy to web, and there is no dedicated public certificate-based SMTP or even mTLS (Mutual TLS) root program. The immediate priority is industry alignment on what that replacement must be.
The email community must determine:
- How any proposed model can work across mailbox providers, email security services, gateways, and enterprise mail systems.
- Use of SMTP sender identity (SMTP-OUT), which is currently poorly specified and apparently of negligible application.
- How an SMTP sender should cryptographically authenticate its identity if publicly trusted ClientAuth certificates are no longer available.
- What certificate identity, issuer, chain, and validation requirements receiving systems should enforce.
- Whether new standards, certificate profiles, or industry guidance are required. In particular, whether a new email-oriented Public-Key-Infrastructure is warranted.
- How the industry will test interoperability and transition without disrupting legitimate mail flow.
Until these questions are resolved, email providers should identify their clientAuth scenarios and participate in collaborative forward-focused interoperability work. They should not assume that a validated replacement for the clientAuth EKU already exists for SMTP.
Call to Action - Closing the Gap with M3AAWG
The industry does not yet have the answer. The email ecosystem needs to define a durable, interoperable trust model for SMTP client authentication.
M3AAWG members should join fellow email experts on the ClientAuth EKU Initiative to discuss how to work through this transition and develop that future model. The objective is to establish a future state for SMTP client identity and trust before providers are forced into fragmented, incompatible solutions. Bring your use cases, trust requirements, and interoperability experience to that work. This is a shared email ecosystem problem, and progress depends on providers solving it together.
Sources
[1] Chrome Root Program Policy, v1.8 (updated February 5, 2026), §1.3.2, “Promote use of dedicated TLS server authentication PKI hierarchies”; §1.1.1 (baseline requirements and stricter program rules). https://googlechrome.github.io/chromerootprogram/crp/policy/
[2] RFC 3207, SMTP Service Extension for Secure SMTP over Transport Layer Security, §§4–4.1.
https://www.rfc-editor.org/info/rfc3207
[3]CA/Browser Forum, Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates, §1.1, “Overview.”
https://cabforum.org/working-groups/server/baseline-requirements/requirements/