Email Throttling: Connection, Rate and Volume Control

Anil Jalela · Published Mar 3, 2026 · 13 min read

Throttling controls how quickly an outbound system opens connections, submits recipients and retries temporary failures. It protects receivers, sender reputation and the local queue. A single global rate is rarely sufficient because mailbox providers expose different capacity, reputation and error states. Control must be provider-aware, stream-aware and adaptive, while permanent failures remain outside the retry loop.

Control the correct dimensions

Use token buckets for predictable bursts

A token bucket adds tokens at a configured rate up to a burst capacity. A send consumes a token; without one, work waits. Pair it with a semaphore for concurrent connections and limits for recipients or messages per connection. Begin conservatively from observed acceptance, not an undocumented universal number.

key = receiver_org + sending_ip + stream
if circuit_open(key): defer_local()
if token_available(key) and connection_slot(key): attempt()
else: schedule_next_eligible_time()

Classify SMTP responses before adapting

A 2xx acceptance supports cautiously maintaining or increasing rate. A 4xx is temporary but its text matters: rate limit, reputation, greylisting, mailbox unavailable and system error should not share one backoff. A 5xx is normally terminal for that recipient and must not be retried as if temporary.

Store full replies, enhanced status code, remote host, attempt and queue ID. Provider text changes, so classification needs versioning and an unknown bucket.

Design exponential backoff with jitter

Backoff should lengthen after repeated temporary failures and include jitter so many workers do not reconnect simultaneously. Cap maximum delay and queue lifetime. Reset recovery gradually after sustained acceptance rather than releasing the entire backlog at once.

Never transform a permanent rejection into a retry. Limit attempts per recipient, deduplicate queue entries, and give fresh critical traffic a protected path so an old marketing backlog cannot consume every connection.

Adapt rates from stable windows

Use acceptance ratio, deferral reason, connection failure, latency and reputation telemetry across a rolling window. One timeout should not collapse healthy traffic; a concentrated provider rate-limit response should reduce only that key. Apply minimum sample sizes and hysteresis to avoid rate oscillation.

A circuit breaker opens when a severe condition persists, allows small probes after a cool-down, and closes gradually after recovery. Manual override requires an expiry and audit record.

Protect queue and storage capacity

• Alert on oldest message, not only queue count.
• Reserve disk, workers and connections for transactional streams.
• Expire messages according to business usefulness and SMTP policy.
• Pause new campaign injection before storage becomes critical.
• Reconcile accepted recipients so retries cannot duplicate delivery.

During recovery, drain by receiver and age under the current safe rate. A fast queue drain can recreate the incident.

Throttle by receiving organization, not only recipient suffix

Several domains can share one MX platform, while one visible domain can route through different infrastructure. Resolve and maintain a governed receiver-organization map using MX patterns and current provider knowledge. Keep raw domain for diagnosis, but apply connection/rate state to the accountable receiving network.

Version mapping changes. A sudden MX migration can merge queues that previously had independent limits.

Combine token buckets, concurrency and connection reuse

state_key = receiver_org + outbound_ip + stream

if circuit(state_key) == OPEN: hold()
else if connection_slot_available(state_key)
     and token_bucket.consume(recipient_cost):
    use_or_open_connection()
else:
    schedule(next_eligible_time)

Tokens bound rate over time and burst capacity; a semaphore bounds simultaneous connections. Separately control recipients/messages per connection where current provider feedback or documented policy supports it. Reuse healthy SMTP sessions to reduce TLS/connection overhead, but honor receiver session termination.

Do not publish one universal Gmail/Yahoo/Microsoft concurrency number. Controls are dynamic and provider-specific. Start conservatively from observed accepted traffic and full replies.

Classify full SMTP replies before changing rate

Keep an unknown family and parser version. Provider wording changes.

Use exponential backoff with jitter and a bounded queue lifetime

delay = min(max_delay,
            base_delay * (2 ** consecutive_failures))
delay = delay * random(0.8, 1.2)
next_attempt = now + delay

stop retrying when:
  final permanent response,
  message business expiry,
  or configured SMTP queue lifetime

Jitter prevents synchronized workers from creating a retry storm. Track attempts per recipient and deduplicate queue entries. Do not reset failure state on one acceptance when the broader window remains degraded. Conversely, one timeout should not collapse an otherwise healthy provider route.

Adapt using stable windows, hysteresis and minimum samples

Inputs can include acceptance ratio, deferral family, connection failure, latency, oldest queue age, complaints and provider telemetry. Use fast protection and slower recovery. Hysteresis avoids oscillating between rates on minor changes.

Log rate version, inputs, decision and manual override expiry. Never let a dashboard operator increase rate without an auditable timeout.

Protect critical streams without bypassing receiver safety

Use separate logical queues and reserved worker/disk capacity for security codes, receipts, lifecycle and promotions. Priority does not exempt transactional mail from authentication, recipient validity or receiver deferrals. Avoid starvation: an old promotional backlog needs expiry and controlled service, not infinite retention.

