InboxGrade

SMTP 421 4.7.0 — temporary rate limit (greylist/throttle)

The receiving MTA has temporarily deferred your message with a `421 4.7.0` policy response, usually because sending rate, connection count, or sender reputation crossed a throttling threshold.

Impact — Medium impact

Messages are not rejected outright — they sit in your outbound queue and retry per RFC 5321 backoff, so delivery is delayed by minutes to hours. Transactional traffic (password resets, receipts, OTPs) misses its time-sensitive window and users refresh or re-request, compounding the queue. Sustained 421 4.7.0 responses from Gmail or Microsoft are an early signal that your sending IP or domain reputation is slipping toward a hard block.

What causes it

  1. Sudden volume spike from a sending IP with no prior history at that destination — Gmail and Outlook ramp trust slowly and throttle anything that looks like an unwarmed burst.
  2. Reputation degradation on the sending IP or From domain: rising spam complaints, spam-trap hits, or high unknown-user rates triggering our system has detected an unusual rate of unsolicited mail.
  3. Too many concurrent SMTP connections or messages-per-connection from one IP — Microsoft 365 enforces per-IP concurrency limits and returns 421 4.7.0 once exceeded.
  4. Classic greylisting: the receiver defers the first attempt from an unknown IP + MAIL FROM + RCPT TO tuple and expects a retry 5–15 minutes later.
  5. Shared IP neighbor abuse — another tenant on the same outbound IP damaged reputation, and the receiver is throttling the whole IP.

How to fix it

Confirm it is deferral, not rejection, and let the queue retry

A 4.x.x code is transient. Inspect the queue to confirm messages are scheduled to retry rather than being bounced to senders. On Postfix, list and flush the deferred queue after you have addressed the underlying cause.

postqueue -p | tail -n 20
postqueue -f   # flush deferred queue once reputation issue is resolved

Pull the exact enhanced status code and remote host

The remediation depends on which receiver is throttling. Grep your MTA log for 421 4.7.0 to see whether it is gmail-smtp-in.l.google.com, *.protection.outlook.com, or another provider — each has a distinct throttling policy and documentation URL embedded in the response.

grep -E '421 4\.7\.0' /var/log/mail.log | awk '{print $7, $8, $NF}' | sort -u

Throttle outbound concurrency and warm the IP

If the receiver is Microsoft or Gmail, reduce default_destination_concurrency_limit and default_destination_rate_delay in Postfix (or the equivalent in your MTA) and ramp volume over 2–4 weeks. Split transactional and marketing streams onto separate IPs so a marketing spike cannot throttle password resets.

# /etc/postfix/main.cf
default_destination_concurrency_limit = 5
default_destination_rate_delay = 1s
smtp_destination_rate_delay = 1s

Check reputation and sign up for feedback loops

Verify the sending IP and domain in Google Postmaster Tools and Microsoft SNDS/JMRP. If domain reputation is Low or Bad, no amount of throttling will fix it — you need to cut spammy segments, enforce double opt-in, and process complaint feedback loops before volume will scale again.

Fixed it? Run a fresh test to confirm.

Test my inbox →

Related errors