SMTP retries and deferrals: why mail sits in the queue

SMTP has two kinds of failure. A 5xx is permanent: the message is rejected and your server generates a bounce. A 4xx is temporary: the message stays in your queue and your server tries again later. Most "slow email" complaints are 4xx responses being handled badly at one end or the other.

Read the class, then the code

421 4.4.2 Connection timed out
450 4.2.0 Mailbox temporarily unavailable
451 4.7.1 Greylisted, try again later
451 4.7.500 Server busy, please try again later
452 4.2.2 Mailbox full
452 4.5.3 Too many recipients

The single most expensive mistake is suppressing recipients behind a 4xx. Those addresses are valid. Deleting them shrinks your list and does nothing about the cause.

How a retry schedule should behave

A sane MTA retries with increasing intervals — minutes at first, then tens of minutes, then hours — and gives up after a configured lifetime, at which point it returns a delivery failure. The lifetime varies by software and configuration; many defaults sit somewhere between one and five days, and hosted platforms are often shorter. Check your own rather than assuming.

Two settings matter more than the schedule itself:

• Concurrency per destination. Twenty simultaneous connections to one provider is how a reputable sender gets 421-ed. Few connections, steady pace.
• Jitter. If every deferred message retries at exactly the same moment, you recreate the burst that caused the deferral.

Greylisting is not a problem to solve

Greylisting temporarily rejects mail from an unfamiliar sender on first contact and accepts it on a later attempt, on the theory that unsophisticated spam software never comes back. A compliant sender experiences a short delay once per sender–recipient pair and nothing afterwards.

You cannot opt out, and you should not try. What you can do is make sure your retry logic actually retries promptly — the senders who suffer under greylisting are the ones whose first retry is three hours away, or who treat the 451 as a bounce.

Reputation throttling looks the same but is not

This is the case that matters for cold outreach. When a receiver is unsure about you, it accepts mail slower than you offer it. Microsoft is the most explicit about it:

451 4.7.500 Server busy, please try again later
451 4.7.650 The mail server [203.0.113.10] has been temporarily rate limited

and Yahoo, which shares its filtering stack with AOL, names the cause outright:

421 4.7.0 [TSS04] Messages from 203.0.113.10 temporarily deferred due to
 unexpected volume or user complaints

Retrying harder does not help, because the limit is a function of trust rather than of server capacity. The fixes are a slower ramp, sends spread through the working day instead of one batch, a steady volume floor rather than stop-start sending, and lower complaint rates. Deferrals thinning out while volume holds steady is the clearest signal that reputation is improving; deferrals rising while volume is flat means complaints, not rate.

Measure the delay rather than guessing

Received headers are timestamped, so queue delay is a number:

Received: from mail.yourdomain.com (203.0.113.10) by mx.provider.net;
 Wed, 15 Oct 2026 10:12:44 +0000
Received: from app-sender-2 (10.0.0.4) by mail.yourdomain.com;
 Wed, 15 Oct 2026 09:41:08 +0000

Thirty-one minutes between your MTA and the receiver's edge is deferral, not transit. Cross-reference your mail log for the 4xx responses in that window and you have the cause.

On the Google side, delivery errors are also reported in Postmaster Tools v2 alongside spam rate, authentication and compliance status — useful for spotting a trend, though it will not give you per-message detail. Keep your spam rate under the 0.30% bulk-sender threshold and ideally below 0.10%, because the complaint rate is what drives reputation throttling in the first place.

What not to do

• Do not suppress recipients that produced a `4xx`. They are deliverable.
• Do not retry immediately and repeatedly. Backoff is both correct and faster overall.
• Do not raise concurrency to clear a backlog. You will convert deferrals into connection refusals.
• Do not retry a `5xx` at all. It is permanent, and the attempts accumulate as reputation damage.
• Do not let every queued message retry at the same instant. Add jitter.
• Do not interpret a quiet queue as good placement. Accepted mail includes spam-foldered mail.

How MailPilot helps

MailPilot classifies the SMTP responses its sends receive, so a temporary deferral is retried with backoff and a permanent rejection is not retried at all — and a mailbox is not stopped for someone else's throttling. Warm-up over OAuth or SMTP/IMAP ramps gradually and spreads sends through the day, which is what reduces reputation-driven deferrals, and inbox placement is measured per provider rather than inferred from acceptance.