Set up DMARC and see who's sending email using your brand's domain.
Taking Email with Postmark
Episode #7

Why emails bounce and how to handle them responsibly?

Episode #7

Anna Ward, the Head of Deliverability at Postmark, gives us an in-depth look at bounces. We discuss what bounces are, why they happen, and what can be done about them. If you’re looking for tips to improve bounce handling for your app be sure to tune in!

Postmark's SMTP Field Manual: A collection of raw STMP server responses from major email service providers and spam filter services. The data is open source so anyone can make contributions.

Why we build the SMTP Field Manual? A short blog post that was written by our CTO, Chris Nagele, which explains why we set out to create a single resource to document SMTP codes for the major ISPs.

Contribute to our open-source SMTP Field Manual: The SMTP Field Manual is only valuable if we can keep it up to date. If you've recently received a strange SMTP response from an email service provider or spam filtering service we want to hear about it. Alternatively, if you think there's something we could do to improve the clarity of our existing messaging, please let us know.

Lastly, be sure to check out the postmaster pages for the major ISPs. You'll find details on the kinds of bounces to expect, your reputation as a sender, and your overall deliverability performance:

Hotmail/Outlook SNDS:


Hosted by

Full transcript

Anna Ward: 00:06 Sloppy senders just don't get good inbox placement. They don't get good deliverability and they don't get good engagement. So if you're not paying attention to bounces, you're sending a message that you're not a good sender and maybe what you're sending isn't really that important.

Marek Loder: 00:24 Hello and welcome to Talk to an Email with Postmark. I'm your host Marek Loder and in today's episode my guest, Anna Ward the Head of Deliverability at Postmark will give us the behind the scenes look at bounces. To discuss what bounces are, why they happen, and what you can do about them. In sharing this, we hope that you'll come away with some ideas on how you might be able to improve bounce handling for your business or side project. Hope you enjoy the episode.

Marek Loder: 00:52 Anna, thanks for joining me again on the show.

Anna Ward: 00:54 Thank you so much for having me Marek.

Marek Loder: 00:57 So you've been on the show before and we've already gotten a bit of backstory and how you ended up as a deliverability expert. And for those of you who may have missed this, be sure to check out episode three where Anna talked to us about solving extreme email deliverability mysteries. So today to kick things off, I figured it'd be fun to start with a fun fact about you. Anything interesting that you want to share with us?

Anna Ward: 01:20 I was trying to think of a fun fact that wasn't actually a boring fact to everyone else, and I'm just going to choose an interesting fact because right now I'm trying really hard to learn how to grow different plants and I have learned that I kill all of the easy ones and it's just I'm obsessed with like watering things and checking pH and moisture levels and stuff. And if you give me a succulent, I'm going to kill it. So I think that works really well with my job, my attention to detail and my obsession with things and every little tiny things you can measure. So it's just my personality and I think that's interesting.

Marek Loder: 01:59 I love that. We'll have to give you a Christmas present, a book on how to take care of succulents and desert plants. I appreciate you sharing that little tidbit with us. So getting right into it let's kick things off with the basics. So when an email is delivered successfully to a person's inbox, can you tell us what's going on behind the scenes in the wacky world of SMTP to make that happen?

Anna Ward: 02:25 Yeah, I was thinking about this question and I wonder if maybe I should start by talking about what SMTP is. And it was created in like the early '80s as a protocol for one email server to communicate with another email server specifically like a server that's external to its own network. And it's the only way that you can send email in the world. All email is sent via SMTP across networks. So I know you might use Postmark or something and say like, "Oh, but I send via the email API." Well, that API is just a call that tells our server to create an SMTP transaction on your behalf. So everything is SMTP. And when it was first created, people maybe manually were initiating these transactions. But now of course we have automated mail transfer agents or MTAs that process and send messages on every human's behalf.

