Anyone know why…

Countless questions about email troubleshooting start with “does anyone know why.” Unfortunately, most of these questions don’t contain enough detail to get a useful answer.

In the case of email, even the smallest redactions, like the IP address and the domain in question, can make it difficult for anyone to provide help. Details matter.
Every detail matters, sending IP and domain are just the beginning. Who’s doing the sending? What is their authentication setup? What IP are they using? How were the addresses collected? What is their frequency? What MTA is used? Are they linking to outside sites? Are they linking to outside services? Where are images hosted?  Is the mail going to the bulk folder or being rejected? What ISPs or filters are involved?
The relevant questions go on and on and on.
We send fairly detailed question lists to clients. I regularly look at them to try and make them shorter. But the reality is these are questions that are relevant. Without enough information we simply cannot troubleshoot delivery problems.
 

Related Posts

Troubleshooting delivery is hard, but doable

Even for those of us who’ve been around for a while, and who have a lot of experience troubleshooting delivery problems things are getting harder. It used to be we could identify some thing about an email and if that thing was removed then the email would get to the inbox. Often this was a domain or a URL in the message that was triggering bulk foldering.
Filters aren’t so simple now. And we can’t just randomly send a list of URLs to a test account and discover which URL is causing the problem. Sure, one of the URLs could be the issue, but that’s typically in context with other things. It’s rare that I can identify the bad URLs sending mail through my own server these days.
There are also a lot more “hey, help” questions on some of the deliverability mailing lists. Most of these questions are sticky problems that don’t map well onto IP or domain reputation.
One of my long term clients recently had a bad mail that caused some warnings at Gmail.
We tried a couple of different things to try and isolate the problem, but never could discover what was triggering the warnings. Even more importantly, we weren’t getting the same results for identical tests done hours apart. After about 3 days, all the warnings went away and all their mail was back in the inbox.
It seemed that one mailing was really bad and resulted in a bad reputation, temporarily. But as the client fixed the problem and kept mailing their reputation recovered.
Deliverability troubleshooting is complicated and this flowchart sums up what it’s like.

Here at Word to the Wise, we get a lot of clients who have gone through the troubleshooting available through their ESPs and sometimes even other deliverability consultants. We get the tough cases that aren’t easy to figure out.
What we do is start from the beginning. First thing is to confirm that there aren’t technical problems, and generally we’ll find some minor problems that should be fixed, but aren’t enough to cause delivery problems. Then we look at the client’s data. How do they collect it? How do they maintain it? What are they doing that allows false addresses on their list?
Once we have a feel for their data processes, we move on to how do we fix those processes. What can we do to collect better, cleaner data in the future? How can we improve their processes so all their recipients tell the ISP that this is wanted mail?
The challenging part is what to do with existing data, but we work with clients individually to make sure that bad addresses are expunged and good addresses are kept.
Our solutions aren’t simple. They’re not easy. But for clients who listen to us and implement our recommendations it’s worth it. Their mail gets into the inbox and deliverability becomes a solved problem.

Read More

Troubleshooting email delivery

Mark Brownlow has a post up explaining how he discovered some problems with delivery at Gmail by digging deeper into his statistics. Mark goes through his thought process including his initial conjecture on what might be causing the problems and then how he looked at the data to see if his supposition fit the data.
I love this post. It is so refreshing to watch someone document how they asked questions, then looked at data to find out the answers. Too many people treat best practices in email delivery as a set of rules that are meant to be broken. Instead of actually asking questions and determining what is best for their market and their recipients they implement best practices.
Following best practices isn’t exactly a bad thing, the reason they’re best is because they’re easy to communicate practices that will not result in bad outcomes. But, they’re not always the ideal practices for a specific situation. Best practices are ones that work across a wide range of senders and situations. Blindly implementing best practices will not always result in the best outcome for each situation.
Mark’s post is a tutorial in the art of looking at email delivery. I think there is a need for more of those kinds of posts, explaining the process from identifying an email problem through to confirming that is actually the problem and then testing potential fixes. I’ll be posting troubleshooting guides here over the next few weeks and months. If you have an issue you think would be an interesting case study drop me an email and we’ll go through it.

Read More

I'm on a blocklist! HELP!

Recently, an abuse desk rep asked what to do when customers were complaining about being assigned an IP address located on a blocklist. Because not every blocklist actually affects mail delivery it’s helpful to identify if the listing is causing a problem before diving in and trying to resolve the issue.

Read More