A bounce is a message from a mail server explaining why yours was not delivered. They are long, they quote headers, and the useful part is usually two lines.
The first digit
Every bounce carries a status code, and the first digit decides how to respond.
5xx, permanent. The message was refused and will not be accepted if you send it again. Something must change: the address, the content, or your server's standing.
4xx, temporary. The receiving server could not take it now. Your server retries automatically, usually for several days, and most of these resolve without anyone doing anything.
Treating a 4xx as a failure and resending manually creates duplicates. Treating a 5xx as temporary means sending repeatedly to an address that will never accept it, which damages your reputation.
The codes worth recognising
550. The most common permanent failure. Either the mailbox does not exist, or the server refused you. The accompanying text distinguishes them and this is where reading it matters.
552. Over quota, or the message is too large. Some servers report a full mailbox as 452, which is temporary instead.
554. Refused, usually for reputation or content. Frequently the one that names a blocklist.
421. Temporarily unavailable, often rate limiting. Sending faster makes it worse.
451. Temporary local error, including greylisting: deliberately refusing a first attempt to see whether a legitimate server retries. It will succeed shortly, and this is a normal delay rather than a fault.
The sentence is the diagnosis
The code is a category. The text the receiving server attached is usually the answer.
"No SPF record found" names a DNS record you are missing. "Listed at" names a blocklist. "Message rejected due to content" is a filter. "User unknown" is a wrong address, and no amount of server configuration will fix it.
Read that line before anything else. Most time wasted on delivery problems is spent investigating a general theory when the bounce named the specific cause.
Bounces you cause and bounces you receive
These are different situations and they get confused.
Your mail bounced. Somebody refused it. The fix depends on the reason, and SPF, DKIM and DMARC goes over the largest category.
You are receiving bounces for mail you never sent. Someone is forging your domain, and their failures come back to you. Annoying and not a compromise. Stopping your domain being used for spoofing goes into reducing it.
What is worth checking is whether the bounces reference your actual server. If they do, an account really is sending and needs attention immediately.
The problem that produces no bounce
The hardest delivery problem does not bounce at all.
The receiving server accepts the message, then files it as spam. Your logs record a successful delivery. The recipient never sees it. Nothing anywhere reports a failure.
A bounce, by comparison, is a message telling you exactly what to fix. The silent case is why "some of our email does not arrive" is a much worse report than "our email bounces".
Confirm which you have by checking the mail log: a successful delivery there means the problem is at the far end, not yours. There is more on reading it in Exim configuration and mail routing.
Bounces from a mailing list
Sending to a list produces bounces in volume, and how you handle them is what preserves your ability to send at all.
Remove permanently failing addresses immediately. Continuing to send to addresses that do not exist is one of the clearest signals that a sender is not maintaining their list, and receiving systems act on it.
Temporary failures should be retried, then removed after several consecutive failures.
This is one of several reasons bulk sending belongs on a service built for it rather than on your hosting account. Sending a newsletter properly goes into it.
When there is no bounce and no delivery
Occasionally mail simply does not arrive and nothing is reported. Check the queue on your own server first; a message still queued has not failed yet, and the queue will say what it is waiting on.
The email troubleshooting guide explains working through it.
The enhanced code carries the detail
Alongside the three-digit reply code, most servers return a second, finer code in the form of three numbers separated by dots. It is more specific than the reply code and is frequently ignored.
The middle number is the useful part. A code beginning 5.1 concerns the address itself; 5.2 concerns the mailbox, typically full or disabled; 5.7 concerns policy, which covers authentication failures, blocklisting and content refusal.
So 550 5.1.1 and 550 5.7.1 are the same reply code and entirely different problems: the first is a wrong address, the second is a refusal on policy grounds. Only the second is worth investigating on your side.
Reading that second code first saves the most common wasted effort in mail diagnosis: checking DNS records for what turns out to be a typo in an address.
Delays are not failures
A message that has not arrived is frequently still in progress, and treating that as a failure produces duplicates.
A sending server retries a temporary rejection for several days before giving up, with increasing intervals. Many send a delay notification after a few hours, which reads like a bounce and is not one.
exim -bp | grep '[email protected]' exim -Mvl MESSAGE-ID
A message still in the queue has not failed. Resending it manually creates a second copy that will also be delivered, which is worse than waiting. There is more on reading the queue in Exim configuration and mail routing.
Automatic replies are not bounces either
Out-of-office replies, ticket acknowledgements and challenge messages all arrive looking like delivery reports and are none.
The distinction matters for anything processing bounces automatically: treating an out-of-office as a hard failure removes a perfectly good address from a mailing list.
Genuine delivery reports carry a specific content type and come from the mail system rather than from a person. Anything relying on bounce handling should check that rather than matching on subject lines, which is how legitimate recipients get unsubscribed by mistake.
Keep the address list clean before it matters
Hard failures are a maintenance signal, not just an event.
An address that returns a permanent failure should be removed on the first occurrence, not the third. Continuing to send to addresses that do not exist is one of the clearest indications to a receiving system that a sender is not maintaining their list, and it affects delivery for every other recipient.
Where the sending goes through a relay, that removal is usually automatic and worth confirming rather than assuming. There is more on the reporting that shows it in sending application email through a relay service.