SMTP Response Codes - What 2xx, 4xx and 5xx Actually Mean

Every SMTP reply starts with 2, 4 or 5, and that first digit is the whole verdict. 2xx means accepted. 4xx means try again later, the message stays queued. 5xx means rejected permanently, the message bounces. There are 3xx codes too, but they only appear mid-conversation while the server waits for more input.

Get that one distinction right and most bounce handling becomes obvious.

The three classes

The practical rule: never retry a 5xx, never delete on a single 4xx. Both mistakes are common and both are expensive. Retrying 5xx responses looks like spam behaviour to receiving servers. Deleting on a first 4xx throws away subscribers whose mailbox happened to be full that morning.

What you will actually see at volume

The codes that matter in bulk sending, by how often they show up:

2xx   250 OK                    accepted, nothing to do
      251 forwarded

4xx   421 service unavailable   you are being throttled
      450 mailbox unavailable   temporary, often rate limiting
      451 local error           greylisting lives here
      452 insufficient storage  mailbox full, or too many recipients

5xx   550 mailbox unavailable   address dead, or you are blocked
      552 storage exceeded      message too large
      553 mailbox name invalid  bad address format
      554 transaction failed    content or reputation rejection

Two of these carry more weight than the rest. 421 at volume almost always means the receiving server is rate limiting you, not that it is broken. 550 is ambiguous by design: it covers both "this address does not exist" and "we are refusing your mail", and the text after the code is what separates them.

Reading the enhanced code

Modern servers add a three-part code after the basic one, defined in RFC 3463:

550 5.7.1 Message blocked
    │ │ │
    │ │ └── detail
    │ └──── subject: 7 = policy / security
    └────── class: 5 = permanent

The subject digit is the useful part:

So 5.1.1 is a dead address, a list hygiene issue. 5.7.1 is a block, a reputation issue. Same 5xx class, completely different response from you. Sorting your bounce log by the subject digit tells you in a minute whether you have a list problem or a reputation problem.

What to do with each

2xx. Nothing. Accepted is not the same as delivered to the inbox, though. A 250 followed by silence usually means the message landed in spam, which is a placement problem, not a delivery one.

4xx. Let the queue do its job. Retry timing backs off automatically, and the whole window is typically 4 to 5 days. If the same domain defers everything you send, you are being throttled and the fix is slower sending, not more retries. Details in why your email is stuck in the queue.

5xx. Remove the address immediately if the subject digit is .1 or .2. If it is .7, the address is fine and your sending reputation is the problem, so removing subscribers will not help. Work the IP or domain reputation instead.

Sorting bounces this way is the single highest-value thing you can do with your log, and most senders never do it.

The classic mistakes

• Treating every bounce as a hard bounce. Deleting on 4xx quietly shrinks your list by a few percent per send.
• Retrying 5xx responses. Some homegrown senders do this. Receiving servers read it as abuse.
• Ignoring the enhanced code. The basic 550 tells you almost nothing on its own.
• Not logging the text after the code. Providers put the actual reason there, often with a delisting URL.

How BulkEmailSetup helps

Bounce classification is part of the build, not something you wire up afterwards. We set up dedicated SMTP infrastructure with bounce and complaint handling that separates 4xx deferrals from 5xx rejections automatically, keeps list hygiene clean, and stops dead addresses quietly eroding your sender reputation.

Basic starts at $549 one-time, covering 1 SMTP server, 3 dedicated IPs, 25,000 emails/day and unlimited contacts. See pricing, or read SMTP bounce code classes for the deeper reference.

Frequently asked questions