We’ve talked recently about how bounces can make a difference in deliverability for your domain, and briefly mentioned a few ways you could help your customers with some proactive interface decisions. Bounce handling has been around for a long time and it basically means “there was a problem delivering your message.” Applications can improve bounce handling by taking this idea a step further to “if an email bounces, don’t just ignore it, here's something to do about it!”
In the early days of email the only choice was to offload monitoring to senders. For applications, this could leave customers with a dilemma when a message bounced. They had to decide if a message is just being slow or will never be delivered. As email use grew Email Service Providers started building rules for how to handle bounces on their system. For example, Postmark will stop sending email to addresses with a hard bounce unless you specifically reactivate it. Today ESPs have tools to make it simpler for applications to build in more advanced bounce handling, and it’s worth exploring some real world examples of how this can work.
To find examples of in-app bounce handling I added a typo to my email address to see how apps I use every day would handle this error. A simple typo or aggressive policy on the receiving mail server can bounce and create unanswered questions for your customers. After a bounce they could be left waiting for an email that will never show up, but it doesn’t have to be that way. Here are examples to show how some apps use handle bounces to help their customers.
Bounce notifications from Inbox by Google #
If you’ve used email you’ve seen bounced messages return to your inbox. Your email server will generate a message to try and explain why they weren’t able to deliver your message. Most people who send email would wonder exactly what a message like `550: 5.1.1 unknown or illegal alias:` means.
Google has done some great work to help Gmail users cut through email jargon and understand what happened to their messages. This starts with their SMTP responses as they reply with specifics and a link to a help article.
Sorry, we were unable to deliver your message to the following address.
``550: 5.1.1 The email account that you tried to reach does not exist. Please try
``5.1.1 double-checking the recipient's email address for typos or
``5.1.1 unnecessary spaces. Learn more at
``5.1.1 https://support.google.com/mail/?p=NoSuchUser k123si3698974itk.63 - gsmtp
This SMTP response is really helpful for folks who bounce a message to a Gmail address. Google builds on this friendly bounce reply and improves it when you’re using Inbox by Google. A clear bounce explanation is front and center and is followed by plain language similar to the raw bounce response.
This message makes it crystal clear why a message wasn’t delivered and gives the user tips on how to correct the error, along with a link to a help article for more information.
Lesson for your app: Try to make smart assumptions about what might have caused a bounce and share that with your customers. Even if your audience is technically sophisticated, they might not want to parse a SMTP error code and response.
Email addresses are a common user ID and it can be a big problem if your customers sign up with an email address where you can’t reach them. It’s a great idea to verify email addresses with a validation workflow, but that doesn’t solve the problem when someone signs up with an invalid email address.
Netflix shows their customers when their email bounces right away in their app. In researching this post, I changed my email address to one with a typo. As soon as I refreshed the page this message popped up across the top of the window:
I love this immediate check. Going back to the email validation workflows, if I mistype my email address I have to switch to my inbox to wait for a message that won’t arrive. Then I have to go back to the app to see if I can request another email, and I might or might not notice my typo. Telling people their updated email address bounced right away saves you and them time.
Lesson for your app: Look for bounces as people are logged in to your app. There’s no reason to send them to their inbox looking for an email that won’t arrive. It’s still a good idea to keep your email validation workflow to make sure your customers are making any changes to their email address on file.
In December we released updated permissions for Postmark accounts. It lets our customers add users with different levels of access and relies on email to take care of the sign up process. This is what the user area looks like for your active accounts.
Bounces don’t just show up as pending invitations here. When an email bounces you can see that at a glance on this page.
If you click through on an account with a bounced message you’ll get more detailed information about what happened with the invitation email. You can resend the invite here too.
Lesson for your app: In addition to noting pending invitations, keep your customers updated on the status of invitations that have bounced. Providing this info at the account level, along with notifications for individual accounts, will make sure your customers are able to get up and running with out account-related hassles.
Churn Buster #
When you send email on behalf of your customers you have to be aware of bounces. If you’re sending email from your own domain and enough of it bounces, your domain’s reputation could take a hit and delivery for all of your customers could suffer. Keeping an eye on bounces can help you identify customers who might not be a fit, or potentially abusing your application.
In the case of Churn Buster, bounces tell you when their customers are in danger of losing revenue. Churn Buster show their customers message stats on their dashboard so they can identify customers with bounced messages and create workflows to keep them from churning.
This gives their customers a way to quickly glance and keep track how their email is performing overall through Churn Buster, and how many bounces they’ve generated in particular.
Lesson for your app: If you send email on behalf of your customers, give them a way to keep track their bounces. The best way to surface this info will vary depending on your use case, but focusing on getting bounce info to your customers is a great way to improve their experience.
Put bounce data to work in your app #
Bounces will happen when you send email. Using your ESPs bounce data to your advantage can help your customers and improve their experience with your app. Here’s an example of the data you can get from Postmark bounce webhook.
"Name": "Hard bounce",
"Description": "The server was unable to deliver your message (ex: unknown user, mailbox not found).",
"Details": "Test bounce details",
"Subject": "Test subject",
"Content": "<Full dump of bounce>",
You can find more details in the documentation for our bounce webhook and API endpoint for bounces. Hopefully, these examples have spurred a thought or two for how you can improve bounce handling for your application. Hit us up on Twitter to share your favorite advanced bounce handling examples.