SMTP error codes explained: reading a bounce message

A bounce message contains the exact reason your mail was refused, stated twice: once as a three digit SMTP reply code and once as an enhanced status code of the form 5.7.1. Most people read the human sentence that follows and stop, but the sentence is written by whoever configured the receiving server and is frequently vague or misleading. The codes are standardized, and reading them tells you whether to retry, fix your configuration, or remove the address.

The three digit reply code

The first digit is the whole decision:

A 4xx is a soft bounce: the server is telling you to try again, and a well behaved sender retries with backoff for a day or more before giving up. A 5xx is a hard bounce: the answer will not change, and continuing to send damages your sending reputation. Suppressing hard bounced addresses immediately is not politeness, it is the single most important thing you can do for deliverability.

The remaining two digits identify the category, and the ones you meet in practice are:

• 421 service not available, closing channel. Usually rate limiting or a busy server.
• 450 mailbox unavailable, temporarily. Often greylisting.
• 451 local error in processing. The receiver's problem, retry.
• 452 insufficient storage. Mailbox full, or too many recipients at once.
• 550 mailbox unavailable. The dominant hard bounce: the address does not exist, or you have been blocked.
• 551 user not local. Relay refused.
• 552 message size exceeds limit.
• 553 mailbox name not allowed. Malformed or rejected sender address.
• 554 transaction failed. A catch all rejection, commonly policy or reputation based.

The enhanced status code

The three digit code is coarse, so RFC 3463 adds a second code with far more resolution, in the form class.subject.detail. The class repeats the temporary or permanent verdict (4 or 5), and the subject is where the real information lives:

The codes worth memorising:

• 5.1.1 bad destination mailbox address. The address does not exist. Remove it from your list; there is nothing to fix on your side.
• 5.1.10 recipient address has null MX. The domain has explicitly declared that it accepts no mail.
• 5.2.2 mailbox full. Sometimes reported as 4.2.2 and retried.
• 4.4.1 no answer from host. The receiving server is unreachable. Check the domain's MX records resolve to hosts that are actually listening.
• 5.7.1 delivery not authorized, message refused. The most common policy rejection, and almost always an authentication problem: SPF failed, DMARC policy rejected, or your address is blocked.
• 5.7.25 reverse DNS does not match. The sending IP has no valid PTR record, or it does not match forward DNS.
• 5.7.26 multiple authentication failures. Neither SPF nor DKIM aligned, and the receiver requires at least one.
• 4.7.0 / 4.7.1 temporary policy rejection, which is what greylisting and rate limiting look like.

Reading a real bounce

Bounce messages carry a machine readable part that most mail clients hide. It looks like this:

Reporting-MTA: dns; mail.example.com
Final-Recipient: rfc822; user@recipient.com
Action: failed
Status: 5.7.1
Diagnostic-Code: smtp; 550 5.7.1 Unauthenticated email from example.com is not
 accepted due to domain's DMARC policy.

Final-Recipient is the address that failed, which can differ from the one you addressed if forwarding was involved. Status is the enhanced code. Diagnostic-Code is the receiving server's verbatim response, and the part after smtp; is what you should paste into a search or a support ticket, not the summary sentence at the top of the mail.

The full journey of the message, including which servers handled it and what each authentication check returned, is in the headers. Paste them into the email header analyzer rather than reading them by hand; how to read email headers explains what each one means.

What causes the ones you will actually see

550 5.7.1 with a mention of SPF, DKIM, or DMARC. Your sending source is not authorized for your domain. Check the domain's records with the email health checker; the usual causes are a new sending service missing from the SPF record, an SPF record exceeding the ten DNS lookup limit, or a DKIM signature that does not align with the From domain. SPF, DKIM, and DMARC explained covers what each check actually verifies.

550 naming a blocklist. Your sending IP is listed. Check with the blacklist checker and work through why is my IP blacklisted. Delisting is per list and each has its own process.

421 or 4.7.0 in bursts. You are sending too fast for the receiver, common when a new sending IP has no reputation. Slow down and warm up; retries will succeed.

450 on a first attempt that then works. Greylisting: the receiver rejects unknown senders once and accepts the retry, on the theory that spam software does not retry. This is normal and needs no action beyond honouring the retry.

5.7.25. Your sending IP lacks a matching reverse DNS entry. Set the PTR record with whoever owns the IP, usually your hosting provider, and verify with the reverse DNS tool.

554 5.7.1 with no detail. Usually content or reputation based filtering with a deliberately uninformative message, since explaining the rule would help spammers. If your authentication is clean and the IP is unlisted, this is a reputation problem, and the remedy is the slow one: consistent volume, low complaint rates, and clean lists.

A quick diagnostic order

1. Read the enhanced status code, not the sentence.
2. 4xx means wait; 5xx means stop sending to that address.
3. For any x.7.x, check domain authentication first with the email health checker.
4. For x.1.x, the address is the problem, and suppression is the fix.
5. If several receivers reject at once, look at your IP and domain reputation rather than the individual message.

Working through the email deliverability checklist once removes most of the recurring causes before they generate bounces at all.