The nice folks over at Postmark shared a new deliverability resource last week. The SMTP Field Manual. This is a collection of SMTP responses they’ve seen in the wild. This is a useful resource. They’re also collecting responses from other senders, meaning we can crowdsource a useful resource for email deliverability folks.
It’s that time again… here’s a look at our last month of blog posts. We find it useful to recap each month, both to track trends and issues in email delivery and to provide a handy summary for those who aren’t following along breathlessly every single day. Let us know if you find it useful too!
As always, I wrote about email filters. It’s so important to recognize that filters aren’t arbitrary — they’re detailed instructions that help meet specific user needs, and the more you are cognizant of that, the better you’ll be able to work with them. Additionally, filters aren’t perfect and likely never will be. False positives and false negatives are frustrating, but as long as spam is still a viable business for spammers, they’ll continue to figure out how to work around filters. As such, we can’t expect filters to be 100% accurate in determining what constitutes wanted and unwanted mail.
Part of this, of course, is due to the problem of fraudulent signups. Companies aren’t particularly vigilant about address acquisition and hygiene, and as a result, they’ll claim you “signed up” for their email when you did not. Some people believe that a confirmed opt-in (COI) will solve this problem, but our experience is companies are reluctant to leave revenue on the table, and that they will continue to mail to addresses that have not confirmed.
Address sharing and co-reg is also part of the problem. As we saw in the extensive RCM data breach, many major brands continue to work with third-party senders to send mail in ways that are quite clearly spam. And in more criminal activity, I looked at the rise of botnets and how some of those criminals were brought to justice. In other justice news, there’s been an indictment in the Yahoo breach and another CASL enforcement action.
I wrote a post about bounce handling and “relaying denied” error messages, which are quite rare. It’s useful to have an understanding of these and other error messages, since bounces are sometimes indicative of a larger technical issue, such as when AOL accidentally bounced all messages for a short period last week. Speaking of AOL, we noted that there’s no official timeline for the move from Verizon addresses to AOL addresses following the 2015 acquisition, but it may be worth considering asking your customers to update their addresses.
Spam and filters aren’t the only factors of course. It can be challenging to figure out the multiple factors that make up the black box of delivery. And of course, the most important part of delivery continues to be engagement, engagement, engagement.
I wrote a few posts this month on why I do what I do, and why it’s so important to me. First, I wrote about A Day Without A Woman, and my choice not to participate in offering advice and guidance for that day. The truth is that I enjoy sharing what I know and helping people solve problems. I was honored to be named one of 11 Innovators in Email, and I know that my volunteer work in the industry and my unpaid blogging work is a big part of that. It may sound corny, but I really do believe we are on the front lines of the fight of good vs. evil online, and despite the distractions of politics and world events, we must all continue to do our part.
It should be easy, right? Except it’s not. So why is it so hard?
With one-on-one or one-to-few email it’s pretty simple. The rejections typically go back to a human who reads the text part of the rejection message and adapt and makes the decision about future messages. The software handles what to do with the undeliverable message based on the SMTP response code.
In the case of a 5xy response the server stops attempting delivery and alerts the original sender the mail failed. One example from helping a client troubleshoot a delivery problem recently.
There’s useful information in the text portion of this email from my mail server. It says there was a permanent failure (550) and that my message won’t be delivered. It also says the email is quarantined in reply to the end of DATA. That’s actually a critical piece of information. It means Barracuda saw the entire message before deciding to reject it. It’s likely a problem with the content of the email and so I need to look at links in the message.
This type of plain text explanation is great for a human to read and act on. But it’s not that simple for list handling software to identify the relevant information in the text message and act on future emails to that recipient. Different MTA vendors and ESPs have done a lot of work to try and correctly parse bounce messages to pull out relevant information.
ISPs have tried to help the situation by giving more descriptive rejection messages. They’re still using the SMTP required 3 digit numbers, but they include short, parseable codes in the text portion of the message. In many cases they also include URLs and links that open up webpages explaining the meaning of the code. They even post a list of the most common codes on their postmaster webpages.
All of these things make it somewhat easier to handle bounces automatically. Kinda.
I’ve been working on some bounce handling recommendations for a client using a few different ESPs. I spent a good few days digging into the bounces returned by their different ESPs. It was an interesting exercise as it demonstrated how very differently ESPs handle bounces. But it also clarified for me that there are a lot of different kinds of bounces.
I’ve got multiple clients right now looking for insights about bounce handling. This means I’m doing a lot of thought work about bounces and what they mean and how they match up and how different ISPs manage delivery and how different ESPs manage delivery and how it all fits together. One thing I’ve been trying to do is contextualize bounces based on what the reason is.
Despite what people may thing, spam filtering isn’t the only reason an email fails to deliver. There are lots of other reasons, too. There is a whole category of network problems like routing issues, TCP failures, DNS failures and such. There are address issues where a recipient simply doesn’t exist, or is blocking a particular sender. There are spam and authentication issues. The discussion of all these issues is way longer than a blog post, and I’m working on that.
One of the interesting bounces that is so rare most people, including me, never talk about is “Relaying Denied.” This is, however, one of the easier bounces to explain.
Relaying Denied means the mail server you’re talking to does not handle mail for the domain you’re sending to.
Well, OK, but how does that happen?
There are a couple reasons you might get a “Relaying Denied” message, most of them having to do with a misconfiguration somewhere. For whatever reasons, the receiving server doesn’t handle mail for a domain.
DNS records are incorrect. These can be due to a number of things