Damn Nameservers

 

Today on "Things others learned", a client finds out nameservers, when they want to, will 'eff up their deliverability.

This story is the counter to "Damn Beautiful Nameservers." Instead of me oozing praise all over them, I'm going to go all "Negative Nancy" on them. But it's really not their fault. They can't help if it if they are given the wrong information or left unattended.

But what the hell, I'm gonna curse them out anyway otherwise my whole schtick for ISKTBN is ruined.

So today, nameservers aren't my friend, or, I should say, my client's.

And so my story begins...

Far, far way, in a work-from-home office that isn't an office, but holds a desk, computer, and internet connection...

A prospect (further to be called 'client' because it's easier) reached out to me after they kept experiencing a high volume of bounces to emails they KNEW were active (one was their sister's email.) They also were receiving feedback via customer complaints that their messages were not being received.

Side note: If customers are complaining they DON'T receive the mail, take note! You're doing something right for them. It also means something is up so go check on it.

I asked them to send me some bounce messages because it ain't easy to diagnose why an email is getting rejected without them.

They first sent me this one: 

550 Verification failed for bounces+34048707-4a68-somedomain.com@clientsubdomain.com The mail server does not recognize bounces+34048707-4a68-somdomain.com@clientsubdomain.com as a valid sender. Sender verify failed

And because 'weird' things abound in email, I asked if all bounces were like this or if this is just one they grabbed. To which, I got a much more meaty response, "Yes the majority are." and sample set.

This has to be DNS!

Super quick DNS checks via Google DIG all came back clear. Let's dig further.

On the phone we get because back and forth with email on a technical issue just gets tedious and difficult for everyone.

While we were talking, we were able to dig further and narrow it down to Microsoft domains having the majority of the issue. Somewhere in my brain got me thinking about Cloudflare and connecting the two. I can't remember the origin of when those dots were connected, but I connected them in my head, for better or for worse. For today's story: For better. (Yippee! And now you know this story will have a happy ending.)

Time to summarize what I knew:

1. Domain/Sender existed for most of the mail, but not all.
2. DNS query from Google DIG showed the right DNS entries needed for email
3. There was an abundance of Microsoft hosted domains having this problem.

Again, this told me that there was something afoul with the DNS; but where? Oh the suspense!

I started by looking at sites like https://www.whatsmydns.net/ to see if there were any nameservers having issues with the basic DNS entries needed for email, because "DNS, It's Damn Hard".

Cloudflare kept coming back with inconsistent results, meaning sometimes I would get DNS results and sometimes I wouldn't. The other nameservers were consistently consistent. Granted my testing wasn't over days or used a lot of different resources so there could have been issues elsewhere, but based on everything together with the bounces from Microsoft and Cloudflare giving spotty results, I knew Cloudflare was definitely off.

But why?

Oh! Quick Intermission: Here's some background that might be helpful if you are trying to sleuth out the problem before I reveal it. This client was using ConvertKit. Migrated away, didn't like what they saw, went back to ConvertKit.

Ok, back to the story. I went to MX Toolbox to do some domain lookups. I don't remember what page I went to or what I clicked. I tried to recreate it, but I can't find the same starting page! (DAMN YOU PRODUCT UPDATES that are supposed to make life easier! At least I'm blaming you for now even if it's my memory that's busted.)

Anywho, when the results came back, MXToolbox pointed out a discrepancy in the results. 

Do you see it? If you aren't careful you might miss it. It's like that game in the Highlights magazine to "spot the differences." Although my favorite was always "Hidden Pictures."

I digress.

Not all nameserver (NS) records were returning the same value for the CNAME record of their subdomain. Two of the three nameservers had the CNAME from their new account (when they came back to ConvertKit) and one had their OLD CNAME before they departed (again, only to later return.)

PSST, because I can't remember how to recreate my steps to get the above result, although I think MX Toolbox just did it for me when I pulled the CNAME record, you can use Wombatmail's DNS Tools (formerly XNND) to check DNS records across all the nameservers. Simply use the 'Special' option in the Multi-DNS dropdown.

Cloudflare was loving up on that second server there (don't ask me why, I don't know and at the time I didn't attempt to find out.) So when Microsoft (and others) used Cloudflare to do DNS lookups, they were seeing the old CNAME. Because the client had departed, the DNS records tied to the original account and that first CNAME were cleared out so the end result was ... NADA. No minimum required DNS records (resource records.) Therefore, the domain could not be "found " and unable to be verified.

Happy as a bee that I have uncovered their issue. I went buzzing back with quick instructions to "presto chango" (perhaps I should say update or repush the changes) the DNS and they should be good. 

Although they were happy to find an answer, they were not happy that they had to go and re-activate all the addresses that hard bounced out of the system. Not a fun endeavor, but at least there was light at the end of the tunnel and a path forward to success!

DAMN NAMESERVERS!

(Although, thank you for the business and the story!)