Why are temporary failures different from hard bounces?

A temporary failure means "try again later." A hard bounce means "stop trying, this address is dead." Treating those two the same is one of the fastest ways to wreck a sender reputation, because every retry on a real 5xx is wasted, and every permanent suppression of a 4xx is a real subscriber you just deleted.

The SMTP protocol splits responses by the first digit of the three-digit reply code. 4xx is a transient negative reply: the server is refusing the message right now but the same message could succeed later. 5xx is a permanent negative reply: the server is telling you not to retry. That distinction is defined in RFC 5321 section 4.2.1, and every legitimate mailbox provider follows it.

What 4xx codes actually mean

A 4xx is the receiving server saying "not now." Common examples you will see in your bounce logs:

• 421 - service not available, the server is shutting down the connection. Often load shedding at a big provider.
• 421 4.7.0 from Gmail - IP throttled for sending too fast or with too many complaints in a short window. See Google's postmaster docs on temporary errors.
• 450 4.2.1 - mailbox temporarily unavailable. Could be the user is over quota right now and will clear it tomorrow.
• 451 - local error in processing, try again.
• 452 4.2.2 - mailbox is full.
• 452 4.5.3 - too many recipients in one envelope.
• 4xx greylisting - the server is intentionally rejecting first attempts from unknown IPs and expects you to retry in a few minutes. Standard anti-spam tactic.

If you treat any of those as a hard bounce and suppress the address forever, you lose a real human who would have received the next attempt. ESPs and MTAs are supposed to queue 4xx messages and retry on a schedule, typically every 15 to 30 minutes for the first few hours, then backing off to hourly, then every few hours, up to a 72-hour total retry window. After 72 hours of continuous 4xx, most senders convert the failure to a permanent bounce and stop. That window comes from RFC 5321 section 4.5.4.1 which says "the give-up time generally needs to be at least 4-5 days." Most production senders shorten it to 72 hours to protect reputation.

What 5xx codes actually mean

A 5xx is the server saying "never." The mailbox does not exist, the domain refuses your mail, or the content was rejected outright. Examples:

• 550 5.1.1 - no such user. The mailbox does not exist. This is the textbook hard bounce.
• 550 5.1.2 - domain not found.
• 550 5.7.1 - message refused for policy reasons, often because your IP is on a blocklist or your SPF/DKIM failed.
• 551 - user not local, no forwarding address.
• 552 - message exceeds storage allocation. Borderline case, some senders treat as soft.
• 553 - mailbox name not allowed, often a malformed address.
• 554 - transaction failed. Frequently a reputation block from Microsoft or Yahoo.

With a clean 550 5.1.1, suppress immediately. Do not retry, do not pass go. Every additional attempt against a dead address is a signal to the receiving server that you do not maintain your list, and that signal feeds directly into how providers score you. See how ISPs detect poor hygiene for what they actually watch.

The retry rule of thumb

• 4xx on first attempt: queue and retry. Do not touch the subscriber record yet.
• 4xx for 72 hours straight: treat as permanent, suppress.
• 5xx with a 5.1.1, 5.1.2, or 5.1.6 enhanced status: suppress on first hit.
• 5xx with a 5.7.x policy code: investigate before suppressing. The address may be fine, your reputation may be the problem.

If your ESP collapses 4xx and 5xx into a single "bounced" bucket and removes everything, you are silently shrinking your reachable audience every send. That is one of the silent hygiene issues that tanks list quality without showing up in obvious metrics. A bounce rate that looks fine on paper can hide a steady drip of real subscribers being killed by overly aggressive suppression on transient errors.

Check your bounce logs by SMTP code, not by ESP category. The three-digit code and enhanced status code (the 5.x.x part) tell you exactly what happened. The label your platform sticks on top of it might not.