I assume the reasoning for the policy change is that allowing a single certificate to be used for many different uses puts a greater risk of the certificate private key being leaked.

They don't want your insecure mail server software to put your secure web server at risk.

smtp servers shouldn't have been doing this anyway...

the pki separation is good.

This is precisely like NIST requirements to change your password frequently, which was well intended, but reduced security due to people not being able to recall their password.

(This is now reversed, of course)

Reducing certificate life to ridiculous time frames, making it difficult to obtain certificates, all for very dubious, extremely tiny and minor improvements in security. It's going to cause more harm than good, and in the end, will reduce not enhance security.

For example, many SMTP servers may revert to self-signed certs now.

Why is it Google that is making these rules? A company would not have this kind of power in a fair competition market.

Does anyone's mail server accept (much less trust) publicly-trusted client certs anyway?

I've read the announcement[1] and I don't see how this deprecation has anything to do with SMTP. Is it because the sending MTA will present its own server certificate as a client certificate to the receiving MTA? I thought most of this traffic was outright unencrypted or opportunistically encrypted with self-signed certs.

Do most SMTP server require, or even use, certs issued by a CA?

[1]: https://letsencrypt.org/2025/05/14/ending-tls-client-authent...

The link is to a random Mastodon post ranting about the change. I think it would be better if it linked to the actual blog post from Let's Encrypt: https://letsencrypt.org/2025/05/14/ending-tls-client-authent...