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

Permission-ish based marketing

My Mum flew in to visit last week, and over dinner one evening the talk turned to email.

Read More

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

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