Who can you trust?

I’ve been recently dealing with a client who is looking at implementing authentication on their domains. He’s done a lot of background research into the schemes and has a relatively firm grasp on the issue. At this point we’re working out what policies he wants to set and how to correctly implement those policies.
His questions were well informed for the most part. A few of them were completely out of left field, so I asked him for some of his references. One of those references was the EEC Email Authentication Whitepaper.
My client was doing the best he could to inform himself and relies on industry groups like the EEC to provide him with accurate information. In this case, their information was incomplete and incorrect.
We all have our perspectives and biases (yes, even me!) but there are objective facts that can be independently verified. For instance, the EEC Authentication whitepaper claimed that Yahoo requires DKIM signing for access to their whitelist program. This is incorrect, a sender does not have to sign with DKIM in order to apply for the Yahoo whitelist program. A bulk sender does have to sign with DKIM for a Y! FBL, but ISPs are given access to an IP based FBL by Yahoo. I am shocked that none of the experts that contributed to the document caught that error.
Independent verification is one reason I publish the Delivery Wiki. It’s a resource for everyone and a way to share my knowledge and thought processes. But other experts can “check my work” as it were and provide corrections if my information is outdated or faulty. All too often, senders end up blaming delivery problems on evil spirits, or using “dear” in the subject line or using too much pink in the design.
Delivery isn’t that esoteric or difficult if you have a clear understanding of the policy and technical decisions at a range of ESPs and ISPs, the history and reasoning behind those decisions, and enough experience to predict the implications when they collide.
Many senders do face delivery challenges and there is considerable demand for delivery experts to provide delivery facts. That niche has been filled by a mix of people, of all levels of experience, expertise and technical knowledge, leading to the difficult task of working out which of those “experts” are experts, and which of those “facts” are facts.

Related Posts

DKIM implementation survey

DKIM has been a hot topic of discussion on some of my mailing lists today. One of the open questions is what is holding up adoption of DKIM. I have my own theories, but thought I’d throw out some questions to see how ESPs and ISPs are currently using domain based reputation.
I have set up two surveys one for ESPs and one for ISPs. Responses are anonymous.
I’ll collect responses for a week and share the results.

Read More

20% of email doesn't make it to the inbox

Return Path released their global delivery report for the second half of 2009. To put together the report, they look at mail delivery to the Mailbox Monitor accounts at 131 different ISPs for 600,000+ sends. In the US, 20% of the email sent by Mailbox Monitor customers to Return Path seed accounts doesn’t make it to the inbox. In fact, 16% of the email just disappears.
I’ve blogged in the past about previous Return Path deliverability studies. The recommendations and comments in those previous posts still apply. Senders must pay attention to engagement, permission, complaints and other policy issues. But none of those things really explain why email is missing.
Why is so much mail disappearing? It doesn’t match with the philosophy of the ISPs. Most ISPs do their best to deliver email that they accept and I don’t really expect that ISPs are starting to hard block so many Return Path customers in the middle of a send. The real clue came looking at the Yahoo numbers. Yahoo is one of those ISPs that does not delete mail they have accepted, but does slow down senders. Other ISPs are following Yahoo’s lead and using temporary failures as a way to regulate and limit email sent by senders with poor to inadequate reputations. They aren’t blocking the senders outright, but they are issuing lots of 4xx “come back later” messages.
What is supposed to happen when an ISP issues a 4xx message during the SMTP transaction is that email should be queued and retried. Modern bulk MTAs (MessageSystems, Port25, Strongmail) allow senders to fine tune bounce handling, and designate how many times an email is retried, even allowing no retries on a temporary failure.
What if the missing mail is a result of senders aggressively handling 4xx messages? Some of the companies I’ve consulted for delete email addresses from mailing lists after 2 or 3 4xx responses. Other companies only retry for 12 – 24 hours and then the email is treated as hard bounced.
Return Path is reporting this as a delivery failure, and the tone of discussion I’m seeing seems to be blaming ISPs for overly aggressive spamfiltering. I don’t really think it’s entirely an ISP problem, though. I think it is indicative of poor practices on the part of senders. Not just the obvious permission and engagement issues that many senders deal with, but also poor policy on handling bounces. Perhaps the policy is fine, but the implementation doesn’t reflect the stated policy. Maybe they’re relying on defaults from their MTA vendor.
In any case, this is yet another example of how senders are in control of their delivery problems. Better bounce handling for temporary failures would lower the amount of email that never makes it to the ISP. This isn’t sufficient for 100% inbox placement, but if the email is never handed off to the ISP it is impossible for that email to make it to the inbox.

Read More

Predictions for 2008

I did not have a lot of predictions for what will happen with email at the beginning of the year so I did not do a traditional beginning of the year post. Over the last 3 – 4 weeks, though, I have noticed some things that I think show where the industry is going.
Authentication. In January two announcements happened that lead me to believe most legitimate mail will be DK/DKIM signed by the end of the year. AOTA announced that approximately 50% of all email was currently authenticated. They did not separate out SPF/SenderID authentication from DK/DKIM authentication, but this still suggests email authentication is being widely adopted. AOL announced they will be checking DKIM on their inbound mail. I expect more and more email will be DKIM signed in response to this announcement.
Filtering. The end of 2007 marked a steady uptick in mail being filtered or blocked by recipient domains. I expect this trend to continue throughout 2008. Recipient domains are rolling out new technology to measure complaints, evaluate reputation and monitor unwanted email in ways that tease out the bad actors from the good. This means more bad and borderline email will be blocked. Over the short term, I expect to see more good email blocked, too, but expect this will resolve itself by Q2/Q3.
Sender Improvements. As the ISPs get better at filtering, I expect that many borderline senders will discover they cannot continue to have sloppy subscription practices and still get their mail delivered. Improved authentication and better filtering let ISPs pin-point blocks. Instead of having to block by IP or by domain, they can block only some mail from a domain, or only some mail from an IP. There are a number of senders who are sending mail that users do not want mixed with mail that recipients do want. Right now, if there is more mail that recipients want in that mix, then ISPs let the mail through. This will not continue to happen through 2008. Senders will need to send mail users actively want in order to see good delivery.
Less is more. A lot of other email bloggers have talked about this, and I will echo their predictions. Less email is more. Send relevant mail that your customers want. Target, target, target. Good mailers will not send offers to their entire database, instead they will send mail to a select portion of their database.
Feedback loops. Use of feedback loops by recipient domains will continue to grow.
Mobile email. More recipients will be receiving email on mobile devices.
Suggestions for 2008

Read More