What is a transient delivery failure?

A transient delivery failure is the receiving mail server saying "not right now, try again later." The message is not rejected for good. It is parked. The sending server is expected to queue it and retry on a schedule.

You see these as 4xx SMTP response codes in your logs or bounce reports. The first digit matters: 4 means temporary, 5 means permanent. A 4xx tells the sender to hold the message and come back later. A 5xx tells the sender to give up and bounce the message back. For the full split, see 4xx vs 5xx error codes.

What actually triggers a 4xx

A handful of real-world causes show up over and over:

• Mailbox full. The recipient has not cleared their inbox and is over quota. You will usually see 452 4.2.2 Mailbox full or similar.
• Receiving server overloaded. The destination is short on resources or under heavy load. Common code: 421 4.7.0 Try again later.
• Rate limiting by the recipient. Gmail, Yahoo, and Microsoft will throttle you if you send too fast from a cold IP or a domain with no reputation. Gmail documents this directly in their postmaster bulk sender guidelines.
• Greylisting. The receiver intentionally rejects the first attempt from an unknown sender with a 4xx, and accepts the retry a few minutes later. Spammers usually do not retry. Legitimate mail servers do.
• Temporary DNS or network issue. The receiving MX is unreachable or a lookup times out. Once the network heals, the next retry goes through.
• Policy-based deferral. The recipient is suspicious of your authentication, IP reputation, or content, but not suspicious enough to permanently reject. They want you to try again so they can re-evaluate.

When your ESP marks a message as "deferred," that is the same event from the sending side. See what deferred means and what happens after a deferred message retries for the sender's side of the loop.

How retries work

RFC 5321 section 4.5.4.1 sets the rules. The sending server queues the message and retries on a backoff schedule. The retry interval should be at least 30 minutes. The total queue lifetime should be at least 4 to 5 days before the message gives up and converts to a permanent bounce.

Most production mail servers and ESPs follow this. Postfix, for example, retries with exponential backoff and gives up after about 5 days by default. Once the queue lifetime expires, the transient failure is converted to a hard bounce and sent back to the original sender as a non-delivery report (NDR). For how that report is built, see how bounce messages are generated.

What you should do about it

If you are sending from your own server or seeing a few 4xx codes in your ESP logs, do nothing. The retry handles it. That is the whole point of the 4xx range.

If you are seeing a high rate of 4xx codes from one mailbox provider, that is a signal:

• A wall of 421 4.7.0 from Gmail means you are sending too fast or your IP reputation is dropping. Slow down. Warm the IP. Check that SPF, DKIM, and DMARC pass.
• A wall of 452 4.2.2 mailbox full across many recipients means your list is stale. Old addresses get abandoned, fill up with spam, and stop being cleared.
• A wall of 451 or 450 greylisting on a small portion of recipients is normal. Let the retries do their job.

The practical rule: a transient failure on one message is noise. A pattern of transient failures across a campaign is a deliverability problem in disguise. Treat the codes as a feedback channel from the recipient. They are telling you what to fix.