Email Throttling slowing the flow, not stopping it

When throttling is the right move

• IP warmup. A brand-new IP has no reputation. Sending 100K emails on day one will get you blocked. The standard warmup ramp throttles deliberately: ~50 on day one, doubling roughly every other day, taking 4-6 weeks to reach full volume.
• Reputation recovery. After a spam trap hit or a complaint spike, slowing volume gives the receiving providers time to re-evaluate. Sending hard during recovery deepens the damage.
• Per-ISP rate limits. Yahoo and Outlook in particular publish (informal) per-domain hourly send rate caps. Exceed them and you start getting 421s.
• Soft bounce response. Sustained 4xx responses from one destination signal you need to slow down to that destination. Continuing at full rate turns soft bounces into hard ones.
• Capacity protection. If your downstream platform is having a bad day, throttling outbound prevents a queue backlog from cascading.

Self-throttling vs receiver throttling

Two different things wearing the same name:

• Self-throttling. Your sending platform decides to slow down. Usually proactive (warmup, reputation protection) or reactive (response to bounce trends). You control it.
• Receiver-imposed throttling. The mailbox provider decides you're too fast for their comfort and starts returning 421 responses. You don't control it; you read the response codes and respond accordingly. Common at Gmail and Outlook when you ramp too aggressively.

Both kinds get logged the same way (deferred queue, retry-after timing), but the operational response is different. Self-throttling means you're driving; receiver-throttling means you're being driven.

How throttling shows up in your logs

• 421 responses. "Service temporarily unavailable, try later." The most common explicit throttle signal. Should trigger an exponential backoff retry.
• Connection refusals or slow connects. Receivers can throttle by simply slowing the TCP layer. Harder to spot than 421s but the symptom is dropped throughput.
• Increased 450s. "Mailbox temporarily unavailable." Sometimes a real mailbox issue, often a throttle disguise. Pattern across many addresses at one domain points to throttle.
• Specific per-provider patterns. Yahoo's CFL feedback can trigger automated throttle. Outlook's SNDS reputation API shows throttle status directly.

Throttling vs pausing vs freezing

Three responses that get blurred together but mean different things:

• Throttle. Slow down. Volume continues, rate decreases. Reversible automatically when conditions improve.
• Pause. Stop temporarily. Volume halts; the queue holds. Usually time-bound (resumes after N minutes/hours).
• Freeze. Stop indefinitely until a human or process intervenes. The most severe response.

A good platform escalates through these in order: throttle first (least disruptive), pause if throttle doesn't help, freeze only if pause fails. Skipping straight to freeze on the first sign of trouble usually causes more harm than the original signal.

How sendmsg.io throttles

The Cortex engine runs per-domain, per-activity, and per-mailbox-provider throttles in parallel. The decision loop sits on top of the temperature score for each entity. Healthy entities run at full rate. As bounce rate, complaint rate, or feedback-loop volume rises, throttle kicks in graduated: first to 75% of capacity, then 50%, then 25%, then to a pause if those don't stabilise the signals. Recovery walks back the same ladder: if 5 clean minutes go by, the throttle eases by one step.

The principle is graduated response. Most reputation incidents are recoverable if you slow down early. Sending platforms that wait until they see a freeze threshold before reacting always pay more than the ones that throttle early. Reputation management at its core is this: catch the slope, before it becomes the cliff.