Rate Limits, Retries and Backoff: Sending Reliably When Things Go Wrong

Email rate limits and retries are part of every serious sending system. Networks fail, servers get busy and platforms protect themselves from overload. An application that treats every error the same will either lose messages or hammer a struggling service. This guide explains the types of limits you will meet, how to read the signals you get back, and how to retry in a way that is polite, safe and effective.

Why limits exist

Sending platforms limit traffic for several reasons. They protect shared infrastructure from a single customer using too much of it, they slow down abuse such as a stolen key used to send spam, and they follow the pace that receiving providers accept. Receiving servers apply their own limits as well. A mailbox provider may accept only a certain number of connections or messages from one address at a time, and may answer further attempts with a temporary deferral. Neither kind of limit is a fault. It is a signal to adjust your pace.

Kinds of limit you may meet

The exact numbers depend on your plan and account. Check your dashboard and the API reference for the values that apply to you rather than assuming them.

Step 1: Classify the failure

The most useful habit is to sort every failure into one of three classes before deciding what to do.

• Temporary. The same request might succeed later. Examples are timeouts, network errors, HTTP 429, HTTP 500, 502, 503 and 504, and SMTP replies that start with 4.
• Permanent. The same request will keep failing. Examples are an invalid recipient, a sender that is not verified, and SMTP replies that start with 5.
• Your request is wrong. The request is malformed or unauthorised. Examples are HTTP 400, 401, 403 and 422. Retrying changes nothing until you fix it.

For the meaning of specific SMTP codes, see our guide to SMTP bounce codes.

Step 2: Honour the signals you receive

When a service answers 429, it is telling you to slow down. Many services add a Retry-After header, which gives either a number of seconds or a date. Use it. It is better information than any guess you can make. If there is no header, fall back to your backoff schedule.

HTTP/1.1 429 Too Many Requests
Retry-After: 30
Content-Type: application/json

{"error":"rate_limited","message":"Too many requests"}

The example is illustrative; check your platform reference for the exact fields it returns.

With SMTP, a 421 or 4xx reply to a command means the same thing in a different form. The server asks you to try later. Close the connection politely, wait and open a new one. Do not open many parallel connections to work around the limit, because that is likely to make matters worse.

Step 3: Retry with exponential backoff and jitter

Backoff means waiting longer after each failure. Exponential backoff doubles the wait each time. Jitter adds a random amount so that many clients do not retry in step. A simple and widely used form is to pick a random wait between zero and the current ceiling, then double the ceiling up to a maximum.

delay = 1
for attempt in range(max_attempts):
    response = send(message)
    if response.ok or response.is_permanent:
        break
    wait = response.retry_after or random.uniform(0, delay)
    sleep(wait)
    delay = min(delay * 2, 60)

The sketch uses plain pseudocode. Adapt it to your language and add logging at each failure. The important parts are the cap on the delay, the cap on attempts and the use of the server value when one is supplied.

Set limits on both attempts and age

Every message type needs a deadline. A one-time sign-in code that arrives after fifteen minutes is worse than none, because it may confuse the user. A receipt can be late by an hour without harm. Decide a maximum age per message type, stop retrying when it passes, and tell the user or log a failure. RFC 5321 describes mail servers retrying delivery for days, which suits server-to-server relay. Your application will usually want something much shorter.

Step 4: Avoid duplicates

Retries create a risk. If a request times out, you do not know whether the platform processed it. If you send again, the recipient might get two copies. There are two ways to deal with this.

1. Idempotency keys. This is a widely used pattern in APIs in which you attach a unique value to a request, and the server treats a repeat of the same value as the same operation. If your platform supports it, generate one key per logical message and reuse it on every retry. Check the API reference to see whether and how it is supported.
2. Your own record. Store a message record with a status before you send. Mark it accepted when the platform returns an identifier. Before any retry, check whether an identifier was already stored.

Step 5: Queue instead of sending inline

Sending mail in the middle of a user request makes the user wait for your slowest dependency. A better design is to write a job to a queue and let a worker send it. The worker can control the pace, retry in the background and spread bursts over time. When a limit is reached, the queue grows for a while instead of users seeing errors.

• Limit the number of workers so that you stay within your concurrency allowance.
• Use a token bucket or a fixed pace to keep requests below your rate limit.
• Send batches where the API accepts several messages per request.
• Give urgent mail, such as sign-in codes, its own queue so that a newsletter cannot delay it.

A worked example: a spike after a product launch

A shop announces a sale. Within a minute, thousands of customers check out and the application tries to send thousands of order confirmations. The platform starts answering some requests with 429. The old code retried immediately in a loop, which kept the application at the limit and slowed every checkout. The new design does three things. Confirmations are written to a queue. Four workers send at a steady pace below the documented request limit. On a 429, a worker reads Retry-After, waits, and retries with jitter, and each message carries a unique key so that no customer receives two confirmations.

During the spike the queue grows and some confirmations arrive a few minutes late. After the spike the queue drains by itself. Customers see a normal checkout, support sees few tickets, and the operations team gets an alert only if the queue age passes a threshold they chose. The same traffic that once caused errors now causes a short delay, which is the goal of a good retry design.

Step 6: Watch and alert

Retries hide problems if you do not look at them. Track a few numbers: how many messages needed at least one retry, how many were abandoned after the last attempt, the age of the oldest queued message, and the share of requests that returned 429. A rise in any of these is an early warning. Our guide to delivery event webhooks shows how to receive the later outcome of each message, which is the other half of the picture: a request can be accepted and the message still bounce later.

Common mistakes

• Retrying permanent errors. It wastes time and, with invalid addresses, can harm your reputation. Record the failure and suppress the address, as described in suppression list management.
• Tight retry loops. Retrying with no delay turns a short problem into a long one.
• No cap. Unlimited retries can fill a queue and keep stale mail alive for days.
• Ignoring Retry-After. The server knows better than your guess.
• Sharing one key across systems. One busy system then uses the limit for all. Use separate credentials, as in our API key guide.
• Retrying after bad credentials. A 401 or 535 will not fix itself. Alert a person.

If you have not yet decided between SMTP and an API, read our comparison of SMTP and API sending. The rules in this guide apply to both.

Further reading and sources

• RFC 5321: Simple Mail Transfer Protocol (see the section on queue and retry behaviour)
• RFC 9110: HTTP Semantics (status codes and the Retry-After header)
• RFC 6585: Additional HTTP Status Codes (429 Too Many Requests)