$ guides / postfix / postfix-rate-limited-by-destination ▌

Operations Guides

Postfix rate limited by destination: 421 and 4.7.1 throttling from major providers

When a major email provider starts throttling your Postfix server, the symptom is distinctive: mail to that one provider defers while everything else flows. You see 421 “too many connections” or 4.7.1 rate-limit responses in your mail logs, the deferred queue fills with messages to that domain, and retries with exponential backoff make the pile worse. Other destinations deliver normally.

Postfix itself is not malfunctioning. The remote MX is enforcing per-IP or per-domain rate limits, and Postfix’s queue manager is correctly deferring and retrying. The problem is that your sending pattern exceeds what the provider will accept, or your IP reputation has degraded to the point where the provider tightens those limits.

What this means

Major providers like Gmail, Microsoft 365, and Yahoo enforce unpublished per-IP and per-domain limits on inbound SMTP connections and message volume. When you exceed them, the remote MX returns a 4xx temporary failure. The specific codes vary:

421 4.7.1 from a provider typically means rate-limiting on connections or messages. Gmail also uses 421 4.7.0 for broader policy concerns (authentication, content, sender reputation) and 421 4.7.28 specifically for volume-based rate limiting on your sending IP.
Microsoft 365 enforces a recipient-per-day limit (commonly cited as 10,000 recipients/day for Exchange Online). Exceeding it produces throttling responses.
Yahoo applies functionally enforced limits (roughly 500 to 1,000 recipients/day for new senders, though unpublished).

Postfix treats all of these as deferrals. The smtp delivery agent logs status=deferred, the queue manager schedules a retry with exponential backoff, and the message sits in the deferred queue. If the deferral reason is rate-based and you keep sending at the same volume, each retry cycle adds more messages to the pile.

The key distinction:

Transient burst throttling: you sent too many messages or opened too many connections in a short window. Lowering your concurrency or adding a rate delay resolves it within minutes to hours.
Reputation throttling: the provider has flagged your IP or domain. Deferrals persist regardless of how slowly you send. Recovery requires pausing sending (often 24 to 48 hours for Gmail rate-based deferrals), warming up gradually, and addressing the underlying reputation issue.

A third possibility is that the provider is genuinely overloaded or has a transient issue. This is rare but worth ruling out by checking whether the deferrals are consistent or intermittent.

flowchart TD
    A["Deferrals to one provider"] --> B{"421 or 4.7.1\nin deferred logs?"}
    B -->|No| C["Check DNS, TLS,\nconnectivity separately"]
    B -->|Yes| D{"Only that provider\naffected?"}
    D -->|No, all destinations| E["Systemic issue:\nDNS, port 25, master"]
    D -->|Yes| F{"Deferrals persistent\nat low volume?"}
    F -->|Yes| G["Reputation throttling:\npause, warm up,\ncheck blocklists"]
    F -->|No, burst only| H["Rate throttling:\nlower concurrency\nor add rate_delay"]
    H --> I["Verify queue drains\nover next hour"]
    G --> I

Common causes

Cause	What it looks like	First thing to check
Concurrency too high for provider	421 “too many connections” from one provider; mail to others flows	`postconf default_destination_concurrency_limit`
Burst volume exceeded provider cap	Sudden spike in deferrals after a campaign or batch send; gradual recovery	Injection rate vs. delivery rate in logs
IP reputation degradation	Persistent deferrals regardless of rate; 421 4.7.0 from Gmail	Blocklist checks, sender score
rate_delay set without raising failed_cohort_limit	Destination goes “dead” after one 421; all mail to it stops	`postconf default_destination_concurrency_failed_cohort_limit`
Concurrency ramp overshoot	Scheduler ramps through 5, 10, 15, 20; triggers 421 at some step	`postconf initial_destination_concurrency`

Quick checks

# Check: which destination domains dominate the deferred queue?
grep 'status=deferred' /var/log/mail.log | grep -oE 'to=<[^>]+>' | grep -oE '@[^>]+>' | tr -d '@>' | sort | uniq -c | sort -rn | head

# Check: what reason is the provider giving?
grep 'status=deferred' /var/log/mail.log | grep -oE 'said:.*' | sort | uniq -c | sort -rn | head