Anna Ward: 03:25 And in Postmarks case that MTA is running additional software to manage really large queues of recipients for many different senders at once. And so the MTA is responsible for looking up the end recipients' exchange servers. That's like a receiving mail server and it starts that connection with it via SMTP and it's kind of adorable to watch. It's literally a back and forth human readable conversation like, "Hey server, how are you doing?" "Oh, I'm doing well." "Hey, can I send you a message?" "Yeah, sure. Go ahead." And it's really human readable responses back and forth just like this, except they happen extremely fast. And at the end of it they say goodbye and that's it. Your message is I guess in that sense, during that connection sent. Yeah.

Marek Loder: 04:21 So it sounds like there's a lot of moving pieces there. Even though it's a single click on your computer, there's a tremendous amount of things happening behind the scenes to actually get that email through to the recipient's inbox.

Anna Ward: 04:36 Yeah. I think that the most important thing to note about this is that it's a single click from my Postmark's MTA to the recipient's MTA. But really there's a ton of hops that are happening and a ton of connections that happen just for one message. So generally a message is sent from an MUA, a mailbox, like a mail user agent and that gets transferred to the MTA. So like maybe Postmark's MTA and then that gets transferred to the receiver's MTA, which is like a receiving, accepting MTA. And then that gets passed onto an MDA, which is a mail delivery agent. And that's to find hopefully a local delivery option. So it's finding where that individual recipient is. But even after that, like because of forwarding and lists serves and mailing lists and stuff and MTA may even transfer it to another MTA and start a whole another chain of connections that have to happen.

Anna Ward: 05:41 And so that's already like five to six connections made like just one single message. And that's not even considering all the extra hops and processes for spam filtering, firewalls and blacklists checks, authentication standards, encryption of course that forwarding and listserv routing that mail today all of these things that mail must go through. So I'm delivering a message you don't really know what's going to happen after that first initial connection from we'll say Postmark to the receiver, but there's a lot of different things that can happen and lots of different things that the receiver wants to happen before it actually delivers the message. So [crosstalk 00:06:27].

Marek Loder: 06:28 I did not have a sense of how many connections are actually happening behind the scenes to get an email from point A to point B. There are a lot of dependencies, right? There's a lot of things that have to go right. Perhaps we can start there, can you walk us through what are the indications that let a sender know that a message has been successfully delivered?

Anna Ward: 06:52 Yeah, definitely. Because of SMTP, each of those connections, each of those hops from server to server, SMTP requires that there's some sort of relevant status about the success of that transaction. So if I send you a message via SMTP and I say, "Did you accept it?" You're supposed to say "Yes, no." With some sort of information. But that means that status is only accessible to the machine that was involved in that most recent connection. So unfortunately that means at the most basic level seeing as success status on the hop from your MTA to the receiving MTA that's the most real confirmation of delivery that most senders have. So that's, I got to 250ok. When Postmark connected with the recipient server. So I'm just going to assume that everything went okay from then on. But now people have tried to build on other indicators of course, because we have HTML content now.

Anna Ward: 07:55 So you can also track image downloads as opens, you can do URL tracking via redirection or UTM tracking parameters, so it's click tracking. And then there's also third party services that you can sign up for or that people download to manage their inboxes. And they will actually sometimes provide feedback to senders directly from your email client. So that's important to know when you download some clean up your inbox app, read the fine print and see if it's actually sharing your data with someone. So there's a lot of ways people have gotten around this idea that SMTP is only limited between the two servers having that conversation. And so they're trying to find ways to get that feedback more directly from the end recipient.

Marek Loder: 08:45 So to be clear there, I think that's really interesting, right? So ultimately getting that 250ok back from the receiving mail server that effectively it means that those five or six connections that may have been made to get to that point, clearly they were all successful if we got to that final stage. Yeah?

Anna Ward: 09:05 Correct. But what's unfortunate here is that your visibility as a sender, as the original sender of the message, you may only have visibility into the status as of the first two or three connections. The last three, six, 100 connections you don't necessarily get feedback on because you don't have access to those machines. So that's what I mean by you may see a 250ok in Postmark meaning that a message was successfully delivered, but there could be some sort of failure later on that ends up making a message undeliverable. And so that's where these extra confirmations like open tracking and click tracking, that's where they come in to try to help solve the mystery. Like did it actually go somewhere? So that's the magic of email, I guess the mystery of it.

