“Unsuitable certificate purpose” / “Client certificate not trusted”: client certificate without clientAuth

Short answer: A mail server that checks client certificates rejected the sender's certificate because its Extended Key Usage has no TLS Client Authentication (clientAuth). Public CAs stopped adding clientAuth to new server certificates, so this usually starts right after a certificate renewal. Fix it on the receiving side: fingerprint matching or a private CA.

Coming: Public TLS Certificates Lose clientAuth (2026–2027): Which Mail Servers Break

421 4.7.1 <host> Error: Client certificate not trusted

certificate verification failed for <host>[<ip>]: not designated for use as a client certificate

SSL verify error: depth=0 error=unsuitable certificate purpose cert=<DN>

verify error:num=26:unsupported certificate purpose

What it means

The receiving server asks the sender for a TLS client certificate and verifies it for the client purpose. OpenSSL rejects a certificate whose EKU list exists but lacks clientAuth (the same check applies to the intermediate CA). Public CAs are dropping clientAuth: Let's Encrypt's last dual-purpose certificates expired around 6 Oct 2026, Sectigo and DigiCert stop in Feb–Mar 2027, and Chrome requires serverAuth-only certificates from 15 Mar 2027. OpenSSL 3.0.8 and later say "unsuitable certificate purpose", older versions "unsupported certificate purpose". Exchange Online is not affected: Microsoft says certificates used to relay to it don't need clientAuth.

How to fix it

1. Check the sender's certificate with our certificate check: if the Extended Key Usage shows serverAuth only, this is the cause.
2. Postfix receiver: replace permit_tls_all_clientcerts (any publicly trusted certificate) with check_ccert_access or permit_tls_clientcerts and the sender's certificate fingerprint. Fingerprint matching works without clientAuth; update it at every renewal. smtpd_tls_req_ccert = yes also requires a trusted client certificate.
3. Exim receiver: use tls_try_verify_hosts instead of tls_verify_hosts and decide in an ACL, or trust a private CA with tls_verify_certificates.
4. Long term: issue client certificates from a private CA that both sides trust; public server certificates won't carry clientAuth any more.
5. If you're the sender and can't change the receiver: Sectigo (until 10 Feb 2027) and DigiCert (until 1 Mar 2027) still add clientAuth on request. That buys at most 200 days. Timeline and sources: public certificates lose clientAuth.

Check your domain now

After the fix, send a test email to see SPF, DKIM and DMARC pass on a real message, then keep an eye on it: free DMARC monitoring shows every service that sends mail as your domain and which ones fail, in plain English.

Other bounce errors

• Gmail 550 5.7.26
• Gmail 421 4.7.26
• Gmail 550 5.7.27 / 421 4.7.27
• Gmail 550 5.7.30 / 421 4.7.30
• Gmail 550 5.7.32 / 421 4.7.32
• Gmail 550 5.7.40 / 421 4.7.40
• Gmail 550 5.7.24 / 421 4.7.24
• Gmail 550 5.7.25 / 421 4.7.23
• Gmail 550 5.7.29 / 421 4.7.29
• Outlook / Hotmail 550 5.7.515
• Outlook / Hotmail 550 5.7.1 S3150 / S3140
• Microsoft 365 550 5.7.606 / 5.7.511
• Microsoft 365 / Outlook 550 5.7.509
• Outlook / Hotmail 451 4.7.650 (S775)
• Yahoo / AOL 421 4.7.0 [TSS04]
• Yahoo / AOL 553 5.7.1 [BL21] / [BL23]
• Yahoo / AOL 554 5.7.9
• Gmail 421 4.7.28
• Microsoft 365 550 5.7.708
• Microsoft 365 535 5.7.139 / 530 5.7.57
• Microsoft 365 550 5.7.233 / 5.7.232
• Microsoft 365 550 5.7.236
• Microsoft 365 / Outlook 550 5.7.520
• Microsoft 365 550 5.1.8
• Gmail 550 5.7.1 / 421 4.7.0
• Gmail 550 5.7.1 / 421 4.7.0
• Gmail / Google Workspace 550 5.4.5
• Gmail / Yahoo / iCloud 550 5.7.26 / 554 5.7.9 / 554 5.7.1 [BS01]
• Validity Heatwave domain blocklist
• Microsoft 365 5.4.8
• Microsoft 365 5.7.5
• Microsoft 365 550 5.7.64 / 4.4.62
• Microsoft 365 5.7.60
• Microsoft 365 550 5.7.68
• Let's Encrypt / DigiCert / any public CA SERVFAIL (CAA / DNSSEC)