Skip to content
Postfix Insights

Shorter TLS certificates and mail delivery: what the 47-day limit means

The CA/Browser Forum has committed to a phased reduction of publicly-trusted TLS certificate lifetimes. The timeline: 200 days maximum (in effect now since 2026-03-15), 100 days from 2027-03-15, and 47 days from 2029-03-15. The current limit was 398 days. The driver is operational: a 47-day window makes manual renewal impractical, forcing the ecosystem toward automation. For mail operations, the chief consequence is this: shorter cert validity increases renewal churn across millions of mail servers, and more churn means more opportunities for certificates to lapse during rotation or deployment. That directly surfaces in your delivery logs and your verified TLS share.

398days
until Mar 2026
200days
Mar 2026 (now)
47days
Mar 2029
Maximum validity of publicly-trusted TLS server certificates, phased down by CA/Browser Forum ballot SC-081. Shorter certificates mean automation is mandatory.

The reduction schedule and why it matters

Section titled “The reduction schedule and why it matters”

The CA/Browser Forum Ballot SC-081v3 passed in April 2025 with consensus. The schedule is phased across three checkpoints:

  • 200 days maximum validity (effective 2026-03-15): already in force. CAs stopped issuing 398-day certificates in March 2026.
  • 100 days maximum validity (effective 2027-03-15): further tightening in 15 months.
  • 47 days maximum validity (effective 2029-03-15): the endpoint. Manual renewal becomes operationally impossible.

This eightfold increase in renewal frequency across the industry means a higher baseline rate of certificate rotations on production mail servers. When a certificate expires undetected or rolls over with a configuration mismatch, it ripples into your delivery metrics and peer reputation.

How it affects your mail server

Section titled “How it affects your mail server”

The scope of this reduction is all publicly-trusted TLS server certificates used for SMTP, including the ones on ports 25 (STARTTLS for inbound MTA connections), 587 (submission from clients), and 465 (submissions over implicit TLS). Your mail server’s certificate is now subject to the phased timeline, and your renewal procedures must adapt accordingly.

Your own server certificate

Section titled “Your own server certificate”

Your mail server’s TLS certificate for submission (ports 587, 465) and STARTTLS (port 25 inbound) falls under this reduction. Submission clients (e.g., your users’ mail clients, your web app) verify your certificate against a trusted root and check its validity dates. If your certificate has expired, submission TLS handshakes fail, and clients cannot authenticate or send mail. Submission breakage is immediate and user-visible.

Inbound port 25 STARTTLS from remote MTAs is more forgiving. Most remote mail servers use opportunistic TLS, meaning they negotiate TLS but do not verify your certificate’s authenticity (no hostname validation, no root chain checking). If your certificate expires, they still accept the STARTTLS upgrade but treat the connection as unauthenticated. The inbound mail is not rejected; it still arrives. However, the connection downgrades to anonymous TLS, which some reputation systems and delivery policies may penalize.

The hardening effect of shorter lifetimes is that you must automate renewals or risk delivery disruption. Manual renewal cycles no longer tolerate 90-day windows; a 47-day cert requires renewal every 6 weeks as standard practice. A missed renewal window for a 200-day certificate is recoverable; a missed window for a 47-day certificate is a service outage.

Outbound deliveries to other servers

Section titled “Outbound deliveries to other servers”

When your Postfix delivers to a remote mail server, it may negotiate TLS on port 25 (opportunistic, by default, with smtp_tls_security_level = may). Your server does not verify the remote certificate’s authenticity in opportunistic TLS mode. If the remote cert has expired, Postfix still delivers the message, but the TLS connection is downgraded to unauthenticated or falls back to plaintext. In your logs this appears as untrusted or anonymous TLS, not verified TLS. The message arrives; your verified TLS metrics fall.

Where expiry actually breaks delivery

Section titled “Where expiry actually breaks delivery”

Two policies enforce certificate verification on outbound SMTP and will reject delivery for an expired or mismatched certificate:

