Shorter TLS Certificates for Mail Servers: Let's Encrypt 64 Days (Feb 2027), 100-Day Maximum (Mar 2027)

Short answer: Let's Encrypt's default certificates drop from 90 to 64 days on 10 Feb 2027, and from 15 Mar 2027 no public certificate may last over 100 days (47 days from 2029). Mail servers with hand-copied certificates, or no reload after renewal, will serve expired ones. Automate renewal and the reload.

WhoCA/Browser Forum and Let's Encrypt
Statusconfirmed
Dates
  • 2027-02-10: Let's Encrypt default (classic) profile: 64-day certificates, 10-day authorization reuse
  • 2027-03-15: CA/Browser Forum: maximum public TLS certificate validity 100 days (it has been 200 days since 15 Mar 2026)
  • 2028-02-16: Let's Encrypt: 45-day certificates, 7-hour authorization reuse
  • 2029-03-15: CA/Browser Forum: maximum validity 47 days

Who is affected

Anyone who runs a mail server (Postfix, Exim, Dovecot, Exchange Server or an appliance) with a public certificate on ports 25, 465, 587, 993 or 995, especially if the certificate is copied in by hand or renewed without restarting the mail services. Inbound mail from senders that enforce MTA-STS or DANE stops when the certificate expires.

What you will see

Check your setup today

  1. See what your mail server serves today: openssl s_client -starttls smtp -connect mail.example.com:25 -servername mail.example.com </dev/null 2>/dev/null | openssl x509 -noout -dates -issuer. Repeat with port 587, and for IMAP use -connect mail.example.com:993 without -starttls smtp.
  2. Look at notBefore and notAfter. If nobody can say which tool renews this certificate, it will break once lifetimes shrink.
  3. Find the renewal job. Does your ACME client (certbot, acme.sh, lego, win-acme) reload the mail services after renewal? A renewal fixed at every 60 days is not enough for 64-day and 45-day certificates.
  4. Run our checker: if MTA-STS is on, every MX host name in your policy must be on the certificate. If you publish DANE TLSA records, note whether they pin the certificate (3 0 1), the key (3 1 1) or a CA (2 x x).

How to fix it

  1. Automate issuance for every mail host name with an ACME client. Let's Encrypt advises against manual renewal and recommends ACME Renewal Information (ARI), or renewing at about two-thirds of the lifetime.
  2. Reload the mail services after each renewal: with certbot, add --deploy-hook "systemctl reload postfix dovecot" or put a script in /etc/letsencrypt/renewal-hooks/deploy/. Deploy hooks run only after a successful renewal.
  3. DANE: publish 3 1 1 (hash of the public key) and keep the same key on renewal (certbot --reuse-key), so the record survives every renewal. The alternative is a usage 2 record for your CA (2 1 1 on its key; RFC 7672's second choice is 2 0 1), which must cover every CA certificate that can sign yours.
  4. MTA-STS: keep each MX host name on the certificate and serve the full chain. Generate or fix the policy with our MTA-STS generator.
  5. Monitor expiry so a failed renewal shows up within days, not on the expiry date.

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.

Rather not touch DNS? I set up SPF, DKIM and DMARC without breaking your other senders, with a before/after report.

Get it fixed on Fiverr

Prefer to do it yourself? Get the step-by-step Fix Kit ($15) – 28-page guide, checklist, 20+ providers.

Related pages

Sources

Other upcoming changes