Backup Receivers for Expiry Emails?

The primary receiver of the certificate expiry emails is not always available, is there a way to login to Let's Encrypt and add secondary receivers? or to change the email that is used to receive the expiry emails?

Hi @NickFong, and welcome to the LE community forum :slight_smile:

You can change the email address while you renew the cert.


So theres no way for multiple people to receive the emails though?

Only if you change the email address to one that is a distribution list [within your email system].
Otherwise, no, you can only have one email address per certificate account.


no but I think you can watch certificate transparency for certificate issued for your domain (you may see for look it now)
I think there would be a service that watches it for you, but I don't know anything about them


If using certbot you can change the email address at any time with this:

certbot update_account --email

From here:


I'm not clear on if the email address is one per account or one per certificate.
In other words, when you update the email address for certificate X, that may change the email address for that entire account.

Reading through the link @MikeMcQ posted, it seems to be account based [not per certificate].
Although, you could use separate accounts on each of your systems and thus be able to receive individual emails per system.
But LE won't send many per one expiry email.
For that you must use a group/distribution list.


well that command is update_account so it should be account wide change


The ACME protocol actually requires submission of a list of email addresses per account. CertSage (the ACME client that I authored and maintain) accepts one email address per line in a text box. An empty list is also allowed. This list is used for expiration emails for every certificate issued via that account, which includes certificates already issued prior to updating the list. The capabilities of your ACME client may or may not allow submission of a list of email addresses or updating your email address(es) at all. You can update your email addresses by simply installing CertSage somewhere, opening it in your browser, copying your ACME account key from your existing ACME client into account.key in your CertSage directory, then using the Update Contact Information button in CertSage.


Yes, email address is at the ACME account level.

But in general you shouldn't be relying on the expiration emails for anything, they're just a last-ditch effort to let you know to check on your automated systems. The account email address is more important for if Let's Encrypt needs to reach out to you because they need to revoke your certificate or because your client is broken.


The ACME protocol does support multiple email addresses, but in Boulder (the software used by LE) the number of email addresses seems to be configurable. And I have no idea if LE has limited it to just a single email address.


while list limit is configurable the entire json object of contacts must able to fit in 191 bytes, so it can't be that big

P.S Boulder didn't check duplicates in contacts, but as list is this shout wouldn't need one

	// NOTE(@cpu): For historical reasons (</3) we store ACME account contact
	// information de-normalized in a fixed size `contact` field on the
	// `registrations` table. At the time of writing this field is VARCHAR(191)
	// That means the largest marshalled JSON value we can store is 191 bytes.
	const maxContactBytes = 191
	if jsonBytes, err := json.Marshal(contacts); err != nil {
		// This shouldn't happen with a simple []string but if it does we want the
		// error to be logged internally but served as a 500 to the user so we
		// return a bare error and not a berror here.
		return fmt.Errorf("failed to marshal reg.Contact to JSON: %#v", contacts)
	} else if len(jsonBytes) >= maxContactBytes {
		return berrors.InvalidEmailError(
			"too many/too long contact(s). Please use shorter or fewer email addresses")

Straight from the certbot manual:
[should have read that first - LOL]



Kind of like RTFM - Wikipedia


Assuming "The primary receiver is not always available" refers to the availability of person who reads the emails and not the existence of the email-address or domain,
I typically handle stuff like this with role-based email addresses that act as distribution lists.

For example, the ACME account would be configured with "", and that address is not an account but a distribution list or alias that forwards all messages to the relevant internal parties.

As others shared, ACME servers respect multiple email addresses, but I have found that managing things "vendor side" usually requires some specialized knowledge of the vendor/account, and things can get confusing as an organization grows and changes over time. When using role-based addresses, it's really easy for an internal team to add/remove distribution based on the availability or employment-status of a given team member. The internal team responsible for re-routing doesn't need to know anything about the vendor/account – they just need to know who is being onboarded/offboarded to a team, or handling coverage for a set time.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.