Best practices for using assigned

Office 365 DNS records

★★★★★
★★★★
★★★
★★
★
The Exchange TeamMay 29, 20182

 197
 0

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:
C:\>nslookup
> server 4.2.2.2
Default Server:  b.resolvers.Level3.net
Address:  4.2.2.2
> set q=mx
> contoso.com
Server:  b.resolvers.Level3.net
Address:  4.2.2.2
contoso.com     MX preference = 10, mail exchanger = mail.global.frontbridge.com
> set q=txt
> contoso.com
Server:  b.resolvers.Level3.net
Address:  4.2.2.2
contoso.com     text =
"MS=ms47806392"
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.