What’s a “synchronous” vs “asynchronous” bounce?
Still have a question, spotted an error, or have a better explanation or a source we should cite?
Picture the moment your email hits a receiving server. Two things can happen right there and then. The server says "no" on the spot, or it says "sure, I'll take it" and then figures out later that it actually can't deliver it. That's the difference between a synchronous and an asynchronous bounce.
A synchronous bounce happens during the live SMTP conversation. Your sending server is still connected, waiting. The receiving server replies with a 5xx error code (something like 550 "user does not exist") and the rejection is instant. Your ESP captures it immediately, no guesswork needed. These are also called inline bounces or rejections, and they're the cleaner of the two because nothing slips through the cracks.
An asynchronous bounce is trickier. The receiving server accepts your message with a 250 OK during the SMTP session, so your ESP logs it as "delivered." But then, sometime later, the receiving system figures out it can't actually put it in a mailbox. It sends back a Delivery Status Notification (DSN) to the Return-Path address on your email. That notification can arrive minutes, hours, or even days later.
The practical problem with asynchronous bounces is that the notification can get lost, delayed, or formatted so inconsistently that your ESP can't parse it properly. Some systems generate malformed DSNs. Others never send one at all. That means you can have addresses sitting on your list that look fine but are silently failing every single send.
From a list hygiene standpoint, synchronous bounces are the easier ones to act on. Your ESP knows right away and can suppress the address immediately. Asynchronous bounces require your ESP to monitor a special inbox (the Return-Path address), parse incoming DSN messages, and match them back to the original send. If that pipeline has gaps, those bad addresses stay on your list longer than they should.
If you're seeing inconsistent bounce data between what your ESP reports and what you'd expect, asynchronous bounce handling (or the lack of it) is often the reason. Worth digging into how your ESP handles Return-Path processing before assuming your list is cleaner than it is.
If you're not sure whether your list has hidden delivery problems baked in, RME Clean can help you find and remove addresses that are quietly failing before they hurt your sender reputation.
Contributors
Who worked on this answer
Every name links to their profile. Every company links to their site. Real people, real accountability.
