During the setup of services for Microsoft 365, Microsoft asked us to configure several DNS records for our domains, so I thought it might be useful to provide a little background information about what they’re for, plus some tricks and tips.
For most people DNS (the Domain Name Service) is a hidden background service but, without exaggeration, it’s invention in 1983 into the then mysterious word of inter-networking, was one of the most important steps in creating a scalable, global network as it allowed people to refer to relatively abstract IP addresses using a recognisable and orderly naming system. To put its novelty into context, it wasn’t for another 10 years; in 1993, that Microsoft released an update to enable Windows (then version 3.11) to connect to IP networks at all – and use DNS.
DNS has stood the test of time and is very much at the core of the contemporary cloud systems we use today.
So, what does it do in Microsoft 365?
IN THE BEGINNING THERE IS A TENANT
When you first sign up to create an account in Microsoft 365, you will be asked to choose a name for your new tenant. Once you’ve chosen something unique, this name will stay with you through the life of your tenant – so choose wisely. This tenant name will show up in all sorts of places throughout Microsoft 365 and Azure AD and it will form part of the DNS names you use to access SharePoint and several other Microsoft 365 services.
The other good news is that Microsoft will take care of all the configuration and DNS requirements for your Tenant domain name automatically so, if you’re only going to use your tenant name, you can stop reading now…
AUTHORISATION
Once you have your tenant, one of the first things you’re likely to want to do is configure your very own domain name. The simplest solution here is to let Microsoft manage it for you but where’s the fun in that!?
Assuming you’ve registered your domain name and you’re managing the DNS yourself, there are different types of DNS records you’re going to come across. The first entry you’ll be asked to make in DNS is to show that you own the domain. Microsoft will ask you to create a custom TXT or MX record to demonstrate that you have control of the DNS for the domain name and you’re authorized to use it.
Once authorized, you can start to enable services against your domain but the order you do them in will depend on how you’re going to migrate or enable services. So in no particular order, here are some common services you’ll be working through:
AUTODISCOVER
Typically, Autodiscover uses a CNAME record called, unsurprisingly: “autodiscover”, to find the Exchange services configured with your domain name. In some cases, a CNAME record is too blunt to accommodate the various certificates and naming in use in your environment – most often your Hybrid environment. In these cases, an SRV record can provide the direction needed to make sure everyone can find their way. The important trick here is that with the help of an SRV record, Autodiscover can use any hostname with a valid certificate to find its way to your Exchange environment. You don’t have to have a certificate which matches the name “autodiscover.yourdomain.whatever” exactly.
Under the surface though, Autodiscover is about much more than allowing Outlook and mobile apps to find their way to Exchange; Exchange also requires Autodiscover in order to handle Free/Busy information, manage calendar availability and several other essential Hybrid features.
The lesson here: don’t be scared of the SRV – it can save your bacon.
OUTBOUND EMAIL
The next service you’re likely to experience which relies on DNS is outbound email. Microsoft 365 will take care of the normal email routing using DNS (or custom connectors if you set them up) but email security is rapidly evolving to try to protect our – generally very insecure – messages and DNS plays a key part in this process too.
Who do you think you are SPF?
The SPF (or Sender Protection Framework) allows you to publish a trusted list of sources from which your domain might send email. If you’re only using Microsoft 365 then include:spf.protection.outlook.com is all you need, but if any other services – such as other SaaS platforms, marketing emailers or an on-premises database – will ever send messages from an address @yourdomain.whatever, then you should include a reference to these services in your SPF. It is your “authorised senders” list. Without it, your email will often look like spam to those who receive email from you – or, just as bad, Microsoft will think that your CRM system is trying to spoof your domain and you’ll miss a vital sales or support email.
SPF is published as a TXT record in DNS taking the form:
v=spf1 include:spf.protection.outlook.com -all
Long live the DKIM
DKIM (DomainKeys Identified Mail) is the next in line to the email security throne. By publishing DKIM selector records you can prevent others sending messages which look like they come from your domain. DKIM enables emails sent by Microsoft 365 to be signed using a cryptographic signature, by the sending system and for the receiving system to be able to confirm that it is legitimate.
DKIM keys are published in the form of CNAME (selector) records which tell your recipients where to validate your DKIM signatures. The selector names are the same for all your domains but the hostnames they point to are different for each domain – which can be a little tricky. So here are a few tips:
- Don’t worry about DKIM, just do it
- The selector names are the same for all domains:
selector1._domainkey
selector2._domainkey
- Unhelpfully, Microsoft don’t provide the addresses in the portal in any easy form, but you can get all your DKIM selector addresses with one PowerShell command:
Get-AcceptedDomain | Get-DkimSigningConfig | FL *CNAME
This will give you both host records you need for each of your domains.
- So now you can create the CNAME records you need. Create one for each selector with the names #2 and the address from #3
Host name: selector1._domainkey
Points to address or value: selector1-<domainGUID>._domainkey.<initialDomain>
TTL: 3600
Host name: selector2._domainkey
Points to address or value: selector2-<domainGUID>._domainkey.<initialDomain>
TTL: 3600
- Once the two records are created in DNS zone, the final step is to enable them in Microsoft 365. You can do this either in the Exchange Management Console, or in PowerShell:
Set-DkimSigningConfig -Identity <domain> -Enabled $true
And that’s it. Once you have SPF and DKIM records set, Microsoft will also automatically use these to check incoming email using DMARC.
For more information on SPF, DKIM and DMARC, see here: https://docs.microsoft.com/en-us/microsoft-365/security/office-365-security/email-validation-and-authentication?view=o365-worldwide
INBOUND EMAIL
Once you have set up your outbound email, the time will come to commit yourself to routing your inbound email directly into Microsoft 365. All Microsoft 365 plans include Exchange Online Protection features to some degree, and some plans also include Advanced Threat Protection but I’m not going to talk about configuring those today – suffice to say: do that first.
Next, it’s time to do some testing: the last thing you want is to flip the switch and find your email doesn’t get delivered.
So, first: find the host name record which Microsoft wants you to use for your domain. The simplest way is to use the Microsoft 365 Admin Console -> Setup -> Domains but if you prefer, you can use Azure AD PowerShell too:
Get-AzureADDomain | % {(Get-AzureADDomainServiceConfigurationRecord -Name $_.Name | where RecordType -eq MX).MailExchange}
Next, test it. Don’t take it for granted that Microsoft has set it up properly – it takes 2 seconds to check, so check.
To test SMTP, either use Telnet or an SMTP testing tool on the web (such as Wormly here: https://www.wormly.com/test_smtp_server). Use the hostname which Microsoft has given you to send a message directly into Office 365 (bypassing the existing MX record). Then, when you receive the email, check the headers using Mirosoft’s Meassage Header Analyser: https://mha.azurewebsites.net/pages/mha.html. You can use this to check that the message has been processed and spam-checked appropriately before being delivered to your mailbox.
And now we’re ready.
HELLO
Microsoft 365 uses only one MX record so you can put the Microsoft provided hostname into your DNS as your new MX record with priority 0. Microsoft recommends a TTL of 3600 seconds (1 hour) but you might prefer to enter a shorted TTL (e.g. 60 secs or 300 secs) just in case you need to revert quickly for any reason. Remember, when you’re putting the MX record in place to put a final . (dot) after the hostname if your DNS service needs it; otherwise your messages won’t go anywhere useful. You can also leave your existing MX records in place for the time being while you test the mail flow. Your DNS will take a while (depending on the zone TTL) to update across the wider Internet but once the new MX record is picked up, your mail should start to be delivered direct to Microsoft 365. Again, check using the MHA tool (above) to confirm that the mail has been routed directly into Exchange Online Protection, and keep an eye on your quarantine and message tracking to make sure your messages are being delivered appropriately.
SKYPE FOR BUSINESS & TEAMS
The DNS configuration for SfB and Teams is the same for all domains – and that’s the good news. However, the bad news is that, compared to what we’ve done so far, it’s a little more complex.
As you can imagine, DNS is used extensively in SfB and Teams, so we need to give it a hand to find its way around. We need 4 different records in place to tie all together:
- CNAME: lyncdiscover – helps clients to connect, much like Autodiscover for Exchange above
- CNAME: sip – used by mobile clients to make and receive audio calls
- SRV: sip – used for external user access
- SRV: sipfederationtls – used to allow external parties to discover your federations to other potential partners
With these four DNS records set for your domain, Skype for Business and Teams users can connect to the service using web, desktop and mobile apps and allowed external partners can connect with your users for instant messaging and calls.
DEVICE MANAGEMENT
Our final stop on this magical mystery tour is device management. Nice and easy this time. Just two CNAME records to add and they’re always the same. These two records (called enterpriseregistration and enterpriseenrollment) enabled Microsoft 365 device management services to discover and enrol your users’ devices using their login credentials. They should be setup for any domain which is used as a UPN or email address in Office 365. No magic here thankfully.
So, in conclusion – a few relatively simple DNS entries enable an enormous amount of functionality under the hood in Microsoft 365. New features may come along in Microsoft 365 demanding further DNS configuration but, as it stands, Microsoft has done a reasonably good job of keeping it simple and stable for us all.