Marek Loder: 10:00 Right. Just getting that 250ok, isn't necessarily an accurate indication that the message did get to the recipient's inbox? So that's where we start to then rely on these proxies, opens, clicks, things like that, which are more behavior centric to let us know whether a message actually made it to the inbox. Is that a fair assessment?

Anna Ward: 10:20 Yeah, that's a great way to put it for sure.

Marek Loder: 10:22 Okay. Let's talk about when emails bounce, when that happens, can you tell us what's going on behind the scenes?

Anna Ward: 10:31 Sure. So I consider any connection or hop that fails, that's an undelivered message. So the message didn't get through that step failed. And when you think of a bounce, you think of something coming back to you. So if you think about an undelivered message and then something coming back to you, I would define a bounce as any indication that a message in more or less real time wasn't delivered. And so you need some sort of indicator or some sort of information coming back to you to let you know about that undelivered status. And that's a bounce.

Marek Loder: 11:11 Okay. So I think the key word there is "any indication", perhaps you can explain to us how this indication or this feedback gets back to the original sender. Can you walk us through that process?

Anna Ward: 11:29 That's a really great question. There's generally two ways to register a bounce. The first one which we kind of talked about is the status during that connection, during that SMTP transaction of a failure. So you're saying your hellos and how are you's to the next server and the receiving server says, "I'm sorry I can't take this message for some odd reason." And immediately during that SMTP transaction you can immediately log this didn't work out and you know, it's bounced. The second way to get a bounce is as an email reply that's sent later to the sender about the failure further down the road. And so we call these non-delivery reports or NDRs and those reports, those emails are sent whenever the receiver has time usually in an automated way on some mail server, some software running there says, "Ah, this didn't work out. Sorry dudes." And then it sends you that email response. And you can receive that to what we call the return path or the envelope from address, which is usually the address for another mail server. That processes bounces.

Marek Loder: 12:46 Okay. So let's talk a little bit about the common factors that cause bounces to happen. Can you speak to that?

Anna Ward: 12:54 Yes, definitely. So first I feel like I should mention that while there are like RFCs and standards and practices on what information a bounce should include and the codes that represent each bounce type, technically receivers can still send back whatever they want. So bounce analysis is often more of an art and it requires a lot of trial and error and heavily customized processing. Just throwing that disclaimer out here, but despite that, so with that said I can go over the main reasons that a message bounces and some of those general categories.

Anna Ward: 13:33 So the first category I would say is a hard bounce, which is a permanent failure. So permanent is the key word there. And the idea is that the sender will never be able to reach this recipient with any message. And so types of bounces that are hard, bounces are maybe a bad or non-existent domain, like you did a typo, a nonexistent end recipient. So maybe exists, but doesn't exist. And then there's also sender or IP reputation issues and black listings. And so those are often a hard bounce too because it affects all messages, it's a permanent failure. As long as you have this reputation issue, no message will go through. So permanent...They are serious bounces that you should seriously consider suppressing from your list or resolving immediately.

Anna Ward: 14:38 The second category is soft bounces and so temporary failures, keyword temporary and that means that the sender might be able to reach this recipient with their next message. So this one didn't work, maybe the next one will. The most common example is a full mailbox. So someone hasn't checked in a while, they're on vacation, you send your next message next week and it'll be fine. Or sometimes they abandoned the mailbox, who knows. But it's considered temporary just because it could resolve itself.

Anna Ward: 15:12 Then there's also spam and content related rejections and that's usually on a per message basis. So maybe you link to something a little bit sketchy for the time being or something that was taken over, there's also the idea that maybe you sent some phrasing or keywords that trends in spam right now are really sensitive to and so you're going to get rejected for now because of that message. But it's still a temporary issue, your next message may not have that sort of issue.

Anna Ward: 15:44 And then there's also this a little bit more rare. Some people aren't aware of this type of bounce. It's called a challenge response. It could also be a hard bounce it depends on how aggressive the receiver is. But the challenge response is usually saying, "I don't know whether you're a spammer, so I'm going to send you the bounce. And if you can click this URL or go to this page or send me another message." This is the challenge part of it. Then how consider accepting future messages or the same message again. So it's again, that's another temporary soft bounce sort of failure and there's usually something you can do or try again later and it'll be fine.

