Failed delivery of permission based email

A few weeks ago, ReturnPath published a study showing that 20% of permission based email was blocked. I previously discussed the definition of permission based email and that not all the mail described as permission based is actually sent with the permission of the recipient. However, I only consider this a small fraction of the mail RP is measuring, somewhere in the 3 – 5% range. What happens with the other 17 – 15% of that mail? Why is it being blocked?
There are 3 primary things I see that cause asked for and wanted email to be blocked.

  • technical issues
  • content
  • expectation disconnect leading to user complaints

The technical issues range from actual RFC violating practices to minor nits that makes mail look more like spam than legit mail. The software vendors are getting better and I find less and less problems with the header content in emails. The one exception is some of the websites using Java to generate mail based on user activity. Some of the Java mail classes generate very poor headers which can decrease delivery.
Looking beyond the headers, there are still problems in the body of the email. Base64 encoding plain text, either in the subject line or in the body of the email, has been used by spammers to avoid filtering. Some legitimate mailers use software that base64 encodes plain text email, causing delivery problems. Invalid HTML is also a common mistake that can drastically hurt delivery.
Once senders have confirmed they’re sending correctly formatted, non-RFC violating email, the next big thing to look at is the content of the email. I’m not talking about the number of exclamation points in the subject line, or the word “free” or “unsubscribe” or content like that. I’m talking about more fundamental content. Is the sender selling loans, stocks or male enhancement products? If so, they are going to have delivery issues no matter how good their opt-in process is. Advertising heavily spammed or phished domains, like links to Amazon.com or eBay.com can also decrease delivery of wanted email. Some companies hire lots of different senders to advertise their domain. If they hire LegitMailer.com and they also hire spammers, LegitMailer.com will often see delivery problems based on the content of their mail being found in spam.
When this happens there isn’t much that the sender can do other than avoid the problematic content. I have one client who sends opt-in mail but will occasionally see their mail bulk foldered at major ISPs. Typically this is a one day event, and every time I’ve asked the ISPs they have always blamed the content. The companies my customer is recommending in their mail are also being mentioned in spam and so my customer’s delivery suffers.
Finally, there is sometimes a disconnect between what the recipient thought they were opting into and what the sender actually sends. This can lower a sender’s reputation and delivery. The fixes for this are not as simple as making a few technical fixes or changing the content of the email. This is a longer process and requires more analysis of recipients, what they want and how the sender can meet the recipient’s needs.

Related Posts

The Weekend Effect

Sending mail only Monday through Friday can cause reputation and delivery problems at some ISPs, even when senders are doing everything right. This “weekend effect” is a consequence of how ISPs measure reputation over time.
Most ISPs calculating complaint rate use a simple calculation. They measure how many “this is spam” clicks a source IP generates in a 24 hour period. Then they divide that number by how many emails were delivered to the inbox in the same 24 hour period.
The weekend effect happens when a sender sends on weekdays and not on the weekend thus lowering the number of emails delivered to the to the inbox. Recipients, however, still read mail on the weekend, and they still hit the “this is spam” button on the email. Even if the number of “this is spam” clicks is lower than a normal weekday, with no incoming email the rate of spam complaints goes above ISP thresholds. Even a very well run mailing program may see spikes in complaint rate on the weekends.
Now, when the ISPs are measuring complaint rates over time, they take the average of the average complaint rates. If the rates spike high enough on the weekend (and they can spike to the 1 – 3% range, even for a well run list), that can hurt the senders’ reputation.
The good news is that ISPs are aware of the weekend effect and take this into account when manually looking at complaints. The bad news is that not all of the major ISPs take this into account when programatically calculating reputation.
There isn’t very much senders can do to combat the weekend effect, except be aware this can happen and may be responsible for poor mailing performances on Monday. If you are seeing delivery problems you think may be a result of the weekend effect you can contact the ISPs and ask for manual review of your reputation. Some ISPs can provide manual mitigation for senders with otherwise clean stats. d

Read More

Modifying RP managed FBLs

I was recently pointed out the FBL support pages for those feedback loops hosted by ReturnPath. Clicking around, they have the framework and the beginnings of a good source of information for their services. You can also open support tickets for questions and services that are not covered in their knowledge base.

Read More

Reputation as measured by the ISPs

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.

Read More