So you've got a bounce... now what?

One of the questions I constantly see being asked in deliverability resource groups is What does this bounce mean? and a copy of the bounce.

While bounces come in all shapes, sizes, forms and some are more useful than others, this guide will try to help you troubleshoot them before you ask for help.

Let's start with the basics: what is a bounce and why do they happen?

A bounce occurs when a sent email message can’t be successfully delivered to the intended recipient. Bounces are classified into two main groups: temporary and permanent. Greylisting is a great example of a temporary bounce, while a non-existent mailbox is a great example of a permanent bounce.

Temporary bounces start with 4xx code to tell the sending server to try again. Most servers try every 5-10 minutes for anywhere from 24 hours to 5 days, depending on the MTA configuration. Temporary bounces are generally not shown to the sender as an NDR (or commonly known as a bounce message), and are only known to server admins with access to the logs. When a temporary bounce exceeds the retry limit, then the sender is notified.

Here's an example temporary bounce from iCloud when the recipient mailbox is receiving mail at an excessive volume

421 4.7.1 Messages deferred due to excessive volume. Try again later - https://support.apple.com/en-us/HT204137

Permanent bounces start with 5xx code and tell the sender that delivery will fail if it is retried unless the underlying cause is fixed. These are the bounces that are usually shown to the sender in the form of an NDR.

One of the most common bounces is when the mailbox does not exist, as we can see below from Google's example. Speaking of Google, their bounces are usually very descriptive on what the issue is and include a link where you can learn more about the bounce.

550 5.1.1 The email account that you tried to reach does not exist. Please try double-checking the recipient's email address for typos or unnecessary spaces. Learn more at https://support.google.com/mail/?p=NoSuchUser - gsmtp

Other times, bounces occur when protocols like SPF, DKIM or DMARC fail or are missing

550-5.7.26 This mail is unauthenticated, which poses a security risk to the sender and Gmail users, and has been blocked. The sender must authenticate with at least one of SPF or DKIM. For this message, DKIM checks did not pass and SPF check for [example.com] did not pass with ip: [*.*.*.*]. The sender should visit https://support.google.com/mail/answer81126#authentication for instructions on setting up authentication.

or your IP is blacklisted (which is a whole other topic in it of itself!)

550 5.7.1 Service unavailable; client [x.xx.xx.xx] blocked using zen.spamhaus.org

How do I fix a bounce?

The first thing do to, which many people miss, is read the bounce. As mentioned earlier, many times, you can easily see the error from the bounce description itself. Some providers do use cryptic internal codes, but most will try to use plain english. If they have a link, follow it! It's there for a reason, to provide more details to you on the causes and fixes.

If, after reading the bounce and following the link still cannot understand the bounce, you have a few options:

• If you use an ESP, contact the ESP - they likely have seen the bounce other times and are happy to help you!
• If you are an email administrator, you can reach the postmaster of the recipient to ask more questions. Their email is usually , but if the bounce has a link, that page may have a better way to reach them.
• Search for the bounce! There is a 99% certainty other people have encountered it before, so use that to your advantage.

Learning how to interpret bounces is a key skill for anyone involved in email marketing, email deliverability or email administration.

The amazing folks at Postmark have developed the SMTP Field Manual (which I've contributed to!) and has a collection of bounces from various email providers and spam filters and explains them in a clear, concise way.