dispatch order within receiver safety envelope:
  1. current security/service messages
  2. time-sensitive transactional
  3. expected lifecycle
  4. marketing by age and business expiry

all classes share receiver circuit and permanent-failure rules

Cancel obsolete mail before dispatch. A password code delivered after expiration wastes capacity and harms user experience.

Model queue and egress capacity before campaigns

Forecast recipients by receiver/hour, message size, campaign injection, expected connection reuse, retry reserve and failure scenarios. Track p50/p95 send latency and oldest queue age. Disk capacity should include retries and log overhead with a safe stop before exhaustion.

Control campaign injection before the MTA queue becomes the limiter

Campaign systems should request capacity by stream and receiver distribution. Reject, delay or split a launch when queue age, disk, circuit state or suppression freshness is unsafe. Once millions of recipients enter the MTA, cancellation and prioritization become harder.

admit(campaign) only if:
  recipient_snapshot_fresh
  AND suppression_feed_current
  AND projected_queue_age < business_expiry
  AND disk_headroom_after_retry_reserve
  AND no_severe_receiver_circuit_for_material_share

Store admission decision, forecast and approver. Marketing urgency cannot override a stale complaint feed or critical storage threshold.

Worked case: retries amplify a Yahoo deferral

A campaign injects eight million recipients rapidly. Yahoo returns temporary policy deferrals. Workers retry immediately, open more connections and triple reply events while unique recipient progress stalls. Queue count and disk grow; transactional Yahoo mail waits behind the promotion.

Operators stop new campaign admission, reduce the Yahoo/IP/promotion key, apply jittered backoff and reserve capacity for current transactional messages within the same receiver safety envelope. They preserve full replies and find the original audience included a newly reactivated inactive cohort.

The cohort is stopped rather than moved to another IP. After complaints and deferrals stabilize, probes and controlled wanted traffic restore rate gradually. Permanent controls add per-receiver admission forecasts, unique-recipient versus event metrics and a circuit breaker.

Monitor scheduler decisions, not only delivery totals

• Unique recipients attempted/accepted/deferred/rejected.
• Reply events and retries per recipient.
• Connections open, reused, failed and terminated.
• Token balance, configured/effective rate and version.
• Circuit state and reason by receiver/IP/stream.
• Queue count, bytes, oldest age and business expiry.
• Admission holds and canceled obsolete messages.
• Manual overrides with owner and expiry.

Alert on unknown reply share and missing source data. Recovery is sustained acceptance and controlled queue age, not merely an empty queue after discarding mail.

Control the complete SMTP connection lifecycle

Track DNS lookup, connect, banner, EHLO, STARTTLS, authentication where applicable, MAIL, RCPT, DATA and final reply latency. A connection slot held by slow TLS or content submission reduces useful capacity differently from a quick recipient rejection. Set timeouts by stage using standards and observed provider behavior.

Use the receiver’s live responses. If it closes after a bounded number of messages, reconnect cleanly; do not assume a historical number applies permanently.

Prevent duplicate delivery during ambiguous connection failure

If the connection drops before the sender receives the final DATA response, the sender may not know whether the receiver accepted the message. SMTP retry can produce duplicates. Use stable Message-ID, idempotent application semantics where possible and clear transaction logs. Never mark delivered without a positive final response, but recognize that retry is at-least-once behavior.

attempt(
  queue_id, recipient_id, connection_id,
  mail_transaction_id, data_started_at,
  final_reply_received, final_reply,
  disconnect_stage, next_attempt_at
)

Reconcile final replies per recipient. A server accepting some RCPTs and rejecting others requires split disposition. Preserve uncertainty when a post-DATA disconnect occurs.

Use throttling during new IP, domain and stream changes

A warm-up is a controlled introduction of representative wanted traffic, not a fixed daily doubling schedule. Segment by receiving organization and observe acceptance, deferral, complaints and business response. Keep aligned domains stable and avoid changing IP, audience, content and cadence simultaneously.

After a long quiet period or failover to a cold address, restart conservatively.

Throttle and contain compromised credentials or tenants

Per-provider rate limits cannot stop an attacker if one credential consumes the entire allowed rate. Add tenant, API key, source application and template dimensions. Compare traffic with campaign plans and historical hour-of-week behavior. Enforce absolute caps, anomaly holds and credential revocation.

if tenant_volume > approved_plan
   OR new_recipient_rate anomalous
   OR template/link identity unknown:
    hold tenant
    revoke_or_challenge credential
    preserve submission and auth logs

Do not move suspicious traffic to spare IPs. Security containment precedes deliverability recovery. After rotation, confirm queues contain no attacker-submitted mail before reopening.

Test the scheduler with deterministic failure simulations

• Repeated 421/451 rate deferrals for one receiver.
• Greylisting followed by acceptance after delay.
• Permanent 550 for one recipient among accepted recipients.
• Connection drop before and after final DATA reply.
• DNS/MX change while messages are queued.
• Circuit open, half-open probes and recovery.
• Disk/admission threshold and transactional reserve.
• Worker restart without duplicate queue entries.

