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

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

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