Email deliverability can be difficult to understand. With so many different mailbox providers (MBPs), algorithms, and nuance, not to mention recipient behavior, it can feel impossible to crack the code for really great email marketing campaigns.
Are you using all the tools you have at your disposal to make sense of all the data available to you?
In this edition of the Email Experts Series, we talk about SMTP codes, a clue given to you by MBPs to understand your email performance. How do they work, and how can you use them to your advantage? Watch the video below to find out!
(We’ve found key timestamps and transcribed this video below.)
Total Run Time: 10 minutes
00:39 – What are SMTP codes?
1:26 – Soft bounce versus hard bounce
2:00 – Walkthrough of SMTP response codes
4:00 – Interpretation challenges
5:21 – Consistency in codes across mailbox providers
6:00 – How to remediate issues
7:39 – Common and helpful SMTP code use cases
Listen and subscribe on your favorite platform:
Transcript
Anthony Chiulli
Hi, everyone, and welcome. My name is Anthony Chiulli, and today we’re going to be talking about SMTP response codes. Joining me today is Luke Martinez, my colleague, and Beth Kittle. SMTP response codes are also known as error codes or bounce codes, but it’s basically the information that’s sent back from a mailbox provider when you send an email that doesn’t get delivered. So, Luke, what is the purpose and the mission of a SMTP response code back from a mailbox provider?
Luke Martinez
Yeah, sure. It’s basically to tell you the status of your delivery. Did the message successfully get to where it was supposed to get? Was there a technical error in attempting to transmit the message? If so, can you? The response code provides you hopefully some information about what the error was. So, knowing if it delivered, that’s great. Knowing it failed, you know, that’s kind of useful. But the purpose of the code is to tell you not just what the result was, but hopefully a little bit about what why it failed. If it did fail, why it was delayed? That’s the goal.
AC
And there’s different categories of response codes, but they basically all boil down to one of two. Beth, can you talk about kind of the two primary categories of response codes?
Beth Kittle
Sure. So, you have your soft bounces and your hard bounces. Soft typically point to a temporary issue, your deferrals and retrials. Maybe it’s a mailbox that’s temporarily full. Then, your hard bounces point to more permanent issues: invalid addresses, maybe it’s an invalid mailbox or outright spam blocking.
AC
What I would like to do is, if you don’t mind, breaking down the anatomy of a response code and understanding the different pieces of an actual response code that comes back.
LM
Yeah, absolutely. It’s really not that complicated, and I bet even if you didn’t know it, you’ve probably seen something that looks a little bit like this. But essentially there’s three parts to an SMTP response. The first part, the basic status code, it actually has to be a three-digit number, but it either starts with a two or four or five. You have an enhanced status code that tells you a little bit more information. You just look up tables that tell you what these enhanced status codes are supposed to tell you. And then, the most useful part, I think, for a lot of people is the reply text. This is a string of text that comes back from the provider that hopefully gives you some insight into why they returned to the specific status code or enhanced code.
You put all these together and it should give you a good idea of what’s going on with your email, at least a basic level. How much of it is getting through? You know, 200 means it got delivered; how much of it might have experienced some delays or some other problems? Those are 400s. Then, how many had, as Beth alluded to, how many had permanent, bad failures? Those are usually your 500s. And I’m using the word “usually” for good reason that we’ll get into a little bit later. But this is the basic anatomy of a response code. Two sets of numbers and then a string of text.
AC
And as you mention, these are extremely helpful. We’ll talk about some of the challenges here with Beth in a moment. But it’s funny when you mentioned that, you know, you may have not seen it, but it may look familiar. I think the reason that many marketers may not even see these types of things is, a lot of times ESPs don’t service these very easily, which leads me to my next question for you, Beth. What are some of the challenges that exist and perhaps, why marketers may not be as familiar or have seen these in their day-to-day operations?
BK
Sure. I think the biggest challenge is that there’s really no consistency in how bounces are processed. Every ISP will have a different way of doing it. One response could mean something at three different ESPs. So, there are now teams at ESPs that are constantly looking at response codes and changing how they’re handling them. It’s a dynamic process.
The rules are updated frequently. One thing could be treated as a soft bounce one day, and then the next day they realize that wasn’t the right call. Maybe the string of text was misleading or something like that. But they actually have teams of people whose job it is to go and review these things and make sure they’re there making the right calls day to day.
AC
And it’s interesting me that the general format you talked about, Luke, the 200 series, the 400 series, the 500 series: That tends to be with an asterisk, right? There’s always outside examples, the general format for how codes are at least classified. What gets really interesting, though, is a lot of mailbox providers and receivers use their own version of their code. What I’m trying to say is, a mailbox provider like Gmail doesn’t have the same set of codes that Comcast has. So, even though you may email two that are invalid addresses, they may not return the exact same permanent 500-type bounce code.
LM
Yeah. I think there is there’s no consistency even in the big mailbox providers, but I think they tend to get them right more often than not. I’ve seen that, you look into smaller telecom providers or individual mail servers, I’ve seen things like a 500 error which should be a permanent failure, hard bounce, but it says, “Please try again later.” Like, try again in five minutes. You’re telling me it’s a 500, but I should try again? So, the important thing for anyone sending email is scale. You do need to have a process for reviewing how you’re handling these things. If the world was perfect, we could just treat 500s as permanent, hard bounce failures and for hundreds of temporary failures. But there’s too many exceptions to leave it up to logic.
AC
I think a lot of ESPs offer bounce management software or tools and rules to do this on behalf of senders, so it’s not like senders—unless you’re operating your own MTA—it’s not like senders have to be manually going through bounce codes and suppressing or trying again later. That’s all automated, most often than not. I think it’s really important to understand what these are and how they’re useful. So how does how does a marketer, Luke, actually go about seeing this? Maybe this is something that they’re aware of, but they’ve never seen it in their general reporting from an ISP.
LM
Yeah, it varies. And the only good answer is talk to your ESP about it. But some of them, to varying degrees, display this stuff in their UI. A table like this could exist somewhere, where you’re actually able to see the responses broken out by the basic code, the enhanced code, and then the recent string. Some of them have fuzzy search features where you can look for the word “spam” or look for the word “invalid,” and stuff like that. Others don’t make it so easy at all. Others, it’s a special feature request you have to tell them to turn on, because you kind of know your stuff and you want to get into the weeds with it. Others still, it’s not even an option. They could tell you that it’s, you know, “We’re sorry, we manage this stuff on our side.” You know, most users aren’t interested in this stuff. So mileage may vary, but it’s going to look something like this, where you’ll have a table where you can go and review your response codes, hopefully do some sorting and filtering and exporting and all that stuff. It’ll be a little bit different everywhere.
AC
Beth, what are some of the helpful use cases of when having access or when reviewing a bounce log like this with response codes would be helpful?
BK
Sure. I think any time that you see a drop in your inbox rate, it’s helpful to look at your bounces. Bounces sometimes have really useful information. Sometimes they call out a blacklist and even have, a postmaster address sometimes or a remediation form. So, for reputation troubleshooting methods; definitely, looking at bounces is helpful for that. Then, any time that you’re doing a change to your mailing structures, so if you’re doing IP warming, you want to monitor your bounces to see if you’re connecting too fast, or any time you’re increasing your sending speed or volume, you want to monitor your bounces to look for a reaction to that change.
LM
And oftentimes in these responses, they’re vague and they just tell you, “message delayed, try again later.” But it’s not rare to see things actually as specific as a message deferred due to user complaints. So now you can go do your soul-searching to figure out why too many people are marking your mail as spam. Sometimes it can say message delayed because of too many invalid addresses. It’s like, “Wow, I have a list collection problem,” that you may not have known about if you weren’t looking at this stuff. So it can range from being like, “This isn’t telling me anything other than the message didn’t work,” to really valuable, immediately actionable stuff. And I’d say it’s worth your time to familiarize yourself with these things.
AC
Yeah, it sounds like it’s free information. It’s only helpful data to further diagnose a potential problem, as mentioned, a blacklist or too many user complaints or you know, another example that I’ve seen is sending speed and sending too much mail, too fast. They’re saying, “Whoa, slow down, you’re being throttled. Try again later.” So, there’s definitely some very helpful diagnostics intel and response codes that, if you aren’t paying attention, it’s there. You just got to find it.
I want to thank you guys both for contributing to this topic. And I think, again, SMTP response codes are something that can be extremely helpful for any marketer sender, whether it’s onboarding and taking a pulse of warming up new IPs or domains or mediating issue, and just familiarize yourself with them there. They’re quite helpful.
Thanks, everyone, for watching.