Understanding Bounce Messages and SMTP Codes
When a message cannot be delivered you get a bounce, and buried in it is a numeric code that tells you exactly why, whether it will ever succeed, and whose end the problem is at.
Most people read the human sentence at the top of a bounce, decide it is unhelpful, and give up. The sentence is written by whichever server rejected the mail and is often vague. The code is not. This article is a reference for the codes you will actually see, and what to do about each one.
How to Read a Bounce
A bounce carries two numbers.
The reply code is three digits, like 550 or 451. The first digit is the one that matters:
- 4xx is temporary. The receiving server could not take the message right now. Your mail server will keep retrying for a period, and it may well succeed on its own. Do nothing yet.
- 5xx is permanent. The receiving server will never accept this message. Retrying changes nothing. Something has to change first.
The enhanced status code is three numbers separated by dots, like 5.1.1 or 4.2.2. It gives the specific reason and follows the same rule: a leading 5 is permanent, a leading 4 is temporary.
So 550 5.1.1 User unknown is permanent and means the address does not exist. 452 4.2.2 Mailbox full is temporary and means try later.
If a bounce does not obviously say what is wrong, search the web for the exact enhanced status code plus the receiving provider's name. Every large provider publishes its own code list, and that page will tell you precisely what they mean by it, which is often more specific than the standard definition.
Permanent Failures (5xx)
| Code | Usually means | What to do |
|---|---|---|
550 5.1.1 | The recipient address does not exist | Check the spelling. If it is right, the address has been closed. Remove it from your records. |
550 5.1.2 | The recipient's domain does not exist or has no mail server | Check the domain spelling. If correct, their domain has no working MX record and it is their problem to fix. |
550 5.7.1 | Refused by policy. The catch-all rejection for authentication failures, blocklistings and content rules | Read the rest of the message. This is the one that usually points at SPF, DKIM, DMARC or a blocklisting. |
550 5.7.26 | The receiving provider requires authentication your domain is not passing | Fix SPF and DKIM. See SPF, DKIM and DMARC Explained. |
551 | The address is not handled here and no forwarding path exists | Use the correct address. |
552 5.2.2 | The recipient's mailbox is over its storage limit, permanently refused | Tell the recipient. Nothing at your end helps. |
553 5.1.3 | The address is syntactically invalid | Fix the address format. |
554 5.7.1 | The transaction was rejected outright, often at connection time | Usually a blocklisting or a hard policy block. See Getting Delisted From a Blocklist. |
Temporary Failures (4xx)
| Code | Usually means | What to do |
|---|---|---|
421 4.7.0 | The receiving service is unavailable or is throttling your connection | Nothing. Retries handle it. If it persists for hours, the receiving provider is rate limiting you. |
450 4.2.1 | The mailbox is temporarily unavailable, often greylisting | Nothing. Greylisting deliberately defers a first-time sender and accepts the retry. |
451 4.3.0 | A local error at the receiving server | Nothing. Retries handle it. |
452 4.2.2 | The recipient's mailbox is full | Nothing immediately. If it persists for days, contact the recipient another way. |
452 4.5.3 | Too many recipients on one message | Split the message into smaller batches of recipients. |
4.4.1 | No answer from the receiving host | Nothing. Their server is down or unreachable. |
4.7.x | A temporary policy block, often reputation-related | Look at your domain's authentication. A young or poorly authenticated domain gets deferred far more often. |
Greylisting is worth recognising because it looks alarming and is completely normal. A receiving server deliberately refuses an unknown sender's first attempt with a 4xx and accepts the retry a few minutes later. If your mail arrives late but arrives, greylisting is the likely cause and there is nothing to fix.
Bounces Generated at the Kapsule End
Some bounces come from our platform rather than the recipient's. These are the ones you have direct control over:
The recipient mailbox is full. A Kapsule mailbox over its storage limit refuses new mail, and the sender receives a bounce saying so. Fix it from your side with My Mailbox Is Full.
The address does not exist. Deleting a mailbox, forwarder, mailing list or shared inbox means mail to that address bounces from then on. The panel warns you about this at the point of deletion. A catch-all on the domain prevents it, at the cost of receiving everything sent to every mistyped address.
A block rule refused it. The Spam filter tab on a mailbox lets you block specific senders and domains, and blocked mail is rejected rather than filed away. If a colleague reports being bounced, check that tab before looking anywhere else.
Egregious spam scoring. Mail scored well past the spam threshold is refused at delivery, so the sender is told it did not arrive. Mail scored moderately is filed in Junk instead, where you can retrieve it. Nothing is silently discarded.
A sending cap was reached. If you are the one being refused when you send, you may have hit the per-mailbox rate limits described in Email Sending Limits.
Hard Bounces Versus Soft Bounces
Bulk senders use two informal terms that map onto the codes above. A hard bounce is a 5xx: the address is dead and should be removed from your list permanently. A soft bounce is a 4xx: a temporary condition worth retrying.
The practical rule is that a hard-bouncing address must come off your list on the first bounce. Continuing to mail addresses that have permanently failed is one of the strongest negative reputation signals there is, and receiving providers treat it as evidence that you do not maintain your lists.
If a large proportion of a send hard-bounces, stop sending. A high bounce rate on one campaign will damage your domain's reputation for weeks afterwards, and every legitimate message you send in the meantime suffers for it. Clean the list, then resume.
Working Out Whose Problem It Is
- Every recipient at every provider bounces. Your domain or your sending configuration. Start with the Deliverability tab on your mailbox and Why Are My Emails Going to Spam?.
- Every recipient at one provider bounces. That provider has a specific issue with your domain or the sending infrastructure. Read the code, then check that provider's postmaster tools.
- One recipient bounces, everyone else is fine. Their address, their mailbox or their organisation's mail rules. Contact them another way.
- It started suddenly with no change at your end. Check whether your domain or the sending infrastructure has been listed somewhere: see Getting Delisted From a Blocklist.
Getting Help
If you have a bounce you cannot interpret, open a support ticket and include the full text of the bounce message, not a summary or a screenshot of the first line. The useful information is in the headers and the final server response, and both are lost when a bounce is paraphrased. Include the time it happened and the recipient address.
Related reading: Why Are My Emails Going to Spam?, Email Sending Limits, Email Not Receiving, and SPF, DKIM and DMARC Explained.