Share or Save

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.

[This info is provided by us. We get you to the inbox. Learn how here.]

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.

Prefer to listen to the podcast? Listen on Apple, Google, Amazon, Audible, Spotify, or Anchor or say "Alexa play the Everything Email Marketing podcast"

 

Full Post Archives


Share or Save

No responses yet

Leave a Reply

Your email address will not be published.


We are ISIPP SuretyMail, the original certified sender program and email deliverability service. Learn more here
Search
Generic selectors
Exact matches only
Search in title
Search in content
Post Type Selectors
Search in posts
Search in pages
Filter by Categories
Blocklists and Blacklists
Content Issues
Deliverability
Email Authentication
Email List Building
Feedback Loops
Mailing List Hygiene
Monitoring and Tracking
Opt-in Practices
Our News
Privacy & Email Laws
Sending Practices
Spam Complaints
Technical Stuff
The Industry
Topics
Need Help Getting to the Inbox?
If you need help getting out of the spam folder and into the inbox, we're here for you. Our deliverability services come with a personal touch, and we get results. That combination has created customer loyalty that's nearly unheard of. (testimonials)
Read what we'll do for you here.

Join our email community and get
How to Stay Out of the Spam Folder 
& How to Grow Your Email List free!


 Get to the Inbox by SuretyMail
The Original Email Deliverability Company

Free stuff!
Close
Skip to content