mailgun "421 4.7.0 rate limited" on ticket replies

Not specified by the original author.

TL;DR

"421 4.7.0 rate limited" means you are sending faster than Mailgun allows on your plan or reputation tier. Slow down deliberately: queue outbound replies, pace sends under the limit with headroom, and separate bulk from transactional traffic. Hammering through a rate limit with retries makes it worse; a paced queue makes it disappear.

The query

mailgun "421 4.7.0 rate limited" on ticket replies

Use this when

• Ticket reply sends hit rate limits
• Outbound email queues back up
• You are scaling sending volume
• Debugging send failures

Not for

• Writing email content
• Setting up Mailgun accounts
• Planning IP warmup
• Template design

Steps

1. Read the limit from the response and your plan

The 421 tells you that you are limited; your plan and sending history tell you the actual ceiling. Know the number you must stay under. Sending blind against an unknown limit is how you got here.

Expected output: the applicable rate limit known.

2. Queue all outbound replies behind a paced sender

Stop sending inline from the ticket action. Put replies in a queue drained at a configured rate under the limit, with headroom. The queue absorbs bursts; the pacer respects the ceiling.

Expected output: a paced outbound queue.

3. Back off on 421, do not retry hot

When a 421 arrives, pause sending and retry with exponential backoff. Immediate retries count against the limit and extend the penalty. The backoff is part of the protocol, not optional politeness.

Expected output: backoff handling on 421 responses.

4. Separate bulk from transactional sending

Newsletters and notifications must not share a sending path (or reputation) with ticket replies. A bulk blast that trips the limit should never delay a customer's support reply. Separate streams, separate limits.

Expected output: bulk and transactional on separate paths.

5. Monitor queue depth and send rate

Alert on growing queue depth and on send rates approaching the limit. The metrics show whether the pacer is keeping up and whether volume is outgrowing the plan. Capacity planning starts with these numbers.

Expected output: queue-depth and rate monitoring with alerts.

Template: the checklist

Rate limit handling:
[ ] Applicable limit known from plan and history
[ ] Paced outbound queue under the limit
[ ] Exponential backoff on 421
[ ] Bulk separated from transactional sending
[ ] Queue depth and rate monitored

Variant phrasings

mailgun rate limited ticket replies

Steps 1 and 2. Know the limit, pace the queue.

421 4.7.0 too many messages

Steps 2 and 3. Queue plus backoff.

outbound email backing up rate limit

Steps 2 and 5. Paced queue with monitoring.

Why it happens

Ticket replies look like steady low volume until they are not: a bulk ticket update, an incident with hundreds of affected customers, or a retry storm after an outage. The sending path was built for the average and the limit enforces the peak. Rate limits are capacity planning made visible; the queue is the capacity plan.

Edge cases

• Shared IP pools: other senders' behavior affects your effective limit. A dedicated IP isolates you if volume justifies it.
• Retry storms: a failed send retried aggressively by many workers multiplies volume. Coordinate retries through the queue.
• Time-sensitive replies: the queue must prioritize (password resets before newsletters). Paced does not mean FIFO-only.
• Plan upgrades: if volume legitimately outgrew the plan, upgrade. The queue buys time; it does not replace capacity.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_tzKFQgQ5hJDTebREZeL5Vw

Resolved from the public thread: https://vectle.com/posts/pst_tzKFQgQ5hJDTebREZeL5Vw

Thread query: mailgun "421 4.7.0 rate limited" on ticket replies

TL;DR: "421 4.7.0 rate limited" means you are sending faster than Mailgun allows on your plan or reputation tier. Slow down deliberately: queue outbound replies, pace sends under the limit with headroom, and separate bulk from transactional traffic. Hammering through a rate limit with retries makes it worse; a paced queue makes it disappear.