Short answer: Let's Encrypt can issue certificates for thousands of customer domains, and most of its rate limits never come into play. Three usually do. New Orders per Account caps a burst of new domains at 300 orders every three hours. Authorization Failures caps retries on a hostname with broken DNS at 5 per hour, and a hostname that keeps failing for weeks gets paused. New Certificates per Registered Domain caps you at 50 a week when many tenants share one parent domain. Issue only for hostnames a tenant has claimed, back off hard when validation fails, renew with ARI, and request an override before launch day.
The limits that matter for customer domains
Let's Encrypt is free, automated and very good at what it does. Its limits exist to keep one subscriber from crowding out everyone else. They're generous for a single site. They get tight when you issue certificates for other people's domains, because you don't control their DNS, their timing or how many hostnames arrive at once.
The table below comes from the official rate limits page (last updated August 5, 2026), as of October 2026. Limits work as token buckets that refill gradually, so you get some capacity back long before the full window passes.
| Limit | Size and refill | When a SaaS hits it |
|---|---|---|
| New Orders per Account | 300 orders per 3 hours, refilling 1 every 36 seconds. Override available. | Bulk onboarding or an import of many new customer domains. |
| New Certificates per Registered Domain | 50 certificates per 7 days, refilling 1 every 202 minutes. Counted across all accounts. Override available. | Many tenants on subdomains of one domain, or one customer with many hostnames. |
| New Certificates per Exact Set of Identifiers | 5 certificates per 7 days for the same hostnames. No override. | Servers that re-issue on every restart because certificates aren't stored. |
| Authorization Failures per Identifier per Account | 5 failures per hour per hostname. No override. | Retrying a customer hostname whose DNS doesn't point at you yet. |
| Consecutive Authorization Failures per Identifier per Account | 1,152 consecutive failures, refilling 1 per day and resetting on success. Issuance is then paused. No override. | A disconnected or abandoned customer domain you keep retrying. At 1,152 failures, that takes from about 10 days to about 4 months, depending on how often you retry. |
Two details shape everything else. Let's Encrypt says it has no way to temporarily reset a limit, and revoking certificates doesn't reset one either. Once you hit a limit, you wait for the bucket to refill.
The New Orders refill works out to about 100 orders an hour, or roughly 2,400 a day, on top of the 300-order burst. That is our arithmetic from the published refill rate. For most products it is plenty. Let's Encrypt's own example puts 250 new certificates a day plus 15,000 renewing certificates "well within our limits" in its February 2026 post on rate limits.
The registered-domain limit follows the Public Suffix List. Customer domains such as shop.customer-a.example and app.customer-b.example usually sit on different registered domains, so they rarely touch it. Tenant subdomains such as acme.yourapp.com all share yourapp.com, and they hit it quickly. Because this limit counts across every ACME account, certificates a customer's own team issues under their domain draw from the same 50 a week as yours.
Renewals are mostly exempt, especially with ARI
ACME Renewal Information (ARI) lets the CA tell your client when to renew each certificate. Let's Encrypt says renewals made through ARI are exempt from all rate limits, as long as the order includes at least one hostname from the certificate it replaces and that certificate hasn't already been replaced through ARI.
Renewals without ARI, for the exact same set of hostnames, are exempt from New Orders per Account and New Certificates per Registered Domain. They still count against the authorization failure limits and the exact-set limit. A renewal that fails validation because a customer moved their DNS still costs you failures.
The integration guide asks large integrators to check ARI at least twice a day, keep a backstop of renewing with a third of the lifetime left, and renew "in small runs" above 10,000 hostnames.
Shorter lifetimes change renewal volume, not the limits
As of October 2026, the default Let's Encrypt certificate lasts 90 days. That is changing on a published schedule from the 45-day announcement and the 64-day update.
- May 13, 2026: the opt-in
tlsserverprofile started issuing 45-day certificates. - October 14, 2026: the staging environment switched to 64-day certificates.
- February 10, 2027: the default
classicprofile issues 64-day certificates, and authorization reuse drops to 10 days. - February 16, 2028: the default moves to 45-day certificates, with authorization reuse of 7 hours.
Let's Encrypt says rate limits won't change for this, because renewals are exempt. It also expects shorter lifetimes to roughly double the number of renewal requests each day. Its advice is direct: renewing at a hardcoded 60-day interval will no longer be sufficient. Use ARI, or renew at about two thirds of the lifetime.
Shorter lifetimes mean more frequent renewals, so a customer whose DNS has drifted away from you will start failing validation sooner. That makes DNS monitoring and failure backoff more important, not less.
How DIY setups run into the limits
The limits rarely bite in normal operation. They bite during specific events, often at the worst time.
- Bulk onboarding. A large customer imports 2,000 hostnames, or you migrate your existing domains onto a new proxy. Every new certificate is a new order, and the 300-order burst runs out in minutes.
- Retry storms on broken customer DNS. Customers add a domain in your dashboard before they change DNS, or they get the record wrong. A loop that retries every few minutes uses up the 5-per-hour failure limit for that hostname, and over weeks it moves the hostname toward a pause. At 10 failures a day, the pause arrives after about 128 days. At 120 a day, it arrives after 10 days.
- Lost certificate storage. A container or new node that issues at startup without durable storage asks for the same certificates again. The integration guide warns this is "likely to hit rate limits", and the exact-set limit allows only 5 a week.
- Renewal waves after a migration. Certificates issued in one batch expire in one batch. Without ARI, they all renew in the same window and any that fail validation pile up together.
- Testing against production. Load tests and CI runs that request real certificates spend the same budget your customers need.
- An unrestricted on-demand TLS setup. Servers that obtain certificates during the first TLS handshake must restrict which hostnames they will issue for, and current Caddy requires a permission check before it enables on-demand TLS. Caddy's automatic HTTPS docs say on-demand TLS "must be both enabled and restricted to prevent abuse."
How to stay under the limits
None of this needs exotic engineering. It needs a few rules applied consistently.
- Only issue for claimed hostnames. Keep an allow-list of hostnames that a tenant has added, and refuse everything else before contacting a CA. For on-demand TLS, Caddy calls this the ask or permission endpoint. Its global options docs say the endpoint should answer in a few milliseconds and avoid DNS queries or other network requests.
- Check DNS before you order. Don't place an order for a hostname that doesn't point at you yet. Poll DNS on your side, which costs nothing against CA limits, and order once it resolves correctly.
- Back off on failed validation. Use exponential backoff per hostname. The integration guide suggests capping retries at once per day per certificate. Stop retrying hostnames whose tenant has left.
- Store certificates durably and share them. Every node serving a hostname should read the same certificate and account data. Caddy's docs note that instances using the same storage coordinate certificate management as a cluster.
- Renew with ARI and spread the load. ARI renewals are exempt from all limits. Keep the one-third-of-lifetime backstop and renew large fleets in small runs.
- Pace bulk imports. Queue large onboarding batches and release them at a rate under the New Orders refill, or about 100 an hour.
- Ask for an override early. The rate limit adjustment form covers New Orders per Account and New Certificates per Registered Domain. Let's Encrypt says requests take a few weeks, so file it before a big launch, not during one.
- Test against staging. Point development and CI at Let's Encrypt's staging environment. Caddy already switches to staging during retries "to avoid rate limit concerns."
- Monitor expiry yourself. Let's Encrypt stopped sending expiration emails on June 4, 2025. Track certificate expiry, validation failures and CA errors per hostname.
Multiple accounts and a second CA
Spreading orders across several ACME accounts looks like an easy way around New Orders per Account. It doesn't help with the registered-domain limit, which counts across all accounts. The integration guide also recommends that large hosting providers use a single account, because Let's Encrypt "will be unable to effectively adjust rate limits if many different accounts are used." One account plus an override is the supported path.
A second certificate authority is a better hedge. Caddy uses Let's Encrypt by default and adds ZeroSSL as a fallback issuer when an account email is configured. ZeroSSL's ACME documentation requires External Account Binding credentials and describes unlimited 90-day certificates at no charge, but it doesn't publish numeric ACME rate limits. Plan as if it has some. Also remember that a customer's CAA records must authorize every CA you might fall back to, or the fallback fails for that hostname.
Our custom domains guide covers the HTTP-01 and DNS-01 choice, and the onboarding checklist explains why DNS can be verified while a certificate is still pending.
When a managed service is the simpler choice
Running issuance yourself is reasonable when you have a few hundred domains, a team that already operates ACME clients, or a hard requirement to hold every key on your own servers. The work grows with scale: an allow-list service on the hot path, shared certificate storage, backoff state per hostname, ARI, override requests, a second CA and expiry monitoring. Our DIY comparison walks through those costs.
We built Approximated so SaaS teams don't have to run that part. We issue certificates on demand only for hostnames configured as virtual hosts, so unknown names are refused before any certificate authority is contacted. We work with multiple certificate authorities, so if one can't issue a certificate, issuance falls back to another. Renewals run automatically.
A customer's DNS still has to point at your cluster before a certificate can be issued, and their CAA records must allow the certificate authorities we use. We report DNS, SSL and proxy-hit status through our virtual-host monitoring and webhooks, so your product can show when a domain is still waiting on the customer. Our pricing is public per domain.
Frequently asked questions
How many new certificates can a SaaS get from Let's Encrypt per day?
As of October 2026, one ACME account can place 300 new orders in a burst, refilling one every 36 seconds. That is about 100 an hour or 2,400 a day sustained, by our arithmetic from the published refill rate. Hostnames under one registered domain are separately capped at 50 new certificates a week. Let's Encrypt accepts override requests for both limits.
Do Let's Encrypt renewals count against rate limits?
Renewals made through ACME Renewal Information (ARI) are exempt from all Let's Encrypt rate limits. Renewals without ARI for the exact same hostnames are exempt from the new-orders and registered-domain limits, but still count against authorization failures and the exact-set limit. Shorter certificate lifetimes from February 2027 increase renewal volume, and Let's Encrypt says the limits won't change.
What happens when a customer's DNS is wrong and validation keeps failing?
Each account can fail validation for one hostname 5 times an hour before new orders for it are blocked. After 1,152 consecutive failures, refilling one per day, Let's Encrypt pauses issuance for that hostname until you unpause it through the self-service portal linked in the error. Check DNS before ordering and back off to once a day.
Should I use multiple ACME accounts to avoid Let's Encrypt rate limits?
Usually not. Extra accounts raise the per-account order limit but not the registered-domain limit, which counts across all accounts. Let's Encrypt's integration guide recommends a single account for large hosting providers, because it can't adjust limits effectively across many accounts. Use one account, request an override, and add a second CA as a fallback.
Can Let's Encrypt reset a rate limit I've already hit?
No. Let's Encrypt says it has no way to temporarily reset a limit, and revoking certificates doesn't reset one. Limits refill gradually, so capacity returns over hours or days. The override form raises the new-orders and registered-domain limits for the future, but processing takes a few weeks, so file it before a large launch.