Bounce codes by provider: what Gmail, Microsoft and Yahoo send

No mail server has ever told you a bounce was "hard" or "soft". Those are labels your sending

tool applies after the fact. What the server actually sends is a three-digit reply code whose

first digit decides everything: a 4xx reply is a deferral and the same message should be

retried later, a 5xx reply is permanent and retrying it is pointless. Everything else -

whether to suppress the address, whether to slow down, whether to look at your own

configuration - comes from the free text and the enhanced status code, not from the word

"bounce".

Getting that one distinction right fixes most bounce-handling bugs. Suppressing an address

because a 450 arrived throws away a good contact. Retrying a 550 5.1.1 forever keeps a dead

address in your list and keeps your bounce rate high.

The reply class, in one table

The second part matters more than most guides admit. A 550 5.7.1 is permanent, but it is

permanent *about you* - your IP, your authentication, your content. Suppressing the recipient is

the wrong response; they are fine. A 550 5.1.1 is permanent *about the address*, and that is

the only family that justifies a suppression list entry.

Gmail and Google Workspace

Gmail is the most verbose major receiver, which makes it the easiest to diagnose.

The 552 5.2.2 case is the one classifiers routinely break on. The code is a 5xx, so naive

rules file it as permanent and suppress the address - but the mailbox is merely full, and it will

very likely accept mail next week.

Microsoft 365 and Outlook.com

Microsoft splits its estate: outlook.com consumer mail and Exchange Online tenants behave

differently and emit different enhanced codes.

550 5.4.1 Recipient address rejected: Access denied. [AM0PR...]
550 5.7.1 Unfortunately, messages from [203.0.113.10] weren't sent. Please contact your
          Internet service provider since part of their network is on our block list
          (S3150). You can also refer your provider to
          http://mail.live.com/mail/troubleshooting.aspx
550 5.7.606 Access denied, banned sending IP [203.0.113.10]
451 4.7.500 Server busy, please try again later

Read these carefully, because two of them look alike and mean opposite things. `550 5.4.1 Access

denied` on a tenant usually means the address does not exist - Exchange Online returns the same

reply for a non-existent mailbox and a blocked one so that directory harvesting does not work.

550 5.7.606 and the S3150 family are IP reputation blocks on Microsoft's side and have nothing

to do with the recipient. 4.7.500 is throttling: honour it, do not hammer it.

Yahoo and AOL

Yahoo runs AOL, so both answer with the same bracketed internal codes. The bracket is the useful

part.

421 4.7.0 [TSS04] Messages from 203.0.113.10 temporarily deferred due to user complaints
554 delivery error: dd This user doesn't have a yahoo.com account (test@mailpilots.in)
421 4.7.0 [TS03] All messages from 203.0.113.10 will be permanently deferred

TSS04 is a complaint-driven deferral - the most common Yahoo failure for cold senders, and it is

a 4xx, so the message is not lost yet. TS03 is the one to worry about: a "permanent deferral"

is Yahoo's phrasing for a block, and no amount of retrying clears it. The 554 delivery error: dd

string is Yahoo's unknown-user reply and is the only one in that list that should suppress an

address.

Zoho and smaller providers

Smaller hosts tend to reject earlier in the conversation rather than send a bounce later. Zoho,

Fastmail and most cPanel/Exim hosts verify the recipient at RCPT TO and refuse there, which

means your SMTP library sees the error inline instead of receiving a delivery status notification

by mail. Functionally it is the same information arriving sooner. They are also stricter than the

large providers about authentication alignment, so a domain that scrapes by at Gmail is often

refused outright by a small strict host.

The ordered fix when bounces spike

1. Separate the classes before anything else. Count 4xx and 5xx independently. A spike

that is all 4xx is a rate or reputation problem. A spike that is all 5xx 5.1.1 is a list

problem.

1. Read the enhanced code's middle digit. .1 is addressing, .2 is the mailbox, .4 is

network and routing, .7 is policy and security. .7 always means the receiver is making a

judgement about you.

1. Suppress only `.1.1`-family permanent failures. Unknown user, no such domain, null MX.
2. For any `.7` family, stop sending from that mailbox and fix the cause. Check SPF, DKIM and

DMARC alignment first, since authentication failures are cheap to fix and produce the same

rejection as a genuine reputation problem.

1. For `4xx`, reduce concurrency and volume and let the queue retry. Deferrals are

instructions, not errors.

What not to do

• Do not suppress a recipient on a `4xx`. This is the most expensive bounce-handling bug

there is. A deferral says nothing about the address.

• Do not treat `552 5.2.2` as a dead address. The mailbox is full. Retry in a few days.
• Do not retry a `5xx` on a schedule. It will fail identically every time and the repeated

attempts are themselves a negative signal.

• Do not rotate to a new IP or domain to escape a `.7` rejection. The rejection is about

behaviour, and the behaviour follows you.

• Do not aggregate all providers into one bounce rate. Gmail deferring while Microsoft accepts

is a specific, fixable diagnosis that an averaged number hides completely.

MailPilot keeps these signals separated. It warms mailboxes over OAuth for Gmail and Outlook or

over SMTP/IMAP for SendGrid, Amazon SES, Mailgun, Postmark and custom servers, measures inbox

placement per provider using a seed-inbox network rather than averaging everything into one

figure, and records per-mailbox reputation daily - so a Yahoo deferral pattern is visible as a

Yahoo problem instead of a vague dip.