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

Updated M3AAWG Best Practices for Senders

M3AAWG has published a new version of the Senders Best Common Practices document and the contains a lot of new information since the original publication in 2008. The new document covers how to vet ESP customers, considerations when selecting a dedicated or share IP to send mail, and includes best practices on a number of technical processes.
The Senders Best Common Practices document is targeted at deliverability teams and email marketers. Any company that is sending marketing emails, using an Email Service Provider, or provides an email enabled platform, it’s always good to go back and periodically review your system to ensure nothing was missed and to stay up-to-date on all new recommendations.
A few of the recommendations include the use of the List-Unsubscribe header, publishing a clear WHOIS for domains used for sending mail, and how to process non-delivery report messages.
The List-Unsubscribe header provides an additional way for users to opt-out of email messages. Gmail and Outlook.com both use the presence of the list-unsubscribe header to provide a one-click button to allow the user to unsubscribe from the mailing list. Often enough, if a user cannot find an opt-out link, they’re marking the message as spam. Allowing a recipient to unsubscribe easily is critical to maintaining good delivery reputation.
A WHOIS is query to determine who is the registered user or assignee of a domain name. During a session at the most recent M3AAWG meeting, it was announced that spammers throw away 19 million domains per year. When a postmaster or abuse desk receive a complaint, they’ll often query to see who owns the domain the email was sent from or who owns the domains used in the hyperlinks. If the WHOIS record is out of date or set to private, this limits the ability for the postmaster or abuse desk to reach out to the owner of the domain.
Processing non-deliver reports is critical to maintaining a high delivery reputation. Many ESPs have an acceptable-use-policy that includes a bounce rate. Mailjet recommends a bounce rate of less than 8% and Mandrill recommends less than 5%. If a system is not in place to remove the hard bounces from your mailing list, the sender’s reputation will quickly deteriorate.
The Senders Best Common Practices document can be downloaded at M3AAWG.org.
 

Read More

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