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.

What is the problem?

Be very specific about the problem you see. The fix for mail going to the bulk folder can be very different from the fix for a Spamhaus listing. The fix for a Spamhaus DBL listing is going to be different than the fix for a ROKSO listing. The more specific you can be about the problem the more likely people can answer your question.

Bad:

  • I’m having a delivery problem.
  • None of my mail is delivering.
  • I need delivery help.

Better:

  • My mail is going to spam.
  • My IP address is listed on the SBL.
  • ISP is deferring my mail.

Where are you seeing this?

It’s important to be specific about where the problem is happening. Are you actually having mail problems? Or did you drop your IP or sending domain into a webpage that came back and told you that it was listed somewhere?

Bad:

  • My mail is blacklisted
  • We’re being blocked

Better:

  •  toolname is telling me that our IP is listed on blocklist
  • My delivery reports show that ISP is deferring mail from our IP address
  • We’re not getting any opens at ISP and my tests show mail from our domain is going to the bulk folder.

When did this start?

Many delivery problems are transient and will come and go in a matter of hours. Once the delivery problem is gone, it’s difficult to troubleshoot it. Waiting a few hours or even overnight will make it clear if this is something transient or if it’s the start of a real problem. Jumping at every little delivery problem is exhausting.

On the other hand, if a delivery problem goes on for a few days it’s unlikely to self resolve. You don’t want to let problems fester for weeks or months. The longer a delivery problem goes on the longer it’s going to take to repair any reputation damage.

Bad:

  • Worrying about delivery problems in the first few moments after sending mail
  • Waiting more than a year before addressing delivery problems.

Better:

  • Giving mail 12 – 24 hours before looking at delivery.
  • Monitoring delivery on an ongoing basis and addressing things within a few weeks of the first sign of problems.

Know your mail

Every, and I do mean EVERY, delivery person should know how to check headers and should be at a minimum able to identify the headers used in authentication. (the description I’ve been meaning to write but haven’t yet). The really easy way to do it is grab the information out of your gmail inbox. Gmail provides an easy to read interface into headers that shows exactly what they’re seeing in terms of SPF, DKIM and DMARC. There’s also a handy “how long it took mail to get from the google.com mail servers into the users’s inbox” counter – letting you know if problems are on the sending or the receiving end.

Knowing your mail includes knowing what you’re using as a mail from (5321.from, bounce string). Is it your domain or the ESP’s domain? Are you signing with DKIM? What’s the from address your recipients see?

Do you know if you’re sending from a dedicated IP? A shared pool? Are you using an ESP, a mail relay service or are you sending out over self hosted servers?

One of the big use cases here is Google Postmaster Tools. Many senders are confused because they are seeing DKIM passing but SPF failing, only to discover that the domain authenticated by SPF is actually the ESP domain, not theirs.

Anyone answering questions is going to need to know the following information. And, yes, you’re probably going to have to share the actual IP address and domain if you really want folks to help.

Collect the information:

  • Sending IP
  • Pool type (shared or dedicated IP)
  • 5321.from
  • 5322.from
  • d= value
  • ESP or MTA
  • Email address sources (including those of less than squeaky clean provenance)
  • Frequency of mailing
  • How long the IP has been in use
  • Age of domain

How we help

These days there are very few magic wands to fix delivery problems, whether you’re peer sourcing delivery help or working with a paid professional. Anyone helping you troubleshoot and fix delivery problems needs to know the who, what, when, and where in order to understand the why. Only once they understand they why, can they help you with the how to fix it.

Related Posts

Tools aren’t a luxury

I was on the phone with a colleague recently. They were talking about collecting a bit of data over the weekend and mentioned how great it was they had the tools to be able to do this. Coincidentally, another colleague mentioned that when the subscription bombing happened they were able to react quickly because they had a decent tool chain. I’ve also been working with some clients who are dealing with compliance issues but don’t have the tools they need.

Read More

Thinking about filters

Much of the current deliverability advice focuses on a few key ideas:

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