# Check: current destination concurrency and rate settings
postconf -h default_destination_concurrency_limit initial_destination_concurrency default_destination_rate_delay default_destination_concurrency_failed_cohort_limit

# Check: non-default settings (what you have changed from stock)
postconf -n

# Check: active and deferred queue sizes
postqueue -p | tail -1
find /var/spool/postfix/deferred -type f | wc -l

# Check: delivery vs. deferral ratio in recent log lines
tail -n 2000 /var/log/mail.log | awk '/status=sent/{s++} /status=deferred/{d++} END{printf "sent: %d, deferred: %d\n", s+0, d+0}'

# Check: is mail to other providers flowing?
tail -n 2000 /var/log/mail.log | grep 'status=sent' | grep -oE 'to=<[^>]+>' | grep -oE '@[^>]+>' | tr -d '@>' | sort | uniq -c | sort -rn | head

Note: on RHEL/CentOS the mail log is /var/log/maillog, not /var/log/mail.log. On systemd-based hosts, use journalctl -u postfix instead.

How to diagnose it

Confirm the deferral reason. Search the logs for the specific SMTP response code. The enhanced status code tells you whether this is volume-based, general policy, or connection-based. This determines your response.
Confirm only one provider is affected. If deferrals cluster on Gmail but Microsoft and Yahoo mail flows, the problem is provider-specific rate limiting or reputation. If all destinations defer, look at DNS, port 25 connectivity, or the master process instead.
Check your current concurrency and rate settings. If default_destination_concurrency_limit is at its default of 20 and initial_destination_concurrency is 5, the scheduler ramps concurrency in linear steps: 5, 10, 15, 20. Each step can overshoot a provider’s connection cap and trigger 421 before the scheduler backs off.
Check whether the destination went “dead.” If you have a non-zero destination_rate_delay, the default default_destination_concurrency_failed_cohort_limit of 1 means a single failed pseudo-cohort marks the destination as dead and halts all deliveries to it. Look for “dead” or “connection rate” messages in the logs.
Measure the gap between injection and delivery. If your injection rate consistently exceeds delivery rate for that provider, you are accumulating deferred messages faster than you drain them. This confirms a capacity mismatch.
Check your sender reputation externally. Query common blocklists (Spamhaus, Barracuda, UCEPROTECT) and check your sender score. Reputation problems produce persistent throttling that no concurrency tuning will fix.
Determine burst vs. persistent. Look at the time distribution of deferrals. If they started after a specific campaign or batch send and are gradually clearing, it is likely a burst. If they persist at low volume over hours or days, it is reputation-based.

Metrics and signals to monitor

Signal	Why it matters	Warning sign
Per-destination deferred count	Shows which provider is accumulating mail	One domain dominates deferred queue
Deferral reason codes (421, 4.7.1, 4.7.0)	Distinguishes rate from reputation from policy	Persistent 4.7.0 indicates reputation
Delivery rate per provider	Confirms whether only one provider is affected	Rate to one provider drops while others hold
Active queue utilization	Tells you if one destination is monopolizing slots	Active queue near `qmgr_message_active_limit`
Deferred queue growth rate	Velocity matters more than absolute size	Sustained positive growth over 1+ hours
Injection vs. delivery ratio	Capacity mismatch indicator	Injection consistently exceeds delivery
Concurrency to specific destination	Whether you are within provider tolerance	Hitting `destination_concurrency_limit` with 421s

Fixes

Lower destination concurrency for the throttled provider

The fastest immediate relief is to reduce how many parallel connections Postfix opens to the affected provider:

# Reduce concurrency for the smtp transport (applies to all destinations)
postconf -e 'smtp_destination_concurrency_limit=5'
postfix reload

This is a blunt instrument. It lowers concurrency to all destinations, not just the throttled one. Use it for immediate stabilization, then switch to a per-transport throttle for a permanent fix.

Tradeoff: lower concurrency means slower delivery to that provider. If you have a large backlog, it takes longer to drain. But sustained 421s mean the provider will not accept faster delivery anyway.

Create a per-transport throttle for specific providers

For a permanent fix, create a dedicated transport for the throttled provider with its own concurrency and rate settings. This isolates the throttle so other destinations keep their default settings.

Add to master.cf:

gmail    unix    -    -    n    -    -    smtp

