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

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.

Read More

Deliverability Help: Information checklist

When asking a for assistance with email delivery, there are some pieces of information that are required before anyone can help. Be prepared with the information so you can get timely assistance. This advice is true whether you’re looking for help from peers or working with paid deliverability consultants.

Read More

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