The DNS Oversight

With the Yahoo-Gmail requirements rolling out, I’m getting a lot more requests to help senders get setup and prepared for the new normal. And although there are MANY ”Yahoogle” webinars, many more questions still remain.

The sheer volume of questions, even if they are repetitive, and blog posts, webinars, and Q&As shows that interest is piqued. This isn’t a buzzworthy topic that will create interest and keep the status quo. This is a buzzworthy topic that will create interest and break the status quo. It’s amazing to see the movement toward compliance, despite the fact that there are still a large number of unaware senders and send systems that aren’t up-to-date.

As with Apple’s ground-shaking introduction of mail privacy protection (MPP), big-tech is yet again moving the industry forward into a safer and more privacy-first environment.

And although I can go on about this topic, this article isn’t about that. But with all the attention on making sure we meet the requirements, attention to detail can get lost. Things like how https should be used with list-unsubscribe and the list-unsubscribes headers also have to be DKIM signed.

But those are implementation details that can be overlooked. There’s also “that’s not how it works” details.

The DNS may seem like a simple thing. Input values and your website works, email is authenticated, easy peasy. But the DNS is not so simple, or easy. It’s often the butt of jokes for those in deliverability and likely in IT; heck it’s even a haiku…

DNS is easy to mess up. Helping clients troubleshoot why DMARC still isn’t working uncovers simple things that can throw results for a loop: two DMARC records when the spec only calls for one, quotes when their DNS MUA doesn’t accept them.

We may find, as we rush to meet these new requirements, that we are rushing to update a system a lot of senders know nothing about and changing it in a way that may break the very things meant to help them.

Besides the technical know-how behind DNS, a lot of small senders are being introduced to the concept of buying a domain. They are being forced into this world of deliverability on a whole new level and the world of DNS.

This is especially true for those that use their personal webmail emails (think gmail.com) to send to their customer base from ESPs. The webmail email service providers are beginning to shut down the use of the email as a sender address unless the mail is coming directly from their system (meaning I can’t send from Mailchimp as email@gmail.com). So now these senders are faced with an alternative: use a shared domain, which may not be offered forever or may bring unexpected reputation fluctuations, or set up a new domain.

And once they get that new domain, they can’t (or shouldn’t) use it right away, a concept not all seasoned markers know, let alone newcomers. Not only does that domain have to be “seasoned” with time, but it needs the right DNS entries. It also needs to be connected to the right mail systems. It needs to make sure it isn’t too permissive and that the records remain up-to-date.

How many users today keep track of when they added a DNS entry and why? I would venture a guess and say, “not many.” So assuming ‘new-to-the-domain-world senders are not thinking ahead about documenting all of the DNS adjustments and why they are there’ is not a far reach.

In five years, the employee that set it up probably won’t be the same as the one that has to update it for a new vendor, subdomain, etc. The DNS entries grow and the history of why disappears. The fear of deleting something that is still needed overrules the desire to keep a tidy and limited-permissioned DNS.

Does the overabundance of DNS entries harm deliverability? No, but the lack of data entry accountability can open up gaps in security that most senders new to the domain world are likely not educated on. Records that were intended to be used with one platform remain in place even after that platform is no longer used. And when DNS entries still exist granting “permission” despite a service no longer in use, it means someone else can exploit that permission the DNS may be providing and cause harm in many other ways.

Consider this. I set up an SPF record that points to sendgrid.net, a common MTA provider for many services. A lot of the Sendgrid SPF records I’ve seen point to one include: sendgrid.net. Doesn’t seem too bad…until you move on to a new service and look back and see that the SPF for sendgrid.net still exists and it is still granting permission to all of sendgrid.net’s IPs. The sheer volume of IPs being permitted… It’s over 200 THOUSAND IPs!

I would venture to say that is one reason why the new guidelines that started this conversation are saying large senders need to have both SPF AND DKIM.

So, if you’re groaning about yet another webinar, it’s ok, but let’s keep the webinars and redundant Q&As and blog posts going anyway. There will always be someone new to the topic.

If you are an educator of these topics, bring in more than marketing best practices and deliverability best practices. Add in DNS and domain basics for the marketer. Bring in the service providers and hosting companies into the fold. If someone is going to buy a domain from a site that hosts small business web pages, like Squarespace, add in that extra education around the DNS. Combine that with how the domain and DNS should be applied in the mailing platform and you start to build a more informed sender, even if there are still a bunch of gaps, let’s at least close some.

Photo by Nick Page on Unsplash