How do ESPs build bounce dictionaries?

When an email bounces, the receiving mail server sends back a response message. Sometimes it's a tidy code like 5.1.1 with a note that says "user not found." Other times it's a wall of text that's somewhere between cryptic and unhinged. A bounce dictionary is how an ESP makes sense of all of it.

The basic idea is pattern matching at scale. ESPs collect SMTP response messages from millions of sends, then map those messages to categories like hard bounce, soft bounce, or block. Over time, these mappings become a reference library that the bounce processor consults every time a new failure comes in.

Here's what goes into building one:

Raw data collection. The ESP captures the full SMTP response from every bounce across every send. That means the numeric code, the text string, the sending domain, the receiving provider, and a timestamp. Volume matters here. The more sends an ESP processes, the more error variations it sees and the more accurate its patterns become.

Pattern extraction. Engineers and data pipelines identify which phrases consistently predict a permanent failure versus a temporary one. "No such user" is usually a hard bounce. "Mailbox full" is usually soft. "Message rejected due to policy" might be a block. These patterns get compiled into regex rules that can match against new incoming responses automatically.

Provider-specific rules matter a lot here. Gmail's wording for a nonexistent address looks different from Outlook's, which looks different again from a regional or self-hosted mail server. A good bounce dictionary has provider-aware branches so it doesn't misclassify a Gmail soft bounce as a hard one just because the phrasing is unusual.

Confidence scoring. Not every pattern is equally reliable. Some error strings map cleanly to one category. Others are genuinely ambiguous ("undeliverable" could mean almost anything depending on who sent it). ESPs assign confidence weights to their mappings, and lower-confidence matches often get routed to a holding category for false positive review before any suppression happens.

Ongoing maintenance. Mail providers change their error messages. New blocklist behaviors emerge. Servers get upgraded. A bounce dictionary that was accurate last year can start misfiring this year if nobody's watching it. Good ESPs version their dictionaries, monitor for unexpected classification spikes, and push updates when patterns drift.

Why does this matter for you? Because the quality of an ESP's bounce dictionary directly affects how cleanly your list gets maintained. A dictionary that misreads a soft bounce as a hard one might suppress an address that would've started delivering again next week. One that misses a true hard bounce leaves a dead address on your list and keeps damaging your sender reputation with every send.

If you're seeing bounce classifications that don't match what you'd expect, it might be worth running a list clean before your next campaign. We do that at RME if you want a second opinion on what's actually sitting in your list ;)