Let's Encrypt stopped sending expiration emails

Let's Encrypt stopped sending expiration reminder emails on June 4, 2025. If a certificate you manage is drifting toward its expiry date, the email that used to warn you a month out no longer arrives.

That backstop mattered more than it should have, because a growing share of Let's Encrypt users never needed it in the first place: certificates issued through ACME clients like certbot renew automatically. The email was aimed at the minority still renewing by hand, or at automation that had quietly broken. With certificate lifetimes shrinking toward 47 days by 2029, losing that backstop lands at exactly the wrong time.

What actually happened

Let's Encrypt announced the change on January 22, 2025, and the service ended on June 4, 2025, about five months later. The stated reasons, in its own words:

• Automation improved: “Over the past 10 years more and more of our subscribers have been able to put reliable automation into place for certificate renewal,” reducing how many people actually needed the reminder.
• Privacy: sending the emails meant retaining millions of email addresses tied to issuance records, which Let’s Encrypt no longer wanted to hold.
• Cost: the service cost Let’s Encrypt tens of thousands of dollars a year to run.
• Simplicity: removing it cut a source of infrastructure complexity for a nonprofit CA operating at massive scale.

Let's Encrypt's own fix, and why it is not one

Let's Encrypt's replacement recommendation is a third-party email service, naming Red Sift Certificates Lite (formerly Hardenize), which offers free expiration email monitoring for up to 250 certificates. It is a reasonable pointer for anyone who genuinely has no other option.

But look at what actually changed: nothing about the underlying mechanism. It is still one inbox, subscribed to instead of another, with the same failure modes an inbox always has. A filter can quietly route it to spam. The person who set it up can leave the team. Nobody escalates if the first email goes unread. That was already true when Let's Encrypt ran the service itself, which is part of why a five-year-old Let’s Encrypt post confirming the shutdown calls the emails a courtesy notice, never a guarantee.

What the emails actually protected you from, and what they never did

It helps to separate two failure modes the same email used to paper over.

• Forgotten manual renewal: someone was supposed to reissue a certificate by hand and did not. The email was a genuine safety net here, because nothing else was watching.
• Automation that silently broke: an ACME client is scheduled to renew, but a DNS validation record changed, the renewal cron stopped running, or a load balancer kept serving the old certificate after a successful renewal elsewhere. The automation believes it succeeded. Nothing about it fails loudly.

Both cases used to end the same way: an expiry-warning email arrives, someone reads it, someone acts. But the two failures are not equally rare anymore. Automated renewal is the default now, so the failure that matters most is the second one, and it is precisely the one an email never verifies. An expiration notice, from Let's Encrypt or from a third party, tells you a date is approaching. It does not check whether the certificate actually being served right now is the one you think it is.

This matters most for the teams least equipped to notice. A company running enterprise PKI has a certificate lifecycle management platform and a team whose job is exactly this. A small team or solo developer running Let's Encrypt through certbot, a hosting platform's built-in TLS, or a load balancer's managed certificates has neither, and was quietly relying on that one email as the entire safety net. That email is the piece that just disappeared, at the same time certificate lifetimes are getting short enough that a single missed renewal cycle is no longer a rare event.

What actually catches a renewal that fails silently

The fix is not a better inbox. It is a check that looks at the live certificate directly, on a schedule, independent of what the ACME client or the CA believes happened. That is the entire job of SSL certificate monitoring: a daily revalidation of the certificate actually being served, which catches the common failure where a Let’s Encrypt auto-renewal breaks silently and the original certificate keeps moving toward expiry regardless of what the renewal job logged.

The distinction that matters is not just when the check runs, but what happens after it finds a problem. An unread email ends the chain right there. A monitoring check that opens a tracked incident and routes the alert to email, Slack, and a webhook gives the failure more than one chance to reach someone before the certificate actually expires.

The practical shift

If Let's Encrypt's emails were the only thing standing between you and an expired certificate, that backstop is gone, and the replacement Let's Encrypt itself suggests is still just an inbox. Automated renewal was always the right fix for the actual problem. What changed is that the one external check on whether it worked no longer exists by default, and a different inbox does not bring it back.

Worth checking today: if nothing outside your renewal automation itself ever verifies the certificate it produces, that gap existed before June 2025, and it just stopped being covered by someone else's email.