Al has a guest post up from an ISP rep (now universally referred to as Barry) about senders contacting ISPs. It lists things senders do that Barry Don’t Like.
Listen to Barry.
There are also comments from various other Barrys in the comments. Those are worth reading, too.
Deliverability is a term so many people use every day, but what do we really mean when we use it? Is there an accepted definition of deliverability? Is the concept different than delivery?
At a recent conference I was running a session talking about email delivery, senders and the roles senders play in the email industry and at that particular organization. The discussion went on for a while, and the subject of deliverability versus delivery came up. J.D. Falk had a comment about the difference that resonated with me. Paraphrased, he said:
There is no such thing as a delivery emergency. They just do not happen.
Delivery is fluid, delivery is changing, delivery is complex.
But when delivery goes bad it is not an emergency. There is no need to call up an ISP person at home on a Saturday afternoon and ask them to remove the filters. (And, BTW, experience indicates if you do this that you may have future delivery issues at that ISP.)
I’m sure that people will provide me with examples of delivery emergencies. And, in some cases I might even concede that the receivers will be happy to receive email immediately when it was sent. However, email as a protocol was designed for store and forward. It was not designed to transmit messages instantaneously from sender to receiver. Sure, it works that way much of the time these days. On the whole the Internet is fairly reliable and major servers are connected 24/7 (which wasn’t always the case).
Among many people, particularly recipients and ISP employees, there isn’t the expectation that bulk email is instantaneous. This leads to the belief that delivery problems are not an emergency. Everyone faces them, they get dealt with, life goes on. Demanding an escalation to deal with a “delivery emergency” may backfire and slow down how long it takes to get a response from an ISP.
Part 3 in an ongoing series on campaign stats and measurements. In this installment, I will look a little closer at what other people are measuring about your email and how that affects your reputation at the ISPs.
Part 1: Campaign Stats and Measurements
Part 2: Measuring Open Rate
Reputation at the ISPs is an overall measure of how responsive recipients are to your email. ISPs also look at how much valid email you are sending. Anything the ISP can measure and use to distinguish good mail from bad is used in calculating reputation.
Some of the major metrics ISPs use include the following.
Invalid Address Rates
The ISPs count how much mail from any particular IP address is hitting non-existent addresses. If you are mailing a large number of email addresses that do not exist (550 user unknown), this is a suggestion that your address collection techniques are not very good. Responsible mailers do have the occasional bad address, including typos, expired/abandoned addresses, but the percentage in comparison to the number of real email addresses is low. How low is low? Public numbers suggest problems start at 10% user unknowns, but conversations with ISP employees show they consider lower levels a hint there may be a problem.
To calculate bounce rate ISPs take the total number of addresses that were for invalid accounts and divide that by the total number of addresses that the sender attempted to send mail to. Rates above 10% may cause significant delivery issues on their own, rates lower that 10% may still contribute to poor delivery through poor reputation scores.
Spamtraps
ISPs pay a lot of attention to how much mail is hitting their “trap” or “bait” accounts. There are a number of different sources of these trap accounts: old abandoned email addresses, addresses that never existed or even role accounts. Hits to a trap account tells the ISP there are addresses on your list that did not opt-in to receive mail. And if there are some addresses they know about that did not opt-in, it is likely that there are other addresses that did not opt in.
Spamtraps tend to be treated as an absolute number, not as a percentage of emails. Even a single spamtrap on a list can significantly harm delivery. According to the ReturnPath Benchmark report lists with a single spamtrap had nearly 20% worse delivery than lists without spamtraps.
This is spam clicks (FBL complaints)
Complaints from users are heavily used by ISPs. This tells them directly how many people are objecting to your email. In this case, permission is removed from the equation. Even if a sender has permission to send email, the recipient can say “no, I don’t want this, it is spam.” The ISPs put more weight on what their users tell them than on what the senders tell them.