Anna Ward: 16:28 And then the third one is a transient bounce and this one is telling you to try again later with the same message. So like the sender should try sending the same message again usually very soon. So maybe within 10 minutes, maybe immediately. Some examples of that is just the receiving mail server is just way too busy. So if you have a lot of mail to send to a company and they manage their own mail server they may say, "Wow, we can't process thousands and thousands of these at once you got to slow down." And so they'll send those bounces to tell you to redo the same message again.

Anna Ward: 17:10 And then another type of transient is gray listing. And gray listing is typically a way to thwart spammers. They have this idea that a spammer may not be paying attention to bounces that much. And so if they say, "Hey, you might be a spammer try again later." That spammer just considers that an undelivered message and doesn't try again, whereas a legitimate sender will say, "Oh, but I'm not a spammer, I'm going to try this again." And so they do and they get delivered. So those are the three types, hard, soft and transient. And there could be some overlap but that's the big kahuna.

Marek Loder: 17:53 Can you just quickly summarize kind of which of these bounce types are primarily related to sender behavior and which of them are really more tied to the receiver side?

Anna Ward: 18:04 Yeah. So sender behavior you'll get a bounce because of something that the sender did when it's about reputation or when it's about list management. So list management is easy like I'm sending two bad domains or I'm sending too old email addresses. Like those sorts of things are more likely to get bounces, just because they aren't useful or aren't being used or don't exist. And then there's also the reputation based ones. So if you've been sending a lot of mail that people just don't want you may start seeing bounces where maybe Gmail says, "We've been getting a lot of complaints about you and we don't want your mail anymore." And that will become a bounce. Hopefully that's extremely rare, but that's all on you. And so those are things you need to watch out for and try to correct because they can be corrected, right?

Anna Ward: 18:57 And the bounce is related to recipient behavior. That would be their solutions for anti-spam or their maintenance for their domain or their server. So for example, if they're using a lot of black list providers and special anti-spam solutions and stuff, there's going to be a huge variation in bounces and how often they're sent back to you, how aggressively they're sent back to you. And sometimes if you're using an unreliable anti-spam solution, you could get a lot of false positives. Like, I'm rejecting you because you're on a black list and then you look and you're not on the black list. And so that's something that their software needs to fix. They've done a bad check there. And then there's also their domain or server maintenance. Like if you let your domain expire or you overloaded your mail server those bounces can happen because the recipient needs to do some maintenance on their end and that's out of your control.

Marek Loder: 20:02 Cool. One thing before we move on with respect to the sender behavior and how that impacts bounces as you said, list management's pretty straight forward, right? You're sending to a bad domain, bad contact, et cetera. But on the reputation side having perhaps a poor domain reputation. Are there indicators of that? I mean in terms of how that would present as a bounce?

Anna Ward: 20:31 So because receivers can put whatever they want in a bounce reply, sometimes there isn't any indication that the bounce is because of a reputation issue that just comes with experience. And maybe even reaching out or asking the receiver for help. Like, I don't understand why this is happening. Can you give me more information? And sometimes they'll say, "Oh, well it's because we just don't like you or you've had some issues in the past or whatever it is." You can figure that out kind of through roundabout ways. But a lot of times it is written in the bounce message itself. It'll say something like, "We didn't like your content, this content related." "Or we're getting too much unsolicited mail from you or due to policy restrictions." And you'll see that one a lot. It's indicating there's more aggressive spam filtering and so you can look into how you might be able to change your messages or your sending practices to better accommodate these more aggressive anti-spam solutions. So sometimes you can't tell what the bounce, but sometimes it's really obvious.

Marek Loder: 21:43 It sounds like there's a bit of a dance going on in order to kind of understand and decipher what might be contributing to these bounces. I mean, I guess in your experience as a deliverability expert, which would you say of these various bounce types cause the most confusion and why?

