5 steps for addressing deliverability issues

Following on from my reading between the lines post I want to talk a little bit about using the channels. From my perspective the right way to deal with 99% of issues is through the front door.
Last week I found myself talking to multiple folks in multiple fora (emailgeeks slack channel, mailop, IRC) about how to resolve blocking issues or questions. All too often, folks come into these spaces and start by asking “does anyone know someone at…” Fundamentally, that’s the wrong first question. Even if the answer is yes. It’s even the wrong question if a representative of the company is on the list where you’re asking for help.
If that’s the wrong question, what is the right question? Where can we start to get help with issues when we’re stuck trying to fix a delivery problem we don’t understand?

1: Read.

Read the full bounce message. The first step is always reading the full bounce message. ISPs are pretty good at providing information in their bounce messages. Look at the full message, and follow any links. Read the information. The links are typically designed for the folks who work in the industry. This means sometimes the language might be jargon. It can take a little work to understand but the help is intended to be there.
In many cases, these information pages will contain links to contact forms for further questions. They’re often not accentuated like a typical call to action. This is intentional. If the visitor is skimming and looking for a contact us button, they’re not actually reading the information on the page. Companies put a lot of time into creating these pages, and try to cover most of the common issues and resolutions in them. Most of the time these pages cover the issue a particular visitor is having.

2: Use the form.

In those cases where the information on the page doesn’t seem to apply, the next step is to use the contact form. Sometimes these forms seem wildly inappropriate, and ask for all sorts of strange bits of information unconnected from the problem. Still, it is best to fill out the form as completely as possible.
There are certain bits of information that are vital for troubleshooting an issue. Things like the sending IP, the domain authentication, any special codes in the bounce string help the sender address the issue. Without those bits of information, it’s nearly impossible for the ISP to answer questions and resolve the blocks.

2a. I can’t find the form.

If you can’t find the form there are a couple things to check. One is to do a text search (⌘-F or alt-F) and search for “contact” or “form” to find the actual link. I do this, sometimes, when I’m in a hurry and my eyes are glazing over the text and I keep missing the link. The second is to search the web. I maintain a list of postmaster pages and links (which is less maintained than I’d like, but I’m working on that). I’m also not the only person who aggregates that data, although most of the links I can find right now focus on the FBL signup pages (ASRG, MAAWG, and Wikipedia).
Sometimes there isn’t a form to fill out. Often this is because the maintainer doesn’t want to or won’t answer questions. There isn’t much to do in these cases.

3: Ask around.

The the previous steps haven’t worked, reaching out for help is the next step. It’s very common for a lot of technical folks to hang out in online spaces to answer questions to help those learning. In the email space, I’d say that was mailop. I regularly see questions in a lot of different places, like public, private and semi-private mailing lists, and slack channels.
There are right ways and wrong ways to ask for help in these fora. That’s probably a whole blog post in itself, but let’s look at some of the highlights.

• Provide the full bounce message
• Provide as much information about your network as possible, including domains and IP addresses.
• State what you’ve done
• State how long (roughly) the problems’ been going on.

Notice I didn’t add in a state what kind of help you want or will accept in that list of bullet points. All too often messages come in looking for direct personal contacts. That’s usually not going to happen, particularly if no one knows you. I’ve blogged about why using personal contacts is bad practice before: Use the form, Follow the script. As J.D. points out in the comments of the second blog post, some of the technical folks shouldn’t be customer facing, so using the channels is better for everyone.

4. Listen.

The answers we get back from requests are not always the answers we want. I mentioned a few of the issues in last week’s blog post. They’re not the only problems. The biggest problem I see is senders not wanting to believe what’s there in black and white. They don’t want to hear the answer or believe it.
I get it. It’s hard to believe that people don’t want that carefully crafted and targeted email. Therefore, the filters must be wrong, it must be a mistake. More often than not, though, the filters are catching the mail they’re designed to catch.
There are, of course, cases where the filters are wrong. Generally that is the only place to use trusted back channels. The folks managing the filters don’t want to hear or listen that they’ve screwed up any more than email senders want to hear it. But when someone who never argues about a filter or a listing sends and email  asking if they meant to block a particular class of mail, those inquiries are taken seriously. Sometimes, as with the listbombing SBL listings, the answer is yeah, actually, we did mean to do that. Other times it’s a ooh, no, let’s fix that.

5. Interpret and act.

The final step is to take the information and act on it. This can be a challenge as often the replies don’t list a set of changes to make. They’re never going to be specific. To quote a post from the mailop list:

What we do for one, we must do for all.
If we can't do it for all, we can't do it at all.

While this statement is from a single ISP, I believe the sentiment is broadly applicable. ISPs do not and will not provide step by step instructions for delisting. They can’t. The minute ISPs start sharing that type of information spammers will take advantage of that. Once again, we all suffer because spammers are jerks.
The good news is dozens of websites, including this one, provide free advice and assistance on how to fix delivery problems. ESPs have extensive internal documentation for customers. Many ESPs have experts on staff to help customers.
Even better that all the free and included resources, there is usually one underlying issue causing delivery problems. Conceptually it’s easy to fix deliverability problems. Delivery fails because recipients aren’t excited about the messages. Solving delivery problems boils down to sending mail recipients expect and want to receive. Figure out how to do that and you’ve solved the long term problem. Solving the short term problem means focusing mailing engaged users.