I was talking with one of my Barry pals recently and was treated to a rant regarding deliverability experts that can’t manage simple things. We’ve been having an ongoing conversation recently about the utterly stupid and annoying questions some senders ask. Last week, I was ranting about a delivery person asking what “5.7.1. Too many receipts this session” meant. This morning I got an IM.
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.
- 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.
- 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.
RSS - Posts
Great post, something I was discussing with my boss this morning, and something that we have addressed internally at Return Path, to our client base, a few times.
Here’s the thing. Most senders task a marketer to do their email marketing, logically enough. Problem is that is a two-parter. Like “music business” coming as a shock to most musicians who are befuddled by the number of lawyers and accountants involved in the business part of making nice noises on a stage, marketers often times forget the other part or EMAIL marketing.
Email, especially these days is a fairly technical subject, involving all sorts of weird acronyms like FQ rDNS, DKIM, 5.1.1 SURBL, PBL, etcetera, etcetera. You get the picture.
A happy emailing is one that involves the techies down the hall from the marketing department. Just as the propeller heads of the world couldn’t give a tinker’s cuss about segmentation, and branding, marketers aren’t usually attuned to the myriad facets of a solid and clean mailing infrastructure.
Yes, they should get a little more informed, but mostly, they need to make friends with the in-house sys admins at their sites, and make sure they are copied in on all reports, alerts, and so on, so that they might save their company an embarrassing hit to their online reputation when Marketerperson pings Barry, inappropriately.
Email marketing is a team effort. Involve your whole team before bothering Barry. that way, when you do have to darken his door, you are a welcome, or at least tolerated presence, not one that is greeted with a grimace, and less than stellar cooperation.
And, as always, remember, there’s no such thing as an email marketing emergency, no matter what your boss might say. At least there sure isn’t from Barry’s perspective, when he has to deal with a raft of hacked user accounts, spam hammering his inbounds, and someone on an anti-spam list complaining about how HE is the worst spammer in the world due to all those compromised accounts.
One more ranty bit. Yes, this might sound like ‘can’t we all just get along’ forgive me if so.
One thing, on the other side of the coin are techies who think that anyone who doesn’t understand this stuff is intrinsically stupid. Barry, keep in mind they might not know what you do, but it is a logical leap to think that a blindspot in a knowledge-base or even an incapacity to grok stuff means your interlocutor is stupid. Their brain just works differently and they may well be very very smart in other areas that you are not.
@Neil It’s not that “we” think that anyone who doesn’t understand this stuff is intrinsically stupid – rather it’s that we think anyone whose job description includes diagnosing email delivery who can’t read one of the most basic error messages is not competent to do their job.
I wouldn’t expect anyone other than a postmaster or an email delivery wonk to be able to diagnose that sort of problem in their sleep – but in this case we’re talking about an email delivery wonk who is paid to do exactly that, yet who is not capable of doing so.
Combine that with an expectation that they don’t need to learn this stuff, as they can always rely on someone else to do their job for them, and you end up with someone who will alienate people with the “trivial” stuff to the extent they won’t get willing assistance when they really do need it. (I’m assuming that they’re bothering Barry in this case because either they’ve already alienated their internal IT folks, or don’t want to demonstrate to their colleagues that they’re not actually doing the job they’re paid for).
Oh, one more thing, last one, I promise, I see your rDNS, Barry, and raise you an unknown user.
I suspend a client for 550s. Get an email back ‘who are these unknown users, and why are they complaining about my email?’
Care to raise me on that one?
If they are simply stupid, the response is usually “talk to someone not as stupid as you.” If they are simply lazy, the response is “do your own job.” If they are neither stupid nor lazy, then the query is probably somewhat valuable for us to address.
Neil: I would assume that your client who didnt know what an unknown user was, hired you guys to handle the tech part for him. Now, if YOU said you didn’t know what that meant, you’d win the Tard Question Bingo for sure.
-Yet Another Barry
Neil wrote “Email marketing is a team effort. Involve your whole team before bothering Barry.”
I’d go a step further, and suggest that someone on the infrastructure of a sender organization probably knows what most of the error messages mean, and can diagnose to puzzle out the rest, and most of these questions should probably be addressed to that person first, as a policy.
Then, after the local in-company propellerhead gets sick of the same questions that Barry is already sick of, he’ll create his OWN set of help webpages (that probably look just like Barry’s help webpages) so the end result is that instead of the stupid question being addressed to Barry and responded to with “…well, what does the help webpage on that error say?”, the same exchange can take place, except with the guy down the hall in the same company.