Anna Ward: 22:03 Yeah, I would say the ones that are most confusing are definitely those reputation related ones. And then also those that are using some sort of customized anti-spam effort and that's because both of those are extremely subjective. So every single recipient you send to and every single message that you send to that recipient, they're going to judge it a little bit differently. So the way Gmail feels about your mail is different from the way that Yahoo feels about your mail, which is different from the way that .gov addresses feel about your mail. And so each of these have their own idea about how you are as a sender. They have their own idea about how aggressive to be with senders. And so all of those anti-spam reputation related bounces they can vary in what they say, they can vary in how often they're sent back to you. And yeah, it's just you've got to have a lot of experience and just be really watchful for small trends and that's where the confusion comes.

Marek Loder: 23:08 Clearly as a sender you're being judged by different mail clients and ISPs and anti-spam solutions, it can probably get to the point where it's a bit overwhelming if you kind of take the approach of you know what, I can't do anything about this. Can we talk a little bit about what kind of the longterm impact of getting these types of bounces would have on a sender?

Anna Ward: 23:31 I think that's a really important question because people often think of bounces as being the result of some sort of action that they've done. Like, "Oh, I've done poorly, so I'm getting a lot of bounces or I'm doing great, so I'm not getting a lot of bounces." But the bounces themselves are your behavior and every rejection by the recipient or by the receiving server, it affects their perception of you as a sender. So if they bounce you, they're like, "This sender I had to bounce them. I need to make a note of that." And a lot of them do. And the more you try to contact them when they don't want you to or try to reach people that don't exist, wasting their time, all of these things are a negative spot on your reputation with them and how mail in the future might be delivered.

Anna Ward: 24:22 And so as a sender, you're most easily identified by your sending domains. We all know that. That sending domains have a reputation that they built and bounces definitely are a part of that. But also they may identify you as a sender by your content. So if you have consistent branding or templates or something, if you try a different sending domain, you might still see poor performance because your reputation is still tied to that content. They may also see certain links or URLs in your content and say, "This is the same sender or I hate people who send these sorts of links." And that same reputation is tied to it. Same thing with where you host your images and files. Like that's another indicator to identify senders that they don't want talking to them. And so anything you can do to minimize bounces is going to be positive for your reputation and anything you do that ignores or encourages bounces is going to negatively affect your reputation. So bounces are really important.

Marek Loder: 25:28 That's actually just kind of amazing to think about the profile that ISPs are able to kind of build and create around who you are as a sender, right? They may have little to do with your domain and they actually have more to do with your content et cetera. I mean are ISPs and mail clients so they work collaboratively to kind of create these really robust profiles to make these types of decisions around bounces?

Anna Ward: 25:59 I honestly, as a sender, I wish it was a little bit more collaborative but it's not. A lot of people like Gmail has its secret sauce that it's never going to share no matter what. And no matter how much Yahoo improves something, they're not going to share it with Outlook. And Outlook isn't going to get to know what Gmail is up to and it's just everybody has their own proprietaries spice blend. But a lot of them, I hear them talk about it as fingerprinting a sender. Little trends that may change over time indicators so that they can tell like you're the same sender even if you change ESPs or you need a new domain, they can still kind of tell who you are and have some sort of reputation information about how much to trust your message.

Marek Loder: 26:48 Wow. I guess going back to your original point, right, because they aren't as collaborative as maybe you would like them to be as a sender. It's a bit of an art with respect to navigating how each of these different ISPs is going to ultimately treat you as a sender. Yeah?

Anna Ward: 27:04 Exactly. So because of maybe your reputation issue at a specific receiver, you could get a lot of bounces from them, maybe even really aggressive ones. Whereas to other receivers you see no effect at all, and your mail gets delivered fine. Bounces are just like inbox placement. Like it varies all the time, no matter who you're sending to. And so keeping track of it and monitoring it and taking action when you see excessive bounces or strange bounces or unexpected bounces is the only way to do it.

Marek Loder: 27:38 So with respect to taking action and making sure that you're actually are being responsible with bounces, I mean, what would you say are some of the best practices for monitoring bounces? And are these practices different when you're sending from a third-party ESP service like let's say Postmark versus sending from an internal mail server?