Then set transport-specific parameters in main.cf and create a transport map:

# Route gmail.com through the dedicated transport
postconf -e 'transport_maps=hash:/etc/postfix/transport'
postconf -e 'gmail_destination_concurrency_limit=3'
postconf -e 'gmail_destination_rate_delay=2s'
postconf -e 'gmail_destination_concurrency_failed_cohort_limit=50'
postfix reload

And in /etc/postfix/transport:

gmail.com    gmail:

Run postmap /etc/postfix/transport after editing. Verify the master.cf entry took effect with postconf -M gmail.

This isolates the throttle. Other destinations keep their default concurrency and rate. You can create separate transports for each provider that throttles you.

Set destination_rate_delay correctly

default_destination_rate_delay inserts a delay between message deliveries to the same destination over the same transport. The default is 0s (disabled).

Critical gotcha: when destination_rate_delay is non-zero, concurrency to that destination is effectively 1. The delay is applied between deliveries on a single connection. Setting both destination_concurrency_limit=5 and destination_rate_delay=1s does not give you 5 parallel connections each sending one message per second. It gives you 1 connection sending one message every second.

If you need true parallelism with rate limiting, use multiple transports or IP addresses. If you need simple rate limiting, accept the single-connection model and set the delay to space out sends.

Raise failed_cohort_limit when using rate_delay

When you set a non-zero destination_rate_delay, you must also raise default_destination_concurrency_failed_cohort_limit (or the transport-specific equivalent). The default of 1 means a single pseudo-cohort failure, such as a transient 421, marks the destination as dead and stops all deliveries to it.

# Raise the failed cohort limit for transports using rate_delay
postconf -e 'default_destination_concurrency_failed_cohort_limit=50'
postfix reload

Or set it per-transport: gmail_destination_concurrency_failed_cohort_limit=50.

Without this change, a single 421 from the provider halts all mail to that destination until the dead-destination timer expires and the scheduler retries.

Address reputation issues

If deferrals persist at low volume, the problem is reputation, not concurrency. No amount of Postfix tuning will fix it. Steps:

Pause sending to the affected provider. Recovery typically requires 24 to 48 hours of paused or minimal sending from that IP.
Check blocklists. Query Spamhaus, Barracuda, and UCEPROTECT for your sending IP.
Review bounce and complaint rates. High bounce rates (above 1% sustained) or complaint rates degrade reputation and tighten provider limits.
Verify authentication. Ensure SPF, DKIM, and DMARC are correctly configured for your sending domain. Missing or broken authentication triggers provider throttling.
Warm up gradually. When resuming, start with low volume and increase over days. Do not resume at full rate.

Prevention

Know your provider limits. Gmail, Microsoft, and Yahoo do not publish exact per-IP connection or message caps. Treat their limits as unknown and conservative. Set your concurrency low enough that you never trigger 421 under normal load.
Monitor per-destination deferral rates. A spike in deferrals to one provider is the earliest signal. Do not wait for the deferred queue to grow large before investigating.
Use per-transport throttles proactively. If you regularly send high volume to a major provider, set up a dedicated transport with conservative concurrency and rate settings before you get throttled.
Watch the concurrency ramp. With initial_destination_concurrency=5, the scheduler grows concurrency in steps of 5: 5, 10, 15, 20. If a provider’s limit falls between those steps, you will overshoot and trigger 421 before the scheduler backs off. Set initial_destination_concurrency lower for sensitive providers.
Monitor sender reputation continuously. Check blocklists and sender scores weekly at minimum. Reputation degradation is gradual and reversible if caught early.
Spread sends over time. For batch or campaign sends, use destination_rate_delay or an external scheduler to spread volume across hours rather than minutes.

How Netdata helps

Per-destination deferred queue tracking shows which provider is accumulating mail before the overall queue size becomes alarming.
Correlating delivery rate against injection rate in a single view reveals the capacity mismatch as it develops, not after the queue has grown.
Anomaly detection on deferral rates surfaces a sudden spike in 421 or 4.7.1 responses to one provider, even when absolute numbers are still small.
Active queue saturation metrics show whether one slow destination is monopolizing queue slots and blocking other mail from being scheduled.
Deferred queue growth velocity (not just absolute size) is the leading indicator that separates a transient blip from a sustained problem.