Email bounce back: read the code, then fix the cause

An email bounce back reads like a mystery and works like a diagnosis. The cause is written into it, in a format nobody ever teaches you to read.

Search this topic and you get nine results explaining that hard bounces are permanent, soft bounces are temporary, and you should clean your mailing list. That’s the right answer if you’re a marketer running a campaign through Mailchimp. It’s no use at all if you’re a business owner whose invoices stopped arriving at a client last Tuesday, because there is no list to clean. Your own domain is what broke.

Here’s the version written from the sending side, by people who run mail servers. Start with the code.

Find the status code first

Open the bounce message and look past the apology paragraph. Somewhere inside it is a three-digit SMTP reply, and usually an enhanced status code that looks like 5.1.1 or 4.7.0. In Gmail, click the three dots and choose “Show original” if the code isn’t in the body. In Outlook, expand the “Diagnostic information for administrators” block.

The first digit tells you most of what you need. A 5 means permanent: the receiving server has made a decision, and resending the identical message changes nothing. A 4 means temporary, and your server will keep retrying on its own, usually for four or five days. Everything useful after that lives in the two digits that follow.

The codes you’ll actually see

The right-hand column is what the marketing-blog versions of this article never give you. If your code starts 5.1 or 5.2, stop investigating. The address is bad or the inbox is full, and nothing you change on your side will help. If it starts 5.7, the problem is at your end, and the rest of this is about you.

Why 5.7.x suddenly got so common

In February 2024 Google and Yahoo switched on bulk sender requirements. Anyone sending more than 5,000 messages a day to Gmail addresses now needs SPF, DKIM, a DMARC record, a valid PTR on the sending IP, one-click unsubscribe on bulk mail, and a spam complaint rate under 0.3%. Microsoft brought in the same thresholds during 2025.

A lot of small senders who had never thought about DNS in their lives woke up to 5.7.26 rejections. Nothing about their mail had changed. The rules had.

So, bluntly: if you send business mail from your own domain and you have never set up DKIM, you are living on borrowed time. Not “you might want to look into it”. It will break, and it will break quietly, because the servers you already correspond with have learned to trust you and the new ones simply won’t.

Fix your end in this order

Assuming a 5.7.x code, work through these in sequence. Later checks tell you nothing if the earlier ones are failing.

1. Get the PTR record right. Your sending IP has to resolve backwards to a hostname, and that hostname should resolve forwards to the same IP. On a VPS you set this in the provider’s control panel, not your DNS zone. A missing PTR is the most common reason mail from a self-hosted server vanishes.
2. Check SPF, and check that there’s only one of them. Two SPF records has the same effect as none. Then watch the ten-lookup limit: every include: counts against it, and stacking Google Workspace plus a CRM plus a newsletter tool plus a helpdesk will quietly blow through it and turn the whole record into a permerror.
3. Publish DKIM. Your server signs outgoing mail with a private key and the public half sits in DNS at selector._domainkey.yourdomain.com. Every mail platform will generate this for you. The usual failure is that somebody generated it two years ago and never published the record.
4. Add DMARC, gently. Start at v=DMARC1; p=none; rua=mailto:you@yourdomain.com and actually read the reports for a fortnight before tightening to quarantine. We have cleaned up more mail broken by an over-eager p=reject than by any attacker.
5. Check reputation last. Look up the sending IP and the domain against the major blocklists. On shared hosting you can be listed because of a neighbour, which is one of the reasons we move clients onto dedicated IPs for anything transactional.

We went through the record syntax properly in SPF, DKIM and DMARC without the jargon, so treat this as the diagnostic path rather than a repeat.

When it’s only one recipient

This is a different shape of problem, and the generic articles never separate it out. If your mail reaches everybody except one domain, the fault is nearly always at that domain: an over-tuned spam filter, a manual block, or an ancient greylisting setup that never lets a first attempt through.

You can’t fix their server. What you can do is hand them the evidence. A recipient’s IT team can find the rejection in their logs in about two minutes if you give them the timestamp and the status code, and approximately never if you tell them your emails keep bouncing. Forward the whole bounce, headers included.

The bounces that aren’t bounces

Backscatter is the first one people misread. You get a bounce for a message you never sent, because somebody forged your domain as the sender and the receiving server dutifully bounced it back to you. It’s irritating rather than dangerous, and a DMARC policy with teeth cuts most of it out.

Silent drops are the second, and they’re worse. No bounce arrives at all. The receiving server accepted your message and then filed it in spam or discarded it, so there’s nothing to read and nothing to decode. When a client says they never got it and there’s no bounce anywhere in your mailbox, treat it as a reputation problem rather than a delivery failure, and go and read your DMARC reports.

Getting it looked at

Most bounce problems we get called in on come down to one missing DNS record and one wrong assumption about who is allowed to send mail for the domain. A couple of hours to audit and fix, and we do it at a fixed price: our email deliverability fix covers the DNS side, the server side, and reporting afterwards so you can watch it land.

If the real question underneath is whether to keep running your own mail server, that’s a fair thing to ask, and we’ve argued both sides in hosted versus self-hosted email. The wider service sits under our mail and deliverability work.