One of the most frustrating things for commercial and volume email senders is that different ISPs have different standards for what they require in order to ensure that your email gets delivered. On top of that, many ISPs don’t seem to adhere to the agreed industry standards in terms of how their receiving mail servers interact with the sending mail servers – for example five different ISPs may use five different SMTP error codes when they bounce an email because the email address doesn’t exist, even though people believe there to be one generally accepted code for that situation (along the lines of “550 user unknown”).
So why is this? Why don’t ISPs all play by the same rules, as it were?
There are a few reasons, and as a sender, it helps to understand why one ISP has different rules, systems, and processes from another.
First, ISPs are like any other company – and the larger the company, the more susceptible their processes are to red tape, to “one hand doesn’t know what the other is doing’ syndrome, to corporate hierarchical differences, and, perhaps above all in the Internet industry, to a disconnect between the awareness, understanding, and goals of the executives making the decisions and the technicians who actually have to deal with the day-to-day running of the technical underpinnings of the ISP.
Now add in that the larger the ISP, the more likely it is that they have acquired and not-quite absorbed as many as dozens of smaller regional ISPs. So now you have a situation where a large ISP can actually be operating on several different platforms, with several different email processing infrastructures and architectures – many of which are legacy systems which they inherited as already up and running systems – and you can begin to get an idea of the nightmare that is the average ISP Internet technologists daily reality.
Another piece of this puzzle is that some of the standards on which ISPs and mail senders are operating were developed when the Internet looked very different. The universe of potential statuses of an email address twenty years ago (either it’s a legitimate email address or it isn’t) was much more limited than it is today. So, for example, the 550 SMTP error code which means that the requested action (delivering your email) was not taken because the mailbox was unavailable probably had only a couple of possible meanings twenty years ago (such as “user unknown”), but today there could be any number of reasons that the requested action was not taken and that the mailbox was not available for your mail, ranging from that there is no such email address hosted on that server (user unknown) all the way to that the email address is not available specifically to you because for some reason you have been blacklisted. So while the reasons that email can be rejected have evolved and multiplied, the codes remain much the same, and it’s not hard to see how an ISP may reject or otherwise fail to deliver email without returning an error code that makes sense or is helpful to you.
A third aspect of this is that just as email senders are unable to agree on one universal standard for what they need to do in terms of “best practices” for sending “legitimate email”, so ISPs do not necessarily all agree on what makes for “legitimate email” which they will accept, and what is spam, which they won’t. And actually, many email senders would not want the ISPs to agree, as they would almost certainly agree that the standard would be confirmed (double) opt-in.
Finally, add into the mix that the average ISP is receiving billions and billions of pieces of email every day – nearly all of which is spam, with a little bit of legitimate, non-spam email mixed in.
Put this all together, and you get the current situation: different ISPs having different standards for what they require in order to ensure that your email gets delivered, and sending different messages when it isn’t.
Yes, it’s frustrating for senders, particularly those who view themselves as upstanding senders trying to send legitimate email. But it’s important to remember that it’s hard for the ISPs too, and most of them are trying to do the right thing under onerous circumstances at best.
And, if you want the ISPs to adopt a unified standard for the acceptance and delivery of email, then senders need to adopt a unified standard for acceptable best practices for the sending of email. And they need to be prepared to have any email which does not meet that standard rejected.