MTA-STS (RFC 8461) is a policy a recipient domain publishes over HTTPS (an mta-sts.txt file at https://mta-sts.<domain>/.well-known/mta-sts.txt), announced through a DNS TXT record at _mta-sts.<domain>. It does not use TLSA records; those belong to DANE. When a domain enforces MTA-STS, your server must negotiate TLS and verify the recipient’s certificate (valid chain, matching hostname, not expired), and must not deliver if verification fails. An expired certificate is a verification failure even when the chain and hostname are otherwise fine. The message is deferred or bounced. MTA-STS is increasingly common among large mail operators and enterprises; a peer’s expired certificate under MTA-STS means delivery failure until the peer rotates their cert.

DANE for SMTP (RFC 7672) uses TLSA records (RFC 6698) published in DNS to bind a certificate to a hostname. Your server can be configured to require or prefer DANE-verified TLS; if the TLSA record specifies a certificate fingerprint or public key, and the remote server presents a different certificate or an expired one, delivery fails. DANE is stronger than MTA-STS because the certificate binding is cryptographic; a peer cannot rotate their certificate without updating their TLSA record without breaking DANE-verified delivery.

More frequent certificate rotation increases the risk of a TLSA record mismatch during rollover. If a server rotates the certificate but the TLSA record is not updated first, DANE verification fails and mail is deferred. Proper DANE renewal practice requires careful choreography: publish the new TLSA record before retiring the old certificate, then allow a rollover window (typically 24-48 hours for DNS cache expiry) for both records to coexist in the wild. Shorter validity periods compress the rotation window and increase the risk of missing this choreography. A single misconfigured rollover can cause hours or days of delivery failure.

Automation is the answer

Section titled “Automation is the answer”

Manual certificate lifecycle management does not scale to 47-day cycles. ACME (RFC 8555) clients, such as Certbot, automate issuance and renewal at the API level. A well-configured Certbot renewal runs daily (or hourly) and re-issues certificates automatically well before expiry, typically 30 days out. The certificate is swapped in place, and Postfix reloads without service interruption.

If you use DANE with TLSA records, automation must extend to DNS. Publish the new TLSA record (pointing to the new certificate) before the renewal, allow a grace period for cache expiry and propagation, then retire the old record. Terraform, Ansible, or a custom API client can automate TLSA updates alongside certificate rotation.

For a mail server, configure your ACME client to renew early and automate reload signaling to Postfix (e.g., certbot renew --post-hook 'systemctl reload postfix'). The shorter the cert, the more critical this automation becomes.

What to watch in your logs

Section titled “What to watch in your logs”

Shorter certificate lifetimes across the Internet mean a rising baseline of cert rotations on peer servers. You will see them as TLS churn in your delivery logs. Watch for these signals:

Falling verified-TLS percentage: If your share of outbound deliveries over verified TLS declines month-over-month, a rising share of peer certificates may be expiring or failing rotation. This is the most sensitive indicator. A 5-10% drop in verified-TLS coverage over a month can signal ecosystem-wide renewal failures at a few major mail providers, or repeated missed renewals by peers you deliver to frequently. Postfix Insights metrics make this trend visible at a glance.

Rising untrusted/anonymous TLS to specific destinations: If a particular peer’s verified TLS count drops abruptly while you continue to deliver to them, their certificate may have expired or rotated without proper renewal coordination. These messages still arrive, but they are counted as untrusted TLS in your logs. Over time, this erodes your reputation score with that peer and reduces your chances of successful TLS negotiation on future deliveries.

Deferrals or bounces on MTA-STS or DANE routes: If you have peers with MTA-STS or DANE enabled and you see delivery failures citing certificate verification errors, that peer has likely allowed their certificate to expire or is in a misconfigured rotation state. These are genuine failures; the remote policy is working as designed. MTA-STS deferrals are temporary (Postfix retries). DANE deferral usually indicates a more serious synchronization error on the peer’s side, such as a TLSA record not updated before certificate rotation. To confirm whether a destination publishes a valid MTA-STS policy and TLS reporting, run its domain through the Email Authentication Checker.

Turn these signals into alerts. You should not have to watch a dashboard to catch a certificate problem. Set a threshold or anomaly alert on TLS-related deferrals and on your verified-TLS share, and route it to email or a webhook. If your own certificate lapses, submission failures and a sudden drop in verified TLS spike together, and the alert reaches you in minutes, before users report that they cannot send. The same applies when a high-volume destination’s certificate expires under MTA-STS or DANE and deliveries to them start failing: the failure rate crosses your threshold and the alert fires.

Postfix Insights TLS coverage reporting (verified vs. untrusted, by peer and version) is where you will see these patterns first. Check the delivery-health dashboard at /stats and the TLS segment of the search interface for trending. The TLS metrics are calculated per remote domain and include breakdowns by TLS version and cipher, making it easy to spot when a specific peer’s TLS profile changes or degrades.

For deep dives into individual failures, refer to TLS coverage from Postfix logs, which explains how to interpret TLS fields in the mail log and correlate them with Postfix Insights metrics. That guide covers TLS negotiation results (verified, Anonymous, Untrusted, Failed) and how to troubleshoot specific TLS errors in your mail logs.

Next steps

Section titled “Next steps”
  • If you have not yet automated certificate renewal, start with Certbot and a daily cron or systemd timer. See certbot.eff.org for installation and Postfix-specific configuration.
  • If you publish DANE TLSA records, audit your renewal workflow now to ensure the TLSA record is updated before each certificate rotation.
  • Monitor your Postfix Insights TLS metrics regularly. A declining verified-TLS share may be an early signal of renewal issues in your infrastructure or on peer servers.
  • Deploy Postfix Insights to gather continuous TLS visibility. Install with Quick start and explore the repository at github.com/Xodus-CO/postfix-insights.

References

Section titled “References”