Email bounces: how to read one, and what each code means

What a bounce is, and the two moments it happens

The word is borrowed from paper and it is the wrong picture. Nothing travels back. A message is handed from server to server, and the last one that still holds it and cannot get rid of it writes a new message — addressed to you, about the old one — and sends that instead. Everything you can learn is in that report, and the report is only as good as the machine that wrote it.

It can be produced at two very different moments, and telling those apart is most of the diagnosis. Two other outcomes look like failures from where you are standing and are not:

So “it bounced” names two things. One is an error your own software showed you and one is a letter a stranger's machine wrote you, and only the second has a report in it to read. The rest of this guide is about that report.

Where the reason actually is

A delivery report is a message in three parts and the shape has been fixed since RFC 3464. The first part is the apology, written for a human by the machine nearest you. The second is the machine-readable block, which is the only part with facts in it. The third is your original message, or just its headers, so that you can tell which one failed.

From: Mail Delivery System <MAILER-DAEMON@mail.example.org>
To: <you@example.org>
Subject: Undelivered Mail Returned to Sender
Content-Type: multipart/report; report-type=delivery-status;
        boundary="B7F21C4"

--B7F21C4
Content-Type: text/plain; charset=us-ascii

I'm sorry to have to inform you that your message could not
be delivered to one or more recipients.

--B7F21C4
Content-Type: message/delivery-status

Reporting-MTA: dns; mail.example.org
Arrival-Date: Tue,  8 Sep 2026 10:14:02 +0000

Final-Recipient: rfc822; sales@example.com
Action: failed
Status: 5.1.1
Remote-MTA: dns; mx.example.com
Diagnostic-Code: smtp; 550 5.1.1 <sales@example.com>: Recipient
        address rejected: User unknown in virtual mailbox table

--B7F21C4
Content-Type: text/rfc822-headers

Read the middle part in this order:

Final-Recipient:

Which address failed. One report can carry a block per recipient, so on a message sent to several people this is how you tell which one it is about — and the others may well have arrived.

Action:

failed is a bounce. delayed is a warning that a server is still trying and has given up on nothing; you may yet get a second report saying it worked. relayed and delivered are not failures at all and are easy to misread as one.

Status:

The enhanced status code — three numbers, meant to be read by software rather than by you. It is the part that is comparable between one provider and another, which the sentences never are.

Diagnostic-Code:

The line that matters. It is the far server's own answer, quoted word for word, carrying its reply code and whatever sentence its administrator wrote. Everything above it is a retelling; this is the original.

Remote-MTA:

Which host said it. Worth a glance whenever the failure is about routing: a hostname you do not recognise usually means the domain's mail is going somewhere you did not expect, or somewhere it only used to go.

The sentence at the very top of the report is not evidence. Your own outgoing server writes it, in whatever wording its software happens to ship with, about a failure it is only passing along. Two identical apologies can sit above two completely unrelated Diagnostic-Code: lines, which is why a bounce read from the top is so often read wrong.

The two numbers, and the digit that decides

A refusal is written like this, and it is three separate things joined by spaces:

550 5.1.1 <sales@example.com>: Recipient address rejected: User unknown

The 550 is the reply code: three digits, defined by SMTP itself in RFC 5321, and the part the protocol needs in order to decide what to do next. The 5.1.1 is the enhanced status code from RFC 3463, added because three digits could not express enough. Everything after it is free text, written by whoever runs that server, and standardised by nothing whatever.

Both numbers begin with the same digit, and that digit is the verdict:

The second number is the subject — what kind of thing went wrong. It is the quickest way to place a code you have never seen before:

Hard bounce

A 5. The address is wrong, gone, or refused as a matter of policy, and sending the same message again changes nothing. Bulk senders drop an address from the list on the first one, because carrying on is what gets a sending domain throttled everywhere at once.

Soft bounce

A 4. A full mailbox, a busy server, a temporary policy refusal. It is retried without anybody's help and usually arrives; you only hear about it if the retries run out first.

Neither term is in any specification. They are the sending industry's shorthand for that first digit, which is — and the shorthand is worth knowing because every deliverability tool you will ever be handed reports in it.

The codes you will actually meet

There are dozens in the registry IANA keeps and about a dozen in ordinary life. These cover very nearly every bounce anybody reads:

Codes outside this list exist and all of them mean something, but a code you have never seen before is almost always a .7. — somebody's policy, described in their own words on the line beside it.

What can and cannot bounce at a temporary address

Almost nothing — and that is worth spelling out, because three of the things people describe as a bounce here are not one:

“User unknown” cannot happen

The server accepts every name on its public domains. anything@grabmail.io is a valid address before anybody has typed it, because there is no list of mailboxes to check it against — so a 5.1.1 from GrabMail is not a thing that exists. How temp mail works underneath has the mechanism in full.

Expiry is not a bounce

A message is deleted 5 days after it arrives, and by then the sending server was told 250 long ago and has forgotten the whole exchange. Nobody is notified, because nothing failed: it was delivered, and then later it was deleted. How long an inbox lasts is the guide for that half.

A form that refuses the address is not a bounce

No mail was sent at all. The site compared the domain against a list and rejected the form; nothing ever reached a mail server, and there is nothing to read. Why sign-up forms block disposable email is a different problem with a different set of answers.

Silence is not a bounce either

If something you were expecting never arrived and nobody sent you a report, the failure — if there was one — happened on the sending side, where you cannot see it. Mail that does not turn up works through the causes in the order worth checking.

