What’s the difference between local and remote bounce sources?

You sent a campaign and bounces came back. Now you're staring at a log full of error codes wondering: is my own server broken, or did their server reject me? That's exactly the local vs remote bounce question, and it actually has a clean answer once you know where to look.

Local bounces happen before your email even leaves your infrastructure. Your sending server (the Mail Transfer Agent, or MTA) couldn't complete the handoff. Think of it as a letter that never made it out of your own post office. Common causes include DNS lookup failures on your end, misconfigured relay settings, queue timeouts, and internal policy blocks.

Remote bounces happen after your email successfully left your server and reached the recipient's mail server. Their server reviewed it and said no. Common causes include the address not existing, a full mailbox, reputation-based rejection, or content filtering at their gateway.

The practical difference matters because local bounces are things you can fix right now. Remote bounces depend entirely on factors outside your control (or outside your network at least).

How to tell which is which in your logs

Look at the Delivery Status Notification (DSN) that comes back with the bounce. Two fields tell you almost everything you need to know.

First, check the Reporting-MTA field. If it matches your own sending domain or IP, the bounce originated locally. If it shows an external hostname, the bounce came from a remote server.

Second, look at the SMTP status code.

• 5xx codes are permanent failures. A 550 5.1.1 typically means the recipient address doesn't exist on the remote server. A 550 5.7.1 usually means policy rejection, often reputation-based.
• 4xx codes are temporary failures. The receiving server accepted the connection but deferred delivery. A 421 or 451 often means throttling or a temporary server issue on their end.
• A local failure often shows no external SMTP conversation at all. Your MTA log will show a DNS resolution failure, a connection timeout before the handshake, or a queue expiry notice.

Still a quick pattern to remember: if your MTA log shows the connection was never established with the remote server, that's local. If the log shows an SMTP conversation started (with a banner from their server) and then a rejection came back, that's remote.

What to do with each type

Local bounces need infrastructure investigation. Check your DNS settings, verify your relay configuration, look for queue backlogs, and confirm your authentication records are correctly published. If you're seeing a lot of local DNS failures, there's often a misconfiguration between your sending domain and your MTA setup.

Remote bounces need list hygiene investigation. A spike in 550 5.1.1 errors usually means too many invalid addresses. A spike in 550 5.7.1 means reputation problems. Neither of those has a server-side fix on your end. You need to handle the bounces properly and investigate why those addresses or your sender reputation got you rejected.

If you're getting bounces you can't decode, our free Email Header Analyzer can help you read the raw headers and DSN fields. Or if this is turning into a real deliverability problem, our SOS hotline is free and we'll help you sort it out.