Use a controlled SMTP test server, never generate harmful load against mailbox providers. Assert rate, retries, jitter bounds, queue state and final recipient disposition. Keep fixtures with scheduler version.

Keep failover from becoming an uncontrolled cold-IP burst

Inventory active, standby, warming, draining and retired routes. When an active IP fails, calculate available warm capacity by receiver rather than shifting the entire backlog instantly. A spare route must have valid PTR/HELO, SPF, aligned DKIM, TLS, feedback ownership and monitoring.

Drain the failed route safely and prevent the same queue item from existing on both paths without idempotent coordination. During restoration, choose whether to keep traffic on failover temporarily or rebalance gradually. Frequent ping-pong destroys stable observation.

Test route loss during an approved exercise and measure recipient progress, duplicates, queue age and receiver response.

Use additive recovery and multiplicative reduction as a simple adaptive pattern

on stable window with sufficient accepted recipients:
  rate = min(configured_ceiling, rate + additive_step)

on concentrated receiver pressure:
  rate = max(safe_floor, rate * reduction_factor)

do not update when sample is insufficient or telemetry is stale

This pattern increases cautiously and reduces quickly, but parameters must be tested against real traffic. Separate rate from concurrency and burst capacity. Use hysteresis/cool-down so several workers do not fight. Never let an algorithm interpret permanent recipient errors as a reason to retry more slowly.

Make message usefulness part of queue policy

Store expiry per message class. SMTP queue lifetime and business usefulness are related but different; the stricter safe limit should prevent obsolete delivery.

Keep receiver policy as reviewed configuration

receiver_policy:
  organization: example-provider
  mx_patterns: ["*.provider.example"]
  initial_rate: reviewed baseline
  burst: bounded
  max_connections: observed safe ceiling
  retry_families: versioned mapping
  circuit_rules: minimum sample + cool_down
  owner: deliverability-operations
  reviewed_at: 2026-08-29

Do not copy these illustrative fields as real provider values. Store why a limit exists, evidence window and last review. Configuration changes need peer review and a rollback. Automatically expire emergency overrides.

Compare effective runtime state with repository configuration; a stuck manual override can otherwise persist unnoticed.

Coordinate throttling across workers and regions

A per-process token bucket can multiply total rate by worker count. Use a consistent distributed budget or partitioned allocation with bounded error. Define behavior during coordination-store failure: fail safe, use a conservative local reserve, and prevent every region from assuming it owns full capacity.

Test failover and recovery without production-provider load. Reconcile total observed connections/rate across regions.

Operational response to a sudden provider slowdown

1. Stop new injection for the affected material share.
2. Preserve full replies, unique recipients, retries and queue age.
3. Confirm receiver mapping and affected IP/stream/tenant.
4. Classify temporary versus permanent causes.
5. Reduce the precise state key and open a circuit if severe.
6. Contain harmful cohort or compromised credential.
7. Probe after cool-down and restore additively.
8. Drain wanted unexpired backlog under current safe rate.

Close after oldest queue age, acceptance, complaints and business latency recover across a sustained window. An empty queue caused by expiration or deletion is not delivery recovery.

Define service objectives by stream and receiver

Set objectives for time-to-first-attempt, final acceptance, oldest queue age and business expiry by message class. Report percentiles and breach minutes, not only averages. A global delivery-time SLO can hide Outlook security-code delays behind fast Gmail promotions.

Objectives guide priorities but never justify bypassing receiver deferrals or suppressions.

Review control effectiveness after campaigns and incidents

Compare forecast versus actual provider distribution, effective rates, reply families, retry amplification, queue peak, oldest age, expirations, duplicates and manual overrides. Identify whether the controller protected independent receivers and critical streams. Tune one parameter at a time in a test or bounded release.

Keep incident fixtures for deferral, greylisting, post-DATA disconnect, region loss and recovery. Remove obsolete receiver overrides and review MX mappings. The desired outcome is stable wanted acceptance with bounded queues, not maximum throughput in an unconstrained test.

Throttling production checklist

• Map domains to receiving organizations.
• Key state by receiver, IP and stream.
• Bound rate, burst and connections separately.
• Classify complete replies with unknown state.
• Use jittered bounded retries only for temporary failures.
• Protect queue disk, age and message expiry.
• Reserve critical capacity without bypassing receiver safety.
• Coordinate budgets across workers/regions.
• Contain tenants and credentials independently.
• Recover gradually and audit overrides.

Re-run failure simulations after scheduler, MTA, provider-map or routing changes.

Keep an accountable owner

Assign owners for scheduler code, receiver mappings, reply classification, campaign admission, queue capacity and incident overrides. Review contacts and escalation paths before peak campaigns and infrastructure migrations.

Approval record

Retain the tested scheduler version, effective limits, campaign forecast, reviewers, release time and rollback conditions for every material control change.

Primary references

• RFC 5321 SMTP
• RFC 3463 Enhanced Status Codes
• Google email sender guidelines

Continue learning

• SMTP Error Codes
• Postfix Queue Backlog Runbook
• Improve Yahoo Deliverability