As someone who reads through hundreds of support cases each month, nothing pains me more than seeing customers struggling with seemingly complex issues, only to discover that the root cause is quite simple. Never is this truer than it is with DNS. Some of the most complicated security and lost mail issues boil down to a few simple records. In fact, we get well over a thousand tickets per month that could be easily avoided by addressing DNS issues. This blog post could save you time, frustration, even money! Please note that I’m focusing on Office 365 email DNS records here, especially those involved in routing & security decisions – but this advice may be applicable more broadly.
Best Practices List
Don’t use legacy DNS records anymore
For several years, we have been doing campaigns to let you know that we’re not going to forever support the use of records like mail.outlook.com, mail.messaging.microsoft.com, mail.global.frontbridge.com, mail.global.bigfish.com, etc. in your MX (mail exchanger) record. However, as of the time of this publishing, we still see over 2000 customer domains that still point to one of these. And that’s just the ones we can easily check in public DNS. There are easily an equal number of on-premises or cloud applications/firewalls/devices which still also appear to be using these records.
Why? Not updating and removing these records means that you’re not getting all the benefits available to you (some of our EOP features simply don’t work). This also increases your risk considerably, as we don’t constantly monitor to make sure all of these records still work like we do with the newer, supported records.
Remove all stale DNS records
It is critical that once you commit to using Office 365, you don’t keep one record pointing to your older routing path. Two variants of this pop up all the time:
- You move your mail to Office 365, but leave the old MX record (priority irrelevant). This is a terrible idea, because it means that any network glitch anywhere, even on the sending side, can send your mail into a black hole, never to return. Your old provider probably still accepts email for your domain (might not be a bad idea to tell them to stop). Why? This causes mail to go missing. If the other host chooses to reject the mail, senders will get bounce messages (NDRs) from time to time. What’s annoying is that these issues can be very intermittent, or so rare that you may barely notice them and if you do – it can be very difficult to track down.
- You move your entire domain to a new DNS provider, but forget to remove the zone at the old provider. I see this one with even the most experienced administrators. Why? In short, intermittent missing mails. Most Internet traffic will get the proper, new records because they’ll be using the SOA (start of authority) and NS (name server) records to determine where to resolve the records for your domain. But any customer who is using your old provider for their DNS will still get the old, orphaned information. This is called a DNS split, as multiple servers think they are the authority. More experienced providers will eventually expire the zone files, but some smaller providers might not have a procedure for deleting zones when customers stop paying the bills. And issues with a smaller provider might take weeks, or years to notice. Note that while domain registrars (the ones who list your domain with root servers) usually provide DNS zone hosting, the registrar may not be where the DNS zone (and actual DNS records) is hosted.
Don’t use multiple MX records, especially if they don’t point to the same provider
Aren’t multiple MX records more reliable? In some cases, yes; but most certainly not in this case. Office 365 assigns you a single record per domain, and if that domain is registered with us, we will accept mail for you. It is covered by our money-backed guarantee. We constantly monitor, and we have engineered multiple layers of redundancy already: at the A (host) record level, at the IP level, and more. At the IP level alone, there are thousands of severs sitting behind just a single virtual IP.
Why? More MX records – whether pointing to a 3rd party scanning service, on-premises, or even a “continuity” provider means more complexity and possible message delays because your mail is taking an extra hop, which is not covered in any of our guarantees. It also means that when mail fails over to another route, unexpected things can happen with junk filtering and spoof detection. For example, a good bit of our EOP filtering stack does not trigger when we detect this configuration. This leaves you open to phishing attacks and more. It also makes it a pain to troubleshoot, because you’ll occasionally be troubleshooting messages that didn’t even pass through in the order you’d expect. SPF most likely will fail for those messages which take an extra hop, and that could trigger false positives. This is so important that I’ll say it one more time – EOP is NOT as effective if you have multiple MX records or mail doesn’t route to EOP first. It’s the first thing I ask support engineers to check when troubleshooting missed junk or false positives. I see countless issues where people are complaining about the effectiveness of EOP, only to discover that all MX records did not point to EOP.
Now, if you have opted not to use EOP and rely on a third party or on-premises filtering infrastructure instead, that is fine, but only use the records appropriate for that single configuration. Don’t mix and match a few of theirs with a few of ours, at least for a single domain.
As for other DNS records, it ultimately depends on how the client behaves – but if you’re not sure, don’t assume that more DNS records are always better.
Use only the MX records provided to your specific tenant
Sometimes, you’ll setup a domain inside of a test Office 365 tenant, and then move it to a production tenant. Sometimes, a company merges or divests, and you must move a domain to a new tenant. You absolutely must update DNS records when doing so. You cannot assume that we’ll let you keep using the old DNS records indefinitely, just because they work for a little while. I saw a case recently where a reseller was using a single DNS record for every tenant they were responsible for. Not only does this increase risk, but it is not supported, and mail will eventually break.
While it is technically true that you could use a single assigned A (host) record for every domain in your tenant, this is not advised, because it also increases risks. What if that domain expires or moves to another tenant, while the others stay where they are?
Don’t let your domain expire
It is sage advice to know when your DNS records are set to expire. Set yourself a reminder a few months in advance, just as you might do with certificates or anything else. Set yourself another reminder for a few days before. Even if you have it set to auto-renew, payment issues happen all the time. Don’t rely exclusively on email notifications.
Check your records occasionally
I know there’s a (mostly true) saying that goes something like, “if it isn’t broken, don’t fix it.” But that doesn’t mean you shouldn’t know what your DNS records are and know that they are setup correctly. Just because something appears to work fine, doesn’t mean that it is setup correctly. I would strongly advise doing a complete and exhaustive check of DNS at least once per year. There are tools all over the Internet to help you. Yes, when you identify that a change needs to happen, proceed with caution. But put together a plan now to get it fixed during the next possible window.
Where do I go to check all of this?
If you login with an Office 365 Admin account, the Domains page under Setup has everything you need for each domain you’ve registered with us. If you’ve purchased the domain through Microsoft and let us manage it for you, there should be nothing more required. If the domain is one that you manage yourself, the experience looks something like this (if GoDaddy is your registrar and DNS provider, we’ll actually walk you through the setup):
From this page, you can click into each domain to see what the value should be, for example:
Then, you can use nslookup to validate what the world sees. As an example:
> server 22.214.171.124
Default Server: b.resolvers.Level3.net
> set q=mx
contoso.com MX preference = 10, mail exchanger = mail.global.frontbridge.com
> set q=txt
contoso.com text =
As you can see from this example, contoso.com does NOT have the proper MX record, and they have no SPF record. Alternately, you can use any number of 3rd party DNS checking tools available on the web.
While you’re at it, check all your Office 365 DNS records as well. And odds are, if you’re still using those old records, you might not have setup DKIM and DMARC. Take this opportunity and stop procrastinating – your brand, your users’ safety, even the financial future of your company could depend on it. For more information, see the Office 365 Domains FAQ.
I hope you find these best practices helpful, and if you’re stuck, our support is able to assist you with any of this.