That leaves exactly one genuine refusal, and it is the size ceiling. A sending server that announces the size up front is turned away immediately, before a byte is stored:

>>> MAIL FROM:<news@example.com> SIZE=7602176
<<< 552 5.3.4 Message size exceeds fixed limit

A sender that does not announce the size gets the same answer at the end of the message instead, once the bytes have been counted for it. Either way the code is 5.3.4, nothing is stored, and a real person is told by their own mail system — which is the entire reason for refusing at the door rather than accepting and discarding.

There is no plan and no header that raises the ceiling, and no bounce for anything else here: no inbound quota, no rate limit, no refusal because somebody is already using the name. On a shared domain two people who type the same name simply share the mailbox, which is a privacy property rather than a delivery one.

Bounces on a domain you have just pointed here

Pointing a domain at a catch-all inbox is one DNS record, and nearly every bounce it produces belongs to the hour around the change rather than to the setup itself. There are five cases and they look different from each other:

1. Before the record exists. A domain with no MX and no address record to fall back on gives senders 5.4.4 or 5.1.2: there is nowhere to deliver and nothing worth retrying.
2. While the change is spreading. Senders that already looked the record up keep the old answer until its TTL runs out. A bounce in this window names the old host on the Remote-MTA: line, which is precisely how you tell it apart from a record you have got wrong.
3. Once it has spread. Every name on the domain is accepted, so “user unknown” stops being possible there too. One record, priority 10, pointing at smtp.grabmail.io, and nothing else to publish for mail to arrive.
4. If the domain used to publish a null MX. Parked domains often carry the record that means “this domain never receives mail”. Senders that cached it answer 5.1.10 until it expires, whatever you have published since.
5. If the domain sends mail as well. A 5.7.26 on outgoing mail is not about any of this — it is your own SPF or DMARC failing to cover whatever sent the message. The receive-only guide is the strict case; a domain that also sends needs the ordinary staged rollout instead.

Reading the record answers most of that before anybody has to read a bounce:

$ dig +short MX yourdomain.com

The answer should be one line: the priority, then the host, then a trailing dot. Anything else — two lines, an unfamiliar host, nothing at all — is the bounce you are about to receive, three minutes early. Pointing your own domain here is the whole setup, and the three records that stop spoofing is what to publish once mail is arriving.

A bounce for a message you never sent

It arrives looking exactly like an ordinary failure report, quoting a message you have never seen, to a recipient you have never heard of. Nothing has been broken into. Somebody sent mail with your address written into the envelope as the sender, a receiving server took it in before discovering it could not deliver it, and then did the correct thing with a failed message: wrote a report and posted it to the sender it had been given. Which is you.

The name for it is backscatter, and what it proves is worth saying plainly: nothing about your mailbox. Forging an envelope sender needs no access to anything — it is one line typed into a conversation. Whoever did it needed your address and nothing else, and they may well have guessed it.

Three things separate it from a real bounce in about ten seconds:

• The returned message is not yours. The third part of the report carries the original, or at least its headers. If you have never written it, you did not send it, and everything else in the report is about somebody else's problem.
• The Received: chain starts somewhere you have never used. Read it from the bottom upwards: the lowest line is the machine that actually injected the message, and it will not be your provider. Reading an email header covers the direction and why the bottom is the honest end.
• The dates do not line up. Backscatter usually reports a message sent hours or days before the report reaches you, out of a queue that has been retrying somebody else's campaign since.

There is nothing to fix and nothing to answer. If the address belongs to a domain you own, publishing SPF and DMARC reduces it in the only way that works: a receiving server which checks the sender's policy before accepting refuses the forgery inside the conversation and never generates a report for anybody. Three records on a receive-only domain is the strictest version of that, and by some distance the easiest to publish.

A short name on a shared public domain collects more of this than a private address does, for the same reason it collects more spam: it is guessable, and a forger picking envelope senders is not aiming at you in particular. It is noise about somebody else, and unlike spam there is no button that trains anything — what the spam controls really do is the guide for the buttons that do work.

The order to read one in

1. Decide which kind you are holding. An error in your own mail app the moment you pressed send is a refusal. A message from MAILER-DAEMON that arrived afterwards is a report, and only the report has anything in it to read.
2. Check it is about a message you actually sent. The returned copy is in the third part. If it is not yours, it is backscatter, and you are done.
3. Open the raw source. The apology at the top is your own server's stock wording, not the reason, and the machine-readable block is not shown by default anywhere.
4. Find Status: and read the first digit. A 4 is still being retried and may yet succeed on its own; a 5 is final and nothing more will happen.
5. Read Diagnostic-Code:. This is the far end's own sentence, and the only place the rule that refused you is actually named.
6. Place the second digit. .1. is the address, .2. the mailbox, .4. the route, .7. somebody's policy. That is normally enough to know whose problem it is.
7. Act on whose problem it is. An addressing failure is fixed by having the right address; a routing failure by fixing DNS; a policy failure by satisfying the policy, or by asking the person on the other side to look at their own logs — where the same refusal is written down at far greater length than they sent you.

Two things are never the answer. Sending the message again unchanged after a 5 repeats the same refusal and, done often enough, damages the sending domain's reputation everywhere at once. And replying to the report reaches nobody: it came from an empty envelope sender, which is the very reason it could be delivered to you in the first place.

Questions