SMTP client auth hits a 2027 wall. M3AAWG wants a plan.

If you use mutual TLS to prove your SMTP client is allowed to send, a policy deadline is heading your way. Chrome’s root program will stop enabling client certificates for new issuance after March 15, 2027—and M3AAWG says the industry needs a shared replacement.

M3AAWG’s call is blunt: “The industry does not yet have the answer.” The group wants providers to help design a new trust model for SMTP client authentication before certificate renewals hit that date, or risk incompatible, one-off fixes across the ecosystem.

What happened

On March 15, 2027, the Chrome Root Program will require that any subscriber certificate issued under its included hierarchies contain only the serverAuth extended key usage (EKU), according to Policy v1.8 §1.3.2 updated on February 5, 2026 (policy).

That change removes clientAuth EKU from newly issued, Chrome-rooted certificates, which many SMTP sending systems present during mutual TLS (mTLS) to authenticate as a trusted client to a receiving server.

M3AAWG stresses the date is an issuance deadline, not a revocation event; certificates issued before March 15, 2027 are not directly affected and can continue until their normal expiry (M3AAWG).

The restriction is specific to Chrome’s root store. As of the article’s publication, Apple, Microsoft, and Mozilla TLS root programs have not adopted the same limitation and could be used instead, M3AAWG notes (M3AAWG).

Chrome’s move does not touch public TLS server authentication, so STARTTLS with server-side verification keeps working. The risk is confined to SMTP paths that enforce client-side certificate authentication.

M3AAWG also clarifies this is not a CA/Browser Forum ban. The Forum’s Baseline Requirements govern publicly trusted TLS server certificates; individual root programs can impose stricter rules on what their hierarchies may issue (CA/B Forum).

Because SMTP TLS behavior is local policy, the impact varies. Some receivers never required clientAuth; others gate high-trust channels, partner relays, or bulk-sender routes on it, M3AAWG says, citing RFC 3207 for SMTP over TLS operation (RFC 3207).

The background

Extended Key Usage values limit what a public certificate may be used for; serverAuth signals server identity, while clientAuth enables client identity checks during TLS handshake. Removing clientAuth EKU from new Chrome-rooted certs blocks that handshake role after renewals.

Chrome’s root program has signaled a web-only direction since it launched in 2022, and the 2027 cutoff enforces that stance by confining new issuance to serverAuth EKU within its hierarchies (policy).

SMTP over TLS, formalized in RFC 3207, leaves authentication policy to endpoints, which is why mTLS is common in some interconnects and absent in others. M3AAWG’s concern is interoperability once common issuance paths for clientAuth expire.

The CA/Browser Forum’s scope matters because it explains why there’s no universal rule on client certs: the Baseline Requirements cover server certificates, and root programs can restrict or allow additional profiles on their own hierarchies.

M3AAWG points out there is no dedicated, public, email‑oriented PKI for SMTP client authentication today. That vacuum increases the chance of one-off private hierarchies or ad hoc trust anchors if the industry does not coordinate.

The group also highlights that SMTP sender identity at the transport layer (SMTP‑OUT) is “poorly specified and apparently of negligible application,” signaling a standards gap separate from domain-level identity systems like DMARC and BIMI.

If you’re thinking about domain authentication instead: DMARC, SPF, and DKIM live at the message layer, not the TLS session. As we’ve reported in our BIMI logos start with DMARC enforcement piece, they solve different trust problems than mTLS.

For readers wanting more on the broader theme, our authentication category hub collects developments that shape how email proves identity across protocols and layers.

What people are saying

M3AAWG is inviting members to a “ClientAuth EKU Initiative” to define “a durable, interoperable trust model for SMTP client authentication,” urging providers to bring use cases, trust requirements, and interop experience (M3AAWG).

The group lists concrete open questions: whether to create new technical standards, new certificate profiles, or an email‑specific PKI to replace lost clientAuth issuance paths across mailbox providers, gateways, and enterprise systems.

It asks how SMTP senders should cryptographically authenticate identity without publicly trusted clientAuth certificates, and what identity, issuer, chain, and validation checks receivers should enforce in any successor model.

M3AAWG wants an agreed test plan: how the industry will trial interoperability, migrate, and rollback without disrupting legitimate mail flow, which is essential for large senders and security services that rely on predictable TLS behavior.

The article cautions providers not to assume “a validated replacement for the clientAuth EKU already exists for SMTP.” That warning targets premature vendor claims and underscores the need for shared proofs before operational changes.

Providers are urged to identify where they require clientAuth today—such as partner relays, bulk ingest points, or quarantine release paths—so they can participate with hard data and not generalities.

What happens next

If your SMTP client certificates chain to a Chrome-included root and you renew after March 15, 2027, you will not receive clientAuth EKU under that program, so plan issuance changes before renewal windows open.

M3AAWG recommends examining your certificate roots now. Mapping chains reveals whether switching issuance to Apple, Microsoft, or Mozilla‑included hierarchies buys time while the industry finalizes a common approach.

Senders with enforced clientAuth on the receiving side should test what breaks when presenting only serverAuth. In many setups, policy simply refuses the connection, so toggles or dual‑stack endpoints may be needed during transition.

Receivers should document their validation policy: what identity in a client certificate binds to sending privilege, what name forms they accept, and how they vet issuers, which will matter if a new email‑oriented PKI emerges.

Because some routes will remain server‑auth only, operators should separate transport trust from message identity and be explicit about what each grants. That separation avoids overloading certificate checks with DMARC‑like guarantees they do not provide.

M3AAWG’s process intends to land a future state “before providers are forced into fragmented, incompatible solutions.” Participation will determine how uniform the replacement is and how easily systems interoperate across providers.

Public TLS for servers is unaffected by Chrome’s change, so there is no forecast of universal email failure in 2027. The narrow but important risk is losing client-auth capability where it gates delivery or privileged SMTP access.

Organizations with annual or biennial renewal cycles should align procurement calendars now. Certificates issued before March 15, 2027 can bridge near-term operations while standards work proceeds, reducing pressure for hurried, bespoke fixes.