mildnode
Sign inGet started

/ Email deliverability

How to read an email bounce, and what each code is telling you

A bounce looks like noise and is actually a precise diagnosis. Two numbers decide everything: the first digit says whether to try again, and the rest says why it failed.

/5 min read

A message bounces and you get back something that reads like a core dump: nested headers, a block of SMTP conversation, a URL to a support page that does not mention your situation.

It is, in fact, a precise answer. There is a conventional structure, and once you can find the two useful lines, most bounces diagnose themselves in under a minute.

First: is it permanent or temporary?

Every SMTP response carries a three-digit code, and the first digit is the whole story:

  • 4xx — temporary. The receiving server declined for now and your server will keep retrying, typically for a few days. Greylisting, rate limits, a full mailbox, a server under load. Often resolves without anyone doing anything.
  • 5xx — permanent. The receiving server will not accept this message, now or on a retry. No further attempts are made. This is what people mean by a hard bounce.

A 4xx that persists for days eventually becomes a delivery failure notice, which reads like a bounce but means something different: nobody ever refused the message, it just never got through.

The codes that matter most are the ones you never see. If a receiving server accepts a message and then files it in spam, there is no bounce at all — acceptance happened. A silent non-delivery is not a bounce problem, it is an authentication problem. Why your business email goes to spam covers that case.

Finding the line that matters

Ignore most of the bounce. The part worth reading is the Diagnostic-Code header, or the quoted line from the remote server:

bounce
1Final-Recipient: rfc822; customer@example.com
2Action: failed
3Status: 5.1.1
4Diagnostic-Code: smtp; 550 5.1.1 <customer@example.com>: Recipient
5 address rejected: User unknown in local recipient table

Three things are there. Action: failed means permanent. Status: 5.1.1 is the enhanced status code. And the text after 550 is the receiving server explaining itself in English, which is usually the fastest route to the answer.

The codes you will actually meet

  • 5.1.1 User unknown. The address does not exist. A typo, or somebody has left. Nothing to fix on your side beyond the address.
  • 5.2.2 Mailbox full. Permanent on paper, usually temporary in practice. Try again in a few days.
  • 5.7.1 Delivery not authorized. The broadest and most important one. It usually means authentication failed — SPF, DKIM or DMARC — or you are on a blocklist. Read the accompanying text; it is nearly always more specific.
  • 5.7.26 Unauthenticated email. Gmail's code for a message that failed both SPF and DKIM alignment. Your DNS records are wrong or missing.
  • 4.7.0 Try again later. Generic throttling, very common when a new domain starts sending.
  • 5.4.1 No answer from host / recipient address rejected. Often a Microsoft 365 response to an address that does not exist on a domain it hosts.
  • 5.3.0 or 5.0.0 Generic failure. The receiving server declined to be specific. The English text is the only thing that will tell you anything.

When the bounce is pointing at your DNS

Some bounces are about the recipient. Others are the receiving world telling you your own domain is misconfigured, and these are the ones worth acting on because they affect everybody you write to:

  • Any mention of SPF, DKIM, DMARC or unauthenticated — your records are wrong, missing, or do not cover the service you are sending from.
  • 550 5.7.1 ... not accepted due to domain's DMARC policy — your own DMARC policy is rejecting your own mail. Usually a service you forgot to authorise in SPF.
  • No PTR record / reverse DNS — the sending IP has no reverse lookup. If you send through a provider this is theirs to fix; if you run your own mail server it is yours.
  • Blocked using ... followed by a blocklist name — your sending IP or domain is listed. Each blocklist has its own delisting process, and the first step is finding out why.

If the bounce names SPF or DKIM, start with the DNS records a small business needs and confirm all three records exist and list every service that sends on your behalf.

Checking the sending side yourself

Before believing a theory about why mail is failing, read what you are actually publishing:

dig
1# what SPF authorises to send as you
2dig +short TXT yourdomain.com | grep spf1
3
4# your DMARC policy
5dig +short TXT _dmarc.yourdomain.com
6
7# a DKIM key, if you know the selector
8dig +short TXT selector._domainkey.yourdomain.com
9
10# where your mail is supposed to arrive
11dig +short MX yourdomain.com

Two SPF records on one domain is an automatic fail, and it is a common accident when a second mail service is added by someone who did not check for the first. There must be exactly one, listing everything.

The bounces that are not bounces

Two things arrive looking like bounces and mean something else entirely.

Backscatter is a bounce for a message you never sent, generated by a server that accepted spam forged to look like it came from your domain and then bounced it to you. It means somebody is spoofing your domain, and a DMARC policy stronger than p=none is what stops it.

Autoresponders — out-of-office replies, ticket confirmations — are ordinary mail that happens to arrive right after you sent something. They are not delivery failures, and treating them as one is how a good address ends up on a suppression list.

/ Questions

Asked about this

What does 550 5.7.1 actually mean?

Delivery was not authorised, which is a category rather than a cause. In practice it is almost always authentication — SPF, DKIM or DMARC failing — or a blocklist. The English text after the code is more specific than the code itself, so read that first.

My email bounced once and then worked. Should I worry?

Probably not. A 4xx is temporary by design and retried automatically; greylisting deliberately rejects the first attempt from an unfamiliar sender and accepts the second. If it happens consistently to one recipient domain, that is a pattern worth looking at.

Why do I get bounces for messages I never sent?

Somebody is forging your domain in the From line, and the servers receiving that spam are bouncing it to the apparent sender. It is called backscatter. A DMARC policy of quarantine or reject tells those servers to discard the forgeries instead.

The bounce says my message was accepted but the recipient never saw it.

Then it was not a bounce. A server that accepts a message and files it in spam reports no failure to you. That is a deliverability problem rather than a delivery one, and the fix is authentication and sending reputation rather than anything in the bounce.

/ Business Email + Domain + DNS

Most of the bounces above come from records that were never published or were published twice. We set up the mailboxes and publish SPF, DKIM and DMARC as one correct configuration, once.

Have your domain and email set up properly

/ Also

Other guides