Anna Ward: 28:02 Great question. So I'll start with managing your own mail servers because that's what I do. And so there are some best practices towards if you want to have a mail server and be any good at it, there's a few things that you need when it comes to bounces. The first one is a way to log the response of every SMTP transaction you make. So you got to not only just do those transactions but log every response and be able to store that somewhere easily accessible. And then you also need a way to receive and log all of the messages sent to your envelope from your return path address that's used for each SMTP transaction. So that's logging all of those NDRs, those none delivery reports and storing them somewhere. And so with those two sets of logs you'll very likely need some software that can analyze those log responses and filter them by category and general content parsing what they're talking about in the codes.

Anna Ward: 29:05 And then once you have that software that can parse and categorize, you need to apply all of that analysis to your retry policies, your list management and anti-abuse efforts for future mail that's sent. So that's just like the basic, like what you need to manage bounces from logging to analyzing and then applying that to how you send mail in the future.

Marek Loder: 29:34 Yeah, it sounds like a lot of work.

Anna Ward: 29:38 It is, and a lot of maintenance. Like, you can set all this up but you're still going to need to make adjustments as time goes and as you learn more. But if you're someone who uses someone else's mail server, which I recommend, like the customer of an ESP you really need an ESP that gives you visibility into every logged response to your mail, made human readable. So I know there's a lot of ESPs that may just say, "Oh, the message bounced." And it was a hard bounce and you don't really get any indication about like, "Okay, what did they specifically say? Was it an NDR? Was it a failure during the transaction?" Like, give me some more details about what's going on.

Anna Ward: 30:19 So try to find an ESP that gives you a lot of visibility into that. So that you can come back to them and say, "Hey, this doesn't look right. Can you make adjustments?" And that's really important to my job is feedback from our customers when they see something a little off. I think that empowering the customers of an ESP, you're only going to make that ESP better and better because they're kind of like your own little QA team.

Marek Loder: 30:46 Before we move on off of that point, Anna you've worked for not only Postmark but a couple other pretty large players in the ESP landscape. As you think about what Postmark does and how we present bounces, is there anything unique to how we present bounces that you think is actually pretty helpful with respect to sending email?

Anna Ward: 31:06 Yes, for sure. So not only does Postmark show a general category and tries to make those categories useful for analytics. So like hard, soft, transient, autoresponder, like all these different types of bounce types that could happen we're trying to make them relevant. Anyone who can log into their account and take a look at any one of those individual bounces and see the specific log of what exactly happened. And if it's an NDR, they can see the entire message headers and all, where it came from. And so a lot of that is great for not only updating your bounce processing but also maybe taking it back to the recipient or the receiver to help them fix their issues too. So I think having that visibility can improve the entire email landscape and there's a lot of customers of ours who have gone back or to their own mail servers or to their recipients mail servers and we've seen improvements and changes and how they accept and deliver mail to their recipients. So it's a really positive change. Just I like giving information.

Marek Loder: 32:17 Cool. No, I didn't mean to make a shameless plug there. I just wanted to just help kind of paint a clear picture of how we actually present bounces at Postmark. So anything else there in terms of using a third party ESP?

Anna Ward: 32:31 So not only just seeing the bounces, but also having them process them into suppression options. So maybe you want to see a hard bounce always blocked going on, going ... Always blocked. What am I saying? So maybe you want to see a hard bounce, always blocked moving forward or maybe you want to see those transient options automatically retried. So those sorts of things are things you want to see in your ESP that they're not only just monitoring the bounces and showing them to you, but they're taking action, direct action on them in a way that makes sense.

Anna Ward: 33:09 And because of that, I want to mention like you may see a variation in how you act on bounces based on your message type. So for example, as a transactional sender we try to be a little bit more lenient because if there is a bounce that we want to block in the future that could be someone's password reset message. That could be their purchase confirmation. And so we try to allow people to resend those whenever possible or to send future mail whenever possible. And the same thing with transients. We try to retry those much more aggressively than maybe a bulk sender would. A bulk sender may retry less often give up sooner and suppress more. And they should because that mail isn't as urgent or time-sensitive. So yeah, there's a lot to consider when choosing an ESP.

Marek Loder: 34:08 It sounds like bounce handling is certainly one of those key considerations that should be factored in the decision making.

