Why Deliverability Depends

A common complaint about the advice or answers any deliverability person gives is that the generic answer to questions is: It Depends. This is frustrating for a lot of folks because they think they’re asking a simple question and so, clearly, there should be one, simple, clear answer.

The problem is that there is almost never one answer in deliverability and details do matter.

Let’s take a common question: How do I authenticate my email so that it meets the new Yahoogle standards? It’s a simple question, and gets the simple answer: you need to sign with your own domain in DKIM and publish a DMARC record for the domain in your 5322.from address.

That’s not a wholly complete answer, though, and won’t always address the full needs of the organization. What if the domain in the 5322.from is a subdomain? What about all the other mailstreams?

Before any good deliverability person can give you a good answer that question they need to know the following:

  1. How much volume do you send per day that goes to those domains? Not just marketing mail, but also corporate mail, any alerts and transactional mail, any monitoring emails your IT department has set up. Does your volume, on any day go over 5000 messages to those domains?
  2. What are your sources of all those types of emails? I’m going to assume marketing uses one ESP, and possible a second ESP handles transactional mails.
  3. What’s your corporate outbound setup?
  4. Does your ESP allow you to set up custom Return Path domains? Have you done that? What is that domain?
  5. Are you on a dedicated IP address or a shared IP address for your ESP mail?
  6. Do you want to use different d= values for different mailstreams or do you want to use the same d= for all your mailstreams?
  7. What’s your current authentication scheme?

That’s one example of a simple question that when you start to dig under the covers, doesn’t actually have a simple answer that covers all your use cases.

A banner saying "Deliver Ability Depends" with the hashtag deliverability week
Image Credit: Travis Hazlewood

What are you trying to do?

That was a relatively simple authentication question I asked above. There are clear and precise answers, but there are also clear and precise answers that have the ability to screw up other parts of your mailstream. We don’t want to give advice that fixes your problem but breaks something elsewhere in your mail stream. There are lots of ways to break email, trust me, I’ve discovered a lot of them through the years and am sure I’ve not found all of them yet.

The answers to complicated questions are even harder. “How do I fix my reputation at Gmail?” is a good example. The simple answer is: “Send mail only to people who want it and who are receiving mail in their inbox for a period of time and then increase the volume slowly and with good recipients.” But that’s not really explaining how, is it? That’s the method, but the detail of which recipients to pick, the details of which addresses to ramp with, aren’t in the answer. It’s a technically correct answer but a practically useless one.

Multiple methods, one right method

In most cases any “how do I” question in deliverability has multiple answers that will all work. Some of those answers are more appropriate than others for a particular situation. When we say “… it depends” it means we can give you a five answers, but if you want the appropriate one for your situation, then you’ll need to give us more details.

Image of a train switching yard with multiple tracks and many switches.
Bahngleise am Hamburger Hauptbahnhof

I know it’s frustrating to hear the answer “it depends” when it comes to email and deliverability. But email and deliverability are parts of a complex system with many choices. There are many paths to the inbox. Knowing the details of a situation is crucial to getting you the right answer, not just the generic answer.

It really does depend.

Related Posts

Are seed lists still relevant?

Those of you who have seen some of my talks have seen this model of email delivery before. The concept is that there are a host of factors that contribute to the reputation of a particular email, but that at many ISPs the email reputation is only one factor in email delivery. Recipient preferences drive whether an email ends up in the bulk folder or the inbox.

The individual recipient preferences can be explicit or implicit. Users who add a sender to their address book, or block a sender, or create a specific filter for an email are stating an explicit preference. Additionally, ISPs monitor some user behavior to determine how wanted an email is. A recipient who moves an email from the bulk folder to the inbox is stating a preference. A person who hits “this-is-spam” is stating a preference. Other actions are also measured to give a user specific reputation for a mail.
Seed accounts aren’t like normal accounts. They don’t send mail ever. They only download it. They don’t ever dig anything out of the junk folder, they never hit this is spam. They are different than a user account – and ISPs can track this.
This tells us we have to take inbox monitoring tools with a grain of salt. I believe, though, they’re still valuable tools in the deliverability arsenal. The best use of these tools is monitoring for changes. If seed lists show less than 100% inbox, but response rates are good, then it’s unlikely the seed boxes are correctly reporting delivery to actual recipients. But if seed lists show 100% inbox and then change and go down, then that’s the time to start looking harder at the overall program.
The other time seed lists are useful is when troubleshooting delivery. It’s nice to be able to see if changes are making a difference in delivery. Again, the results aren’t 100% accurate but they are the best we have right now.
 

Read More

August 2016: The Month in Email

August was a busy month for both Word to the Wise and the larger world of email infrastructure.
IMG_0026
A significant subscription attack targeted .gov addresses, ESPs and over a hundred other industry targets. I wrote about it as it began, and Spamhaus chief executive Steve Linford weighed in in our comments thread. As it continued, we worked with M3AAWG and other industry leaders to share data and coordinate efforts to help senders recover from the attack.
In the aftermath, we wrote several posts about abuse, blocklists, how the industry handles these attacks currently, and how we might address these issues going forward. And obviously this has been on my mind before this attack — I posted about ongoing problems with internet security, how open subscription forms contribute to the problem, and other ways that companies inadvertently support phishing operations.
I posted about the history of email, and recounted some of my earliest experiences, when I had a .bitnet and a .gov address. Did you use email before SMTP? Before email clients? I’d be curious to hear your stories.
Speaking of email clients, I did two posts about how mail gets displayed to the end user: Gmail is displaying authentication results, which should provide end users with a bit more transparency about how authentication is used to deliver or block messages, and Microsoft is partnering with Litmus to improve some of the display issues people face using Outlook. These are both notable — if this is not your first time reading this blog, you know about my constant refrain that delivery is a function of sending people mail they want to engage with. If the mail is properly formatted and displayed, and people have a high degree of confidence that it’s been sent from someone they want to get mail from, that goes a long way towards improving engagement in the channel.
On that note, I spoke at length with Derek Harding about how marketers might change their thinking on deliverability, and he wrote that up for ClickZ. I also participated in the creation of Adobe’s excellent Teaching the Email Marketer How to Fish document (no, not phish…).
Steve was very busy behind the scenes this month thinking about abuse-related topics in light of the SBL issues, but he wrote up a quick post about the Traffic Light Protocol, which is used to denote sensitive information as it is shared.
Finally, for my Ask Laura column this month, I answered questions about delivery and engagement metrics and about permissions with purchased lists. As always, if you have a general question about email delivery, send it along and I’ll consider it for the column.

Read More

Why Deliverability Matters to Me

Welcome to deliverability week. I want to especially thank Al for doing a lot of work behind the scenes herding this group of cats. He’s an invaluable asset to the community.

Read More