How to Tell If an Email Bounced Because of Your Server or Theirs

An email bounces back and your stomach drops. My first thought is always the same: something is wrong with my mail. Half the time, that is not true at all. The bounce is telling you exactly whose side the problem sits on, if you read it properly, and the difference matters because the fix is completely different depending on the answer. Fixing your own SPF records will not help when the recipient's mailbox does not exist.

Start with the number, not the panic

Every bounce, the formal name is a non-delivery report, carries a three-digit code and usually a longer code with dots in it, like 5.1.1. The first digit does most of the work. A code starting with 4 is a soft bounce, a temporary failure. The sending server will keep retrying for a day or two, and the message may still arrive. A code starting with 5 is a hard bounce, a permanent failure. Nothing will be retried, and resending the same message changes nothing.

The dotted code narrows it down further. The middle number points at the area: x.1.x is addressing, x.2.x is the mailbox, x.4.x is network or routing, and x.7.x is security or policy. Read the plain-language text after the code too: two servers can return the same code for different reasons.

A worked example: the invoice that bounced

Here is a case I have actually lived through. I sent an invoice from my own domain to a client, and minutes later the bounce came back: 550 5.1.1, "The email account that you tried to reach does not exist." The 5 means permanent, and 5.1.1 means the address itself is the problem, not my server and not the network.

Before replying, I ran the client's domain through our MX Record Checker. The MX records pointed at Google's mail servers, which told me their mail was hosted and working, and the refusal came from Google's servers, so the address really did not exist there, or the person had left and their mailbox had been closed. I asked the client for a current address, they gave me a different one, and the invoice went through on the first try. No DNS change on my side would have fixed that bounce, because nothing on my side was broken.

Contrast that with a different bounce I have seen: 550 5.7.26 from Gmail, saying the message failed authentication. That one points straight back at the sender. The fix lived in my own DNS, in the SPF, DKIM and DMARC records, and I checked them with our SPF, DKIM & DMARC Checker before touching anything.

The five-minute check, in order

When a bounce lands, work through these in order and stop at the first one that explains it.

First, read the code. If it starts with 4, wait. A 421 or 451 usually means the receiving server is busy, greylisting you, or rate-limiting your sends, and your server will retry on its own. If it starts with 5, keep going, because something has to change before you resend.

Second, check the recipient's domain. Run their domain through the MX Record Checker. No MX records at all means their domain cannot receive mail, which is their problem to fix with their host or DNS provider. MX records that point somewhere sensible mean their mail system is alive, and the bounce is about the address or the policy, not the domain.

Third, look at the words. "User unknown", "mailbox does not exist" and "recipient address rejected" are their side: a typo, a closed account, a wrong address. "Mailbox full" or "over quota" is also their side, though it is temporary, so a retry in a day or two is reasonable. Wording about authentication, SPF, DKIM or DMARC is your side, and so is any mention of your IP or domain being blocked.

Fourth, check your own authentication. If the bounce mentions SPF, DKIM, DMARC, or a policy rejection like 550 5.7.1, run your own domain through the SPF, DKIM & DMARC Checker and send a test through our Email Deliverability Test to see the verdicts live. Our post on fixing email that passes SPF but still fails DMARC walks through the most common trap here, a record that looks right and still fails.

Fifth, check the blocklists. A 554 rejection or a message about your IP being blocked can mean your sending IP or domain sits on a blocklist. Run it through the Blacklist Checker. If it is listed, that is your side to clean up, and no amount of resending will help until the listing is dealt with.

The mistake I see most often

The mistake is assuming the bounce is about the message you sent, when it is about the address you sent it to. I have watched people rewrite an invoice, strip out links, resend from a different address, and finally phone the client in frustration, only to learn the client had changed jobs and the mailbox had been closed for weeks. The bounce said 5.1.1 the whole time. Reading the code first would have saved all of it.

The opposite mistake exists too. When every message to Gmail bounces with 5.7.26, people keep resending and blaming Google, when the real fault is a missing DMARC record on their own domain. One bounce to one person is usually their side. The same bounce to many different people is almost always yours.

An edge case worth knowing

Sometimes the bounce comes from your own provider, not the recipient at all. If you have exceeded a daily sending limit, or you tried to send from an address on a domain you never verified with your provider, your own server refuses the message before it ever leaves. The bounce will name your provider's server rather than the recipient's. That is easy to miss, but the fix is in your own account, not theirs.

What to do first

Next time a message bounces, do not resend it and do not start changing DNS records. Read the code, note whether it starts with 4 or 5, then run the recipient's domain through the MX Record Checker. That one check splits the problem in half: no MX records or a dead address means it is their side, an authentication or policy refusal means it is yours. From there the fix is usually obvious, and you will know exactly who needs to act.