Anna Ward: 34:15 For sure yes. Bounce handling is probably what I spend most of my day on as a deliverability expert is understanding bounces, analyzing them, and then trying to figure out if I'm wrong and if I need to reach out to the recipient directly for more insights.

Marek Loder: 34:33 Well, let's talk a little more about that with respect to this is, as you said, something that's a huge part of your day to day as a deliverability expert. What are some of the biggest challenges that you have when it comes to understanding the root cause of bounces?

Anna Ward: 34:50 So, yeah, great question. For me the most frustrating thing about bounces is I would say like the playful way that some receivers use bounces, how they choose a seemingly random SMTP code. Like they'll assign a 400 to a hard bounce, which is incorrect, or they'll make a bounce that has a 250, which should be a success. But then in the description, it says they didn't accept it. Just really sloppy like I like to think maybe they're trying to confuse or they're trying to be playful or maybe it's just they didn't have the time or knowledge to make that as correct as possible. Vague descriptions, sometimes I even see some that are really sassy, like little sassy things like "you're a spam and you're never getting in here" l ike little cute things and that's great. And I love it when that people are able to do that. But for me, processes a lot of mail those sorts of responses are really hard for me to parse in an automated way. So you got to keep your eye out for sassy jokes and bounce responses.

Anna Ward: 36:01 And then of course, another challenge is if it is something more cryptic in the description, maybe that's by design they want to thwart spammers after all is trying to understand if you aren't a spammer, what you need to do to get around that bounce to make that bounce stop happening. And a lot of that is communication with the receiver. And so as a deliverability expert we have a whole community of industry members trying to work together to improve how we communicate and how we talk about things and how we share information when possible when appropriate. And so I have to make sure that I know someone at every major receiver and that they trust me. I know that I'm going to do the right thing with whatever they tell me so I have my own reputation that I have to monitor and maintain so that we can process bounces properly.

Marek Loder: 37:04 So just to add to that piece, would it be ill advised to manage your own mail server if you didn't have somebody like you who has those relationships to be able to kind of remedy some of these deliverability issues?

Anna Ward: 37:20 If you're a mail server that sends on behalf of many senders and you have a lot of volume and it's consistent like those sorts of things that requires constant management and you really do need an expert to handle it. But if you are a single company and you want to have your own mail server just for your own mail, sending from your own employees, from your own domains it may be less of a need just because there aren't as many reputation risks at play I guess. But and so you do see a lot of like single companies managing their own mail servers, but at the same time they do often have to rely on third party vendors, like third party anti-abuse software and blacklist providers. And so I guess no man is an Island when it comes to mail servers. So you're always going to have some sort of expert to rely on and you really do need it to do anything efficiently when it comes to email.

Marek Loder: 38:23 So whether you're sending through an ESP or managing your own mail server, are there any tools or strategies or things that you rely on that can be helpful to decipher and understand bounces?

Anna Ward: 38:39 First I'll mention that most major receivers like Yahoo, Gmail, Outlook they all have published what they call postmaster pages of some kind or you can get a little bit of information about what to expect when it comes to bounces and failures and how to potentially reach out or create a ticket of some kind if you're having issues. I couldn't speak to how efficient that is at solving problems, but it's definitely better than nothing. And unfortunately there just hasn't been much information out there about bounces and what's expected across receivers right now. A lot of people have been relying on private channels and so thank you for giving me this opportunity for a shameless plug.

Anna Ward: 39:28 We've been working on a site called So, and it is free and it is open source anyone can contribute bounces that they've seen in the wild, the SMTP code, the receiver that they came from. And I've been encouraging all my colleagues in the industry to contribute and they have, it's been a really cool project. It's very beautifully done because it's done by Postmark designers. And so I really encourage everyone to check that out and just to see what's out there in the wild, see the kinds of variations and hopefully that will help you when you're designing or editing how you parse bounces. So you'll kind of know what to expect even if you haven't seen it before.

Marek Loder: 40:16 So just to be clear, this field manual, this SMTP field manual that we've put together is literally our best attempt to kind of pull together all of these different bounce codes from major ISPs around the world. Yeah?

Anna Ward: 40:33 Exactly yes. And it's also been a big hit among major receivers. Like, for example, Yahoo, when we first put it out, they were really excited about it. And I felt kind of silly because I accidentally excluded them from the list and just bad oversight on my side. And they were like, "Hey, where's the Yahoo SMTP codes? Can we help provide those for you?" And I thought that, that was really cool that a receiver was excited about this tool and wanted to help contribute to it too. So it's definitely a big need and please contribute and check it out. And I think we hope that the whole industry will get a lot of value from it.

Marek Loder: 41:11 Super cool. And I'll certainly be sure to include a link to that in the resources section for this episode. So once you've created systems, whether they're systems that are provided by the third party ESP that you're using to send the email or whether you're creating systems to log all of your sending with your own mail server. Now what? I mean, can you kind of walk us through what do you actually do or what actions you should take once you get this bounce information?

Anna Ward: 41:39 So that will definitely vary what you do with the bounce response based on what type of message that you're sending. So if you're sending transactional for example, you may not want to suppress every hard bounce. Maybe a hard bounce if it's a bad domain, sure we won't try that domain in the future, but if it's a bad email address, maybe they just created it and you want to try again because they've created an account in your app, for example, and you don't want to suppress them forever. You're going to try more mail later if it's transactional. But for bulk, if you get a hard bounce, you pretty much immediately should remove it from your list and never send to it again. It should be suppressed. The same thing with domain reputation issues, you may stop sending bulk for a little while, while you're resolving some sort of reputation dilemma.

Anna Ward: 42:36 But for transactional, you're just going to keep sending. Even if you're getting bounces that might be content related, you can not send a password reset or you can not send your purchase confirmation like you have to try. And so that can also change. And then I'll also say that when it comes to parsing what's inside of the bounce, what's going on, like if it's a blacklist concern, for example, your IP is blacklisted. That doesn't necessarily tell you to take someone off your list, but it does tell you to take action and look up your IP or look up your domain, see where it's listed and start that resolution process with the owner of that public list. So there's a lot of actions that come out of a bounce and some of them are done by your mail server provider and some of them are done by the individual sender. Hopefully most of those are automated.

Marek Loder: 43:38 Cool. So there's no, obviously, yeah, there's no one size fits all? It just depends on the scenario, it depends on the bounce, it depends on the content that you're sending? But it does sound like monitoring bounces and responsibly handling them in one way or another is important, correct?

Anna Ward: 43:57 Correct. Yes. It's a lot more important than some people think, I would say.

Marek Loder: 44:02 And just to be clear, I mean, like worst case scenario here, if you're really not handling your bounces appropriately, what can happen? I mean, what does that end up looking like?

Anna Ward: 44:15 If you're not handling your bounces and not doing anything about them, then what you'll probably see in the future is your reputation will drop. Receivers will think you're a sloppy sender, which I would say that is true. If you aren't paying attention to bounces and sloppy senders, just don't get good inbox placement. They don't get good deliverability and they don't get good engagement. So if you're not paying attention to bounces, you're sending a message that you're not a good sender, and maybe what you're sending isn't really that important. Isn't important enough to you to manage it properly.

Marek Loder: 44:58 So don't be a sloppy sender.

Anna Ward: 45:00 Don't be a sloppy sender, have a little respect for yourself and manage those bounces.

Marek Loder: 45:05 Cool. All right. So don't be a sloppy sender, sounds like that's the big takeaway. Manage those bounces and make sure you're tracking them. Make sure you're taking actions on them.

Marek Loder: 45:14 Anna I'd like to thank you for taking the time to be with us today.

Anna Ward: 45:19 Yeah, thank you so much. This is my favorite topic and I just had a really great time talking about it.

Marek Loder: 45:23 And to our listeners, thank you for joining us today. If you enjoyed the episode, please leave us a review on iTunes and subscribe to receive updates on all future episodes. And be sure to check out the resources section for this episode where you'll find helpful tools like our SMTP field mail. Lastly, if you're ever looking for help with handling bounces for your app or side project, be sure to reach out to us at and we'd be more than happy to help.

Marek Loder: 45:48 See you soon!