What I didn’t talk about was how badly broken the ESP was in handling my complaint. The ESP was, like many ESPs, an organization that grew organically and also purchased several smaller ESPs over the course of a few years. This means they have at least 5 or 6 different domains.

The problem is, they don’t effectively monitor abuse@ for those different domains. In fact, it took me blogging about it to get any response from the ESP. Unfortunately, that initial response was “why didn’t you tell us about it?”

I pointed out I’d tried abuse@domain1, abuse@domain2, abuse@domain3, and abuse@domain4. Some of the addresses were in the mail headers, others were in the ESP record at abuse.net. Three of those addresses bounced with “no such user.” In other words, I’d tried to tell them, but they weren’t accepting reports in a way I could access.

Every ESP should have active abuse addresses at domains that show up in their mail. This means the bounce address domain should have an abuse address. The reverse DNS domain should have an abuse address. The d= domain should have an abuse address.

And those addresses should be monitored. In the Dell case, the ESP did have an active abuse@ address but it was handled by corporate. Corporate dropped the ball and never forwarded the complaint to the ESP reps who could act on the spam issue.

ESPs and all senders should have abuse@ addresses that are monitored. They should also be tested on a regular basis. In the above case, addresses that used to work were disabled during some upgrade or another. No one thought to test to see if they were working after the change.

You should also test your process. If you send in a complaint, how does it get handled? What happens? Do you even have a complaint handling process outside of “count and forward”?

All large scale senders should have appropriate abuse@ addresses that are monitored. If you don’t, well, you look like a spammer.

While digging through my blog posts to see if there was any help I could provide, I realized I don’t have a guide to resolving blocking issues at ISPs. Much of the troubleshooting can be done without ever contacting the ISPs or the blocklists.

Identify the issue.

There are a number of techniques that ISPs use to protect their users from malicious or problematic mail, from rate-liming incoming mail, putting mail in the bulk folder, or blocking specific IP addresses. Step one to resolving any delivery problem is to identify what is happening to the mail. In order to resolve the issue, you have to know what the issue is.

All too often, the description of a delivery problem is: My mail isn’t getting delivered. But that isn’t very clear as to what the actual problem is. Are you being temp failed? Is mail being blocked? Is mail going to the bulk folder? Is this something affecting just you or is it a widespread problem?

Troubleshoot your side.

Collect as much data about the problem as you can. Dig through logs and get copies of any rejection messages. Follow any URLs that are present in the bounce messages. Try sending a bare bones email to yourself at that ISP with just URLs, is it still blocked? What if you send from a different IP, does the same thing happen?

There is a lot of troubleshooting a sender can do without having to contact an ISP, and the information can lead to resolution that doesn’t involve having to contact the ISP. Also, many current ISP blocks are dynamic, they come up and go down without any human intervention. Those blocks that require contact to get them resolved have clear instructions in the bounce message.

Fix your stuff.

Whether it’s a reputation issue or a minor technical issue, fix the problem on your end. Just moving IP addresses or changing a URL isn’t a sustainable fix. There is a reason mail is being blocked or filtered and if you don’t fix that issue, the blocks are just going to come back. After you do fix your stuff, expect to see changes in a few days or a week. The ISP filters are generally quite responsive to sender improvements so if you’ve fixed the stuff you should see changes pretty quickly. Expect unblocking or filtering to take a little longer than the block was in place.

If you can’t figure out what the problem is, hire a consultant. Here at Word to the Wise we can often quickly identify a problem and provide a path to resolution. Sometimes the problem isn’t even the ISPs, we’ve had multiple cases where our clients were using custom software and their software wasn’t SMTP compliant and we were able to identify the problem and get their mail working again. There are a host of other independent consultants out there that can also help you identify and resolve blocking problems.

Contact the ISPs.

If there is a hard block or after fixing what you think the underlying problem is, you’ll have to contact the ISP. Many ISPs provide self service websites and contact forms to facilitate this process. Generally, though, most issues aren’t going to require contact.

1. Find out whether mail is actually being blocked, or whether the customer just went to one of the jumbo economy blacklist checker sites.
2. If no mail is being blocked, it’s not an issue.
3. If mail is being deferred (Yahoo…) it’s not the same issue as being blocked, and likely isn’t worth pursuing.
4. If mail is being blocked, don’t take the customers word for why. If they got an email rejected by, say, Earthlink for some reason and then went to the blacklist checker and discovered that they’re listed on FIVETEN, they might grab onto that listing like a rabid terrier when it’s really an irrelevant rathole.
5. Start with the rejection message. If it has a URL in it, that’s all you need to start with.
6. If not, see if it’s consistent – does test mail get rejected. If not, it’s either a transient issue or it’s a content-based block rather than an IP based block, and hence not your problem.
7. If there’s no URL in the rejection, contact the entity that blocked the mail, perhaps.
8. Make a good judgement call about whether it’s worth caring. If it’s just one guy in his Mom’s basement blocking mail then it’s not worth the time or energy to care about the issue.
9. If this is really business-critical for the customer then they should talk to a decent consultant rather than relying on their abuse desk for assistance.

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.

Barry: I see your “too many recipients” and raise you a “DNS failure.”

Me: You’re joking.

Barry: “Unknown address error (’550′, ['REQUESTED ACTION NOT TAKEN: DNS FAILURE'])

Me: That seems pretty self explanatory. I would close the ticket with a “not a mail issue.”

Barry: It wasn’t a ticket. It was a direct mail to me by a very well known person on the sender side. You’d die if you knew who it was. But he didn’t send me anything useful, not even an IP address.

Me: You’re kidding? Please tell me you’re kidding. Please.

This is yet another example of people bothering Barry with questions that should be answerable by anyone who holds themselves up as a delivery expert. Really.

Barry is not your free consultant. Barry has a job and it does not involve troubleshooting problems on your end. Asking questions about stupid stuff like “too many recipients this session” or “DNS failure” is why most Barry’s don’t hand out their info to senders. They don’t want to be bothered with questions just because the sender is too stupid or lazy to do their own troubleshooting.

There are two things that come to mind immediately when I see this error message and two things that I would check before even considering contacting someone.

1. This is an internal DNS failure and the MX lookup on the sender’s side failed. The sender should do a manual DNS lookup and confirm they can get a MX record (or A) record for the recipient domain.
2. This is a DNS failure on the receivers side. A little harder to troubleshoot, but some ISPs check the DNS of the sending domain before accepting mail. Make sure that the domain exists in DNS and is answering queries promptly.

Once you have checked DNS and everything is OK you can move to the next step. Open up a telnet session to the mail server and do a manual SMTP session. Use the same Mail From: and Rcpt To: that generated the 550 you’re attempting to troubleshoot. You don’t need to do the whole session, just through Mail From: and Rcpt To:.

If the Mail From and Rcpt To: addresses are accepted by the receiver mail server, then go back into your MTA and resend the message that originally failed.

It works, you’re done. If not, go back and think about what else might cause a DNS failure, then test it. Same as you did above. Repeat.

EDIT: While writing the post, I heard back from Barry. The problem was that the sending domain did not exist in DNS. This issue would have been identified at the 2nd DNS check. No mail to Barry needed.