Let's Encrypt rate limits when you issue certificates for customer domains

Ask any assistant how to let your users bring their own domain and it will hand you a build plan: an ACME client, DNS-01 validation, Let's Encrypt, and a warning about rate limits. The warning is almost always the same number — 50 certificates per registered domain per week — and for a platform issuing certificates on customer-owned domains, it is the one limit that will probably never affect you.

The limits that will are further down the page, and they are the ones nobody quotes. This is a walk through all of them, which ones bind for a custom-domain platform, and what each one feels like when you hit it.

One disclosure first: we build CustomDomain, a managed service for exactly this problem, and this article lives on our blog. The rate-limit figures below come from Let's Encrypt's own documentation, read on 19 August 2026, and their page is the authority if it has changed since. Where we describe what our own edge does, we say so plainly and we also say what it does not do.

Every current limit, in one table

From letsencrypt.org/docs/rate-limits, last updated 5 August 2026. Let's Encrypt moved to a token-bucket model, so each limit has a capacity and a refill rate rather than a hard window that resets.

The three in bold are the ones that bind in practice for a platform connecting customer domains. The famous one is not among them.

Why the 50-certificate limit usually does not apply to you

The limit is 50 new certificates per registered domain per week, where a registered domain means the part you buy — acmebakery.com, not shop.acmebakery.com. It is a global limit, counted across every ACME account.

If your customers connect domains they own, each customer brings a different registered domain. Connecting a thousand customers in a week means a thousand registered domains, each spending one of its own fifty. You would have to issue fifty certificates for a single customer's domain in seven days to trip it, and there is no ordinary reason to do that.

There is one shape where it bites immediately, and it is worth naming because it is a common early architecture: giving every customer a subdomain of your own domain. If your customers live at acme.yourplatform.com and globex.yourplatform.com, every one of those shares the registered domain yourplatform.com. Fifty new customers in a week and issuance stops for everyone, including renewals of names you have not issued before. The usual fix is a wildcard certificate for *.yourplatform.com, which is one certificate rather than fifty — and the other usual fix is moving customers onto their own domains, which is the thing this whole category exists to make easy.

The limit that actually hurts: five authorization failures per hour

Every certificate needs the domain's control proven first. When that proof fails — the CNAME is not there yet, the TXT record has a typo, the customer pasted it into the wrong zone — that is an authorization failure, and you get five per identifier per hour, refilling one every twelve minutes. There is no override.

Five sounds generous until you notice that failed validation is the normal state of a domain that a human is still configuring. The Domain Connect Association's own knowledge base reports that roughly half of users who attempt manual DNS configuration fail and abandon the setup. Those customers are not doing something unusual; they are the median case, and each of their attempts spends from the same bucket.

It gets worse with more infrastructure, not better. If TLS is issued on demand at the edge, every TLS handshake for an unknown hostname can trigger an order. A customer who has not finished their DNS, hitting a page repeatedly, on a fleet of several edge nodes that do not share state, produces failures far faster than one every twelve minutes. The rate limit is then not a capacity problem — it is a retry-loop problem wearing a rate limit's clothing.

This is a real mechanism rather than a hypothetical one. Our own edge carries a throttle written for exactly it: while the control plane reports that the last ACME order for a host failed, the edge places at most one new order per window for that host, and any other status clears the cooldown. The comment in that file says the quiet part directly — a fleet of edges re-ordering on every handshake "is exactly how a Let's Encrypt 'too many failed authorizations' rate limit gets earned." If you are building this yourself, the throttle is not an optimisation to add later. It is load-bearing.

Five per exact set of identifiers, and why retries are expensive

You may issue at most five certificates for the same exact set of names every seven days, refilling one every 34 hours, with no override available. Two different names are two different sets, so this does not constrain growth. It constrains repetition.

The way platforms hit it is by treating certificate issuance as retryable. A deploy loop that reissues on every restart, a health check that reprovisions when it sees an error, a migration that re-runs for a batch of hosts — five attempts and that exact name is frozen for the better part of a day and a half. Certificates are not idempotent operations you can hammer.

Three hundred orders per three hours is the real ceiling

An ACME account may create 300 new orders every three hours, refilling one every 36 seconds. That is 2,400 a day at a sustained rate, and it is the number to plan a platform against, because unlike the per-domain limit it applies to all your issuance together.

It is also the one limit on this list where the answer is simply to ask: overrides are available on request. Let's Encrypt grants them for legitimate high-volume use, and a platform issuing on behalf of thousands of customers is the case the override process exists for. Ask before you need it, not during the incident.

Renewals are treated differently, and one kind is exempt from everything

Renewals do not count against new orders per account or against certificates per registered domain. They are still subject to authorization failures and to the exact-set limit, so a renewal that cannot validate still burns the same bucket a first issuance does.

Renewals coordinated through ARI — ACME Renewal Information, where the CA tells the client when to renew — are exempt from all rate limits. That is a meaningful difference at scale and it is worth building toward.

We do not do this yet. Our edge issues through golang.org/x/crypto/acme and autocert, and it does not consult the renewal-information endpoint, so our renewals get the ordinary exemptions and not the blanket one. It is on the list. If you are choosing a managed provider partly on rate-limit headroom, ask whoever you are talking to whether they implement ARI, and treat a vague answer as a no.

What this means if you are deciding whether to build

None of these limits make a custom-domain platform impossible to build. They make it a system with a specific failure mode: it works in testing, works for the first hundred customers, and then degrades in a way that looks like flakiness and is actually a bucket you emptied an hour ago. The engineering is not the ACME call. It is the state machine that decides when not to make one.

What a managed service is actually selling here is that throttle, the shared view of which hosts are failing, the backoff, the override relationship with the CA, and somebody whose job it is to notice when the limits change. Custom domains for SaaS covers the rest of the picture, and automating TLS for customer domains goes through the issuance path in detail.

The honest version of the trade: if you are connecting tens of domains, build it, and put a throttle in front of the ACME client on day one. If you are connecting thousands, the rate limits are a small part of what you are taking on, and the certificate layer is the least interesting part of the problem you will spend the most time on.

Frequently asked questions