When sending large amounts of transactional email, it’s inevitable that some will bounce. Maybe there was a typo in the email address, the receiving server could be down, the mailbox may have been deleted, or there could just be a transient error somewhere in the chain. Regardless of the cause, understanding the reasons can help you understand how to handle the bounce and provide the best experience for your users.
With marketing or promotional emails to huge lists, you may be less concerned with bounces, but with transactional email, a bounce today could mean that a user is locked out of their account because they can’t reset their password tomorrow. That will almost inevitably turn into an extra support request. So by improving your bounce handling, you’re likely to reduce support requests related to delivery problems in addition to providing a better experience for customers. Happier customers? Fewer support requests? Who doesn’t want that?
Types of bounces #
The first step to handling bounces is to understand them. Bounce notifications exist to make you aware of a delivery issue. In most cases, this means that the recipient didn’t receive your mail. In some cases, like spam complaints, they may have received it but didn’t want it. Sometimes, you can take steps to fix the problem, but in other cases, it’s simply outside of your control. So depending on the type of bounce, you’ll want to respond differently.
At a high level there’s two key types of bounces, and then there’s a third group of spam-related issues that’s closely related to traditional bounces. The first of the primary types is a ‘hard bounce’ which represents that the email was permanently undeliverable. This can happen when emails are mistyped or when a mailbox has been deleted or hasn’t been set up yet. Network issues can frequently lead to hard bounces as well, but these can also be temporary. There are other reasons too, but those are the most common.
| Reason | Type | Explanation | Action |
| Bounce | Hard Bounce | ||
| Soft Bounce | |||
| Autoresponder | |||
| Spam | Complaint | ||
| Notification | |||
| Blocked |
Then there are ‘soft bounces’ which means that the email may be able to be delivered eventually, but it wasn’t delivered just yet. This can happen when someone’s inbox is full or when their mailbox is configured to send an autoresponder. In some cases, these aren’t bounces in the sense of delivery failure, and the sending server will automatically retry under the right circumstances. Soft bounces are still worth paying attention to, though. Sometimes they even justify a response of some sort.
Finally, there are spam-related bounces. These can take the form of a ‘spam complaint’ where a user explicitly marks an email as spam or as a ‘spam notification’ where a mail server determines that the message is spam. The latter will generally only affect individual emails and can be caused by content or virus filters - or really anything that a receiver uses to score spam. In many cases, it’s simply an over-aggressive corporate firewall or spam filter, such as Mimecast or Barracuda. In cases where messages are blocked by a receiving server's spam filter, you will want to let the recipient know via another channel, so that they can have their mail administrator whitelist either your sending domain or the IPs you send from.
It’s also possible for a message to be flat out blocked by an ISP due to domain or IP address reputation issues. These cases generally require deeper investigation by your email service provider as they are at a higher level and will affect delivery of all emails from that source.
Most modern email service providers let you configure a webhook for handling bounce and spam complaints. You’ll need to configure an endpoint within your application that accepts these webhook requests and then processes the bounce information accordingly. You can see an example bounce webhook in Postmark’s Bounce webhook documentation, and Patrick Graham built a standalone demo application for receiving and display Postmark webhook contents.
This webhook approach enables you to keep all of your bounce handling logic directly in your application’s codebase. Any time an email bounces, Postmark will make a request to your endpoint with all of the details about the bounce so you can take the relevant actions on your end. Depending on the bounce type and circumstances, there are a quite a few possible actions you can take to remedy the issue. So let’s dive deeper and look at the best ways to respond to each type of bounce.
When and how should you intervene? #
One of the more challenging parts of handling bounces is deciding whether, when, and how to intervene. Is it a temporary issue that may resolve itself? What’s the permission level of the user? For instance, it’s more problematic for an account holder responsible for billing and adding new users to be locked out of their account than a read-only user with minimal access. Has the problem been recurring? Is it one email address or an entire domain that’s bouncing?
All of these questions and more play into your decision-making process about how to fix the problem. Automating how you handle bounces is a good practice, but like anything else, you only want to automate when it makes sense. Certain types of bounces are more common than other types, and some are more complex to fix through automation. Your results will vary, but from our experience with Postmark, here’s a rough break down of what types of bounces you can expect.
- 80% Hard bounces.
- 10% Soft bounces.
- 3.5% Spam complaints/notifications and ISP Blocks
- 2.5% Message delayed.
- 2.5% Auto responders.
- 1.5% Other. (DNS Error, DMARC reject policies, Challenge Verifications, Unsubscribe, etc.)
These numbers are across a variety of accounts and practices across Postmark. It’s likely that your numbers will be fairly different, but these should still give you a good ballpark of what to expect. So the big takeaway is that taking care of hard bounces will generally address 80% of your bounce-related delivery issues.
Let’s dive in and look at each of these categories as their own cases and think through the best practices for managing and automating each type of bounce. Then we’ll explore some of the various strategies for automating bounce handling and minimizing disruption to your users.
Hard bounces #
Hard bounces are the most critical bounces because the recipient won’t receive the email or future emails unless action is taken by someone. This could be the user updating or changing their email address, or it could be customer support fixing obvious typos in emails like “gmial” instead of “gmail.” Regardless of the reason, whenever you receive a hard bounce notification, you should immediately cease delivery to that address until the problem is resolved. Otherwise, you risk hurting your delivery for other emails on that same domain or IP address.
The good news about hard bounces is that they can usually be addressed with some automation to a reasonable degree. We’ll discuss those options in detail later in this guide. With hard bounces, you may want to use a combination of methods to ensure that the problem gets resolved. Most of your bounce handling effort should be focused here, but the exact solution can vary widely depending on your application and use cases.
By default, Postmark will stop trying to deliver emails to an address that has had a hard bounce. Delivery can be reactivated via the API or the Postmark web interface, but you’ll likely only want to manually reactivate delivery on behalf of your users.
Soft bounces #
Soft bounces will generally require action, but more often than not, it’s simply about retrying the email at a later time. For example, when someone’s inbox is full, the ISP may reject the email, but once they’ve deleted some, delivery would succeed. Of course, a full inbox may be a sign of an abandoned email address. So while it may be a temporary issue, it’s also very possible that it’s a permanent delivery issue. You likely only want to retry a couple of times and then consider it a hard bounce.
In some cases, your ESP will handle these automatically by reattempting delivery at set intervals over the course of the next few days, but if they don’t, you’ll want to consider building a system that will attempt to re-send the emails and track the number of soft bounces. That would involve recording the soft bounce, the recipient, and the email, and regenerating it for that individual. Too many failed attempts, and you should definitely write it off as a hard bounce and handle it accordingly.
Spam or content-related bounces #
Spam-related bounces can be the trickiest because there’s often very little you can do. Regardless, there’s one thing you should always do, and that’s not attempt future delivery to that address unless the problem is resolved. Otherwise, ISPs will interpret that behavior as spam-like, and they could block future delivery.
In some cases, it could be that the end user clicked a “Report Spam” button accidentally, but unless they email support about missing emails, you want to always assume it was intentional. In Postmark, the only way to reactivate delivery to an email address that received a spam complaint is to email support with an explanation. This helps protect both your reputation and Postmark’s.
One of the more common spam-related problems is ISP blocks. This happens when a mailbox provider has decided to flat out block delivery. In some cases, this is tied to domain or IP reputation, but in all cases, it’s something that has to be addressed manually. At Postmark, we fully bear the burden of these issues in the case of issues with IP reputation. If there’s an ISP block with a major provider due to an IP reputation issue, we dig in and take care of it. Whether that’s taking an IP address out of rotation, reaching out to the provider to find out the exact reason for the block, or getting whitelisted to prevent future issues, we handle it. These types of bounces should be few and far between, but if you’re ever concerned, you can reach out, and we’ll be all over it.
The final type of spam-related bounce is ‘spam notifications.’ These are situations where content filters or firewalls blocked a specific message. In our experience, most of these are caused by one of two things: some piece of content in your email or over-zealous corporate firewalls. With the former, it can be anything from a “viagra” mention to a phone number. The content that triggers spam filters isn’t always obvious. In the case of spam notifications, the best solution is usually to have the recipient reach out to their IT department or mail administrator to have your domain or sending IP addresses whitelisted in their spam filter.
Message delayed #
Generally speaking, with delayed messages, some larger cause is at play. In some rare cases with transactional emails, inbox providers could explicitly delay delivery for a variety of reasons. If a recipient has received a large volume of notifications from the same source, they may slow down the rate of delivery to the inbox. In most cases, it will get there eventually once they’ve accepted it.
Alternatively, if the ESP detects or suspects unusual behavior, delivery may be temporarily suspended until the validity of the messages can be confirmed. And finally, sometimes services simply have a large queue, and things slow down. While this is rare, at Postmark we do our best to be transparent and clearly label messages as such so you know exactly what’s happening.
Auto-responders #
In general, there’s no need to do anything with auto-responders. They’re aren’t really a bounce, but they can represent delivery issues or delays. In some cases with collaborative software, you may want to pass along out-of-office notifications to your application so that other participants are aware of potential delays in responses.
Other #
In most cases, these specific issues happen infrequently enough that it’s probably not worth investing significant time automating them, but they’re still worth paying attention to.
- Challenge Verification - When a recipient uses a challenge verification tool, you may need to respond to the challenge or otherwise reach out via other channels in order to get the sending address whitelisted. It’s generally best to route these to your support team to ensure the recipient doesn’t miss out on any emails.
- DNS Error - When migrating domains or changing email providers, you’ll occasionally run into widespread issues where delivery to a domain can be affected for a large number of users. These are usually far outside of your control, but it’s important to stay aware and coordinate with your users when problems are widespread.
- DMARC Reject - As DMARC adoption increases, more and more domains are implementing a rejection policy that directs ISPs to refuse delivery for any emails that aren't aligned with DMARC. If you’re seeing DMARC rejections, you may need to review your authentication settings for SPF and DKIM to ensure that your emails are aligned with the DMARC policy.
- Unsubscribe - These are rare with transactional email, but it’s imperative that you take these seriously and silence future email notifications to the subscriber. Otherwise, it’s likely to turn into a spam complaint and be more difficult to fix in the future.
10 things you can do to handle bounces with care #
The biggest challenge with bounce handling is that a bounce generally represents an issue that prevents email communication with customers. So if you can’t email your customer to let them know there’s a problem with their email address, what can you do? Ideally, you’ll want to automate your bounce handling as much as possible, but until you’re at a high enough scale to justify the development costs, you’ll want to start low-tech and enhance your bounce handling as it makes sense.
You can seek examples of several of these tactics in use with our version control application, Beanstalk as well as Sifter, a hosted bug and issue tracking application. Both applications implement a completely automated end-to-end bounce handling solution using Postmark’s bounce handling webhook and API.
1. Protect your delivery reputation #
There’s one over-arching principle for handling and responding to bounces. Whenever you receive a hard bounce or spam complaint/notification, you should immediately stop attempting to deliver emails to those addresses until you’re able to investigate. Too many bounced emails or an obvious disregard for spam complaints can hurt your delivery reputation and affect delivery of other emails to that provider.
Postmark automatically suspends delivery to email addresses that have received a hard bounce or spam complaint/notification. Hard bounces can be manually reactivated, but delivery to addresses that received a spam-related bounce can only be reactivated by emailing support and explaining what happened.
2. Notify your support team #
The simplest solution for bounce handling is to create a system that automatically notifies your support team whenever there’s a delivery issue. They’ll be able to dig in and determine the best course of action. Even once you automate some of your bounce handling, you’ll likely still end up with some bounces that can’t be handled automatically. So no matter how advanced your bounce handling becomes, support will always play a role in handling the edge cases.
3. Display a prominent notification to the user when they log in #
In the case of hard bounces, you’ll want to display a prominent notification within your application. Imagine that a new user signs up but mistypes their email address. While they’re looking around and trying out your application, their welcome email bounces, and you’re notified. Now you can immediately display a notification to the user so they can correct the mistake right away.
4. Log an event or add a note to the user’s account for future reference #
Process the request and add a note to the user’s account about what happened. If it’s a temporary technical issue, they may not even be aware that emails bounced, and they may go looking to find out why they didn’t receive an email that they expected.
5. Let users reactivate delivery #
Occasionally, hard bounces are caused by unusual and temporary circumstances. For instance, say a new employee’s email address hadn’t been properly set up. It may bounce, but then that bounce serves as the impetus for the user to ensure that the problem is resolved. Then, once the email address should work, the best resolution is for them to let you know that it’s safe to try again.
6. Use other forms of communication #
If your application uses SMS or you have users set up and confirm multiple email addresses, you can fall back to those forms of communication to let them know about the delivery issues to their email address.
7. Notify other users on the account #
If your application is collaborative with multiple users tied to an account, you can notify administrators that can help proactively fix the problem on the user’s behalf. The easiest way to do this is to send an email to the relevant administrators that the user’s email is bouncing.
There’s one subtle but important distinction here depending on how your application handles permissions. You’ll want to think through the subtle implications of what happens if the person in charge of an account has an email address that’s bouncing. In most cases, this is a “big deal” since it could mean that the account holder may no longer be active. That could lead to a big inconvenience for other users on the account, but there’s not a simple solution. With Sifter if the account holder’s email bounced, the application would automatically notify all of the administrators on the account so that they could collectively take action to mitigate future delivery issues.
Another interesting use case is notifying administrators when a user reports an email as spam. You’ll want to stop delivery to that user, but it’s important for the other users on the account to understand that person won’t receive any future notifications. Sometimes, spam complaints are accidental, and it may have simply been a miscommunication. So by notifying the other users on the account, you give them a chance to reach out to that user directly and sort out any issues.
8. Relay auto-responder information #
In some cases, you may want to do something with auto-responders. For instance, if you send critical email notifications through your application, it may be useful to process the auto-responder and let the sender know about things like out-of-office replies. That way, if they’re expecting a quick reply, they’ll know that the reply may take longer. These are edge cases of course, and it’s rare that you’ll want to do anything with auto-responders.
9. Use Rebound by Postmark #
If you use Postmark and you're not at a point where you can custom build full bounce handling functionality into your application, you can use Rebound to quickly add in basic bounce handling functionality using JavaScript.
10. Use Postmark's sandbox feature
#
There are many benefits to having a dedicated sandbox environment set up and one of those is so that you don't mix your test emails with emails going to real recipients. By separating these two environments, you'll be able to more quickly pinpoint and address any issues with bounces that you might be seeing.
Email is about way more than sending #
Anybody can send email, but like most software efforts, the way you handle and recover from issues makes a world of difference in the deliverability of your emails. Handling bounces carefully will protect your domain’s reputation and ensure fewer issues for customers. You don’t need to implement a robust bounce handling solution on day one, but you will want to monitor them and regularly build up and enhance your bounce handling capabilities as time goes on.
Bounce handling is a breeze with Postmark
With detailed reporting, bounce webhooks, and Postmark Rebound, handling bounces has never been easier.
