Blog Archive » O365 – DNS for “Dummies”

O365 – DNS for “Dummies”

One of the big things that seems to trip up a lot of people when they attempt to move to Office 365 are the DNS requirements that Microsoft expects you to have in place.  If you are not used to messing about with DNS the requirements can look a bit daunting.  And if your present DNS provider doesn’t support the record types that Microsoft uses and/or does not make life easy for you to make the changes then the move to O365 can be pretty frustrating.

So, to make your life a bit easier, here is Rob’s O365 DNS primer (for those of you that already “get it” you should move along as there is nothing new here):

First, just what the heck IS a DNS record?  Well, I’m glad you asked because there is nothing really mystical about it.  In simple terms, a DNS record maps things like website names or server connections (think www.itgroove.net or mail.itgroove.net) to an IP address.  DNS records are what allow systems and people to find specific resources on the Internet.  You look up a name and you get the address in a similar fashion to looking up a name in a phone book or in the Yellow Pages and getting a phone number in return.  Of course there are some complicated variants but the basic premise remains the same … look up something and get specific information back.

There are m any types of DNS records and each type does something specific.  O365 expects you to be able to set the following types:

  • A record:  this is a simple pointer, a name to IP reference.  Something like remote.company.com points to 111.222.333.444 (or something similar)
  • CNAME:  this is an alias or a re-direct that maps one name to another; whatever you map TO must already exist and resolve correctly.  O365 will give you some CNAME records to set up like autodiscover.yourdomain.com which has to point to something like autodiscover.outlook.com
  • MX record: this is the “biggie” as it tells all of the email servers in the world how to find your email server (which will now be O365).  If you are migrating to O365 from another email system there is probably already an MX record in place that points at your old email server.  You have to update the record and once it propagates throughout the Internet other email servers will know to connect to O365 to send email to you.
  • TXT record:  this is kind of a “generic” entry that allows you to enter a lot of text.  It is for information or instructions.  Microsoft uses a TXT record to record SPF information for your domain (Sender Policy Framework) which helps other email servers confirm your email server’s identity (it is a valid email server for your domain) as well as valid IP addresses for your email server. Many email servers will NOT accept email form or send email to email severs that don’t have corresponding SPF records so this one is pretty critical.   Note:  many DNS systems allow you to actually create and publish an SPF record directly but Microsoft chooses to use the TXT record type for this info.
  • SRV record:  this is a very specialized record that Microsoft uses to identify the SIP service records needed to support Lync services in O365.  Chances are it is this record type that will give you the most grief if your DNS provider’s system is older or clunky.

    • Microsoft lists DNS providers that work well with O365 and they also suggest, strongly, that if you have issues setting up the required records that you change DNS providers to one that is more “friendly”.  I concur wholeheartedly.  See my post here about painful issues with a dumb DNS provider that were resolved in about 10 minutes by changing to a DNS provider with decent tools and a modern backend.  There is no reason whatsoever for your move to O365 to be blocked by DNS issues.  If your provider can’t do the job, dump them.  The Internet (and DNS) is ruthlessly Darwinian – the dumb provider will either “get it” or die. 

    Keep in mind when setting up DNS records that if your provider allows you to control the “lifetime” or the “time to live” that shorter times are better than longer.  If you mess something up you want it to die off quickly so that your fixed updates take effect sooner.  Also keep in mind that it can take time for your DNS updates to propagate across the web.  If you are able to control where you QUERY external DNS (lookup) then I suggest you point at Google’s DNS servers – 8.8.8.8 and 8.8.4.4 – because they update incredibly fast.  I’ve seen Google catch DNS changes made at a DNS provider inside of 30 seconds from the point the DNS provider accepted the DNS change.  It’s a great way to see if your changes are what you want.  Also, the DNS test inside O365 will pick up the changes fairly quickly and once you get past the DNS test you are away to the races in terms of your O365 tenancy.

    I hope this helps clarify O365’s DNS requirements a little bit.