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.

Two things happened today to reinforce that.

1. Yahoo announced they were having incoming MTA issues again, causing them to non-specifically defer mail. This has been going on for almost a week, causing mail delays all over the net. Other ISPs are dealing with backups and delays. Bulk senders are also seeing problems across the board.
2. Yesterday I received email from a local brew pub about their tapping party for a new beer. Usually these announcements come 10 – 12 days before the actual party so I mentally noted that the tapping party was “coming up.” Today we went to the same pub for lunch, and discovered the party was last night and we’d missed it. Well, bummer.

In one case email delays are technical, in they other case they’re user error. In both cases, they’re things that senders can’t really control, though.

ISPs and other receivers build their data centers with the needs of their customers in mind, and you are usually not their customer. When every relative your customer has wants to send mail inviting them to Christmas dinner (all at the same time) and you and every other marketer in the world want to send them mail inviting them to shop at your all-important sale (all at the same time), it overloads the available capacity of your customer’s ISP. While they do build their systems (more or less) robustly and with many normal, seasonal surges in mind, you have to understand that sometimes something happens that means that your email will not arrive instantaneously.

Al Iverson tweeted yesterday alluding to the same complaint from one of his customers.

Hey, don’t yell at your ESP when we can’t make ISP X accept your mail faster…. we don’t run the entire universe yet.

There are certain bits of delivery a sender or ESP can control, and there are some things a sender or ESP can’t control. Capacity at the ISPs is one thing a sender can’t control, and when everyone is sending mail at the same time, everyone is going to see delays.

One commentor on that Spamtacular post claimed that anti-spam was “a racket” and that there were simple solutions to the spam problem. In response to that comment, Annalivia wrote an detailed rebuttal, talking about exactly what was happening on the ISP side of the fence.

ISPs are laying people off right and left. The premise of allowing spam to flow just to justify the purchase of expensive new toys is nonsense. It takes money to buy additional appliances to handle the overhead of unwanted email. ISPs don’t *have* that money. Mickey’s original post was all about the reasons why email is sometimes delayed. One of those reasons is the lack of sufficient resources to handle the flow. Why are those resources lacking? NO MONEY. There’s a major economic crisis going on [...]

Email marketing may be one area that isn’t being hit hard by the current state of the economy. But the ISPs are struggling, and expecting them to invest money they don’t have so that marketers can have instantaneous email delivery is folly.

There will be delivery problems due to network congestion and too much mail for ISPs to handle. Marketers can’t do anything about this except send mail and wait for it to be delivered. In an ideal world there would be sufficient resources for all. We don’t live in an ideal world, and in the cooperative environment of the Internet, everyone has to be respectful of the resource limitations of everyone else.

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.