Module 7 · 7.1

English

Nederlands English Deutsch Français Dansk Español Svenska Italiano Português Română Hrvatski Norsk

Connecting Microsoft 365

Module 7: Connecting external services · Reading time: 9 minutes

Learning objective: After this lesson, you'll be able to set up the DNS records for Microsoft 365 and check that they're correct.

Key concepts: verification TXT (MS=ms...), MX to Microsoft, SPF include, DKIM CNAME (selector1 and selector2), autodiscover, admin centre

Why Microsoft 365 needs records

With Microsoft 365, your email arrives at Microsoft. Your website can simply stay with your own web host. For this split, Microsoft needs a few things from your DNS:

proof that the domain is yours (verification);
the place where mail arrives (MX);
permission to send mail on behalf of your domain (SPF);
a signature under your mail (DKIM);
a record that lets Outlook find the settings itself (autodiscover).

You add these records with the party that manages your domain's DNS. Not sure who that is? Check your domain's nameservers (lesson 2.1). If you make changes anywhere else, nothing will happen.

The most important rule in this lesson: always copy exactly what the Microsoft admin centre shows for your domain. The examples below show what the records look like. The exact values differ per domain and subscription, and Microsoft sometimes changes the format.

Step 1: verifying the domain

When you add a domain in the Microsoft 365 admin centre, you get a TXT record with a code:

example.com.   3600   IN   TXT   "MS=ms12345678"

Add this record to the bare domain (@). Then click verify in the admin centre. If it doesn't work straight away, wait a quarter of an hour and try again: sometimes a resolver still has the old answer cached (lesson 6.1). This TXT record can sit alongside other TXT records, including your SPF record (lesson 4.2).

Step 2: the MX to Microsoft

The MX record points to a mail server linked to your domain. For a long time, this was the domain name with hyphens instead of dots, followed by mail.protection.outlook.com:

example.com.   3600   IN   MX   0 example-com.mail.protection.outlook.com.

Newer subscriptions sometimes get an address ending in mx.microsoft, for example something like example-com.x-v1.mx.microsoft. That's not a typo: .microsoft is a genuine top-level domain. You can see which of the two you get in the admin centre. Copy it exactly, including the trailing dot if your panel asks for it (lesson 2.2).

Two things often go wrong here:

Leaving old MX records in place. Remove the MX records pointing to your previous mail server. If you leave them, some of your mail may still arrive at the old location, even with a higher priority (lesson 4.1).
Local delivery at your web host. Many hosting panels deliver mail from your own website (contact form, webshop) straight to a mailbox on the same server, if it thinks your mail lives there. In DirectAdmin, this setting is called "Use this server to handle my emails". If you point the MX to Microsoft, turn off this local delivery. Otherwise, form submissions will never reach Microsoft. In other panels, this is sometimes called "Remote mail exchanger" or "Disable local mail".

Step 3: adding to SPF, not duplicating it

Microsoft wants this in your SPF record:

include:spf.protection.outlook.com

Already have an SPF record? Then don't create a second one; instead, add the include to your existing record. Two SPF records make your SPF invalid (lesson 4.3). If your website sends mail via your web host's server, keep that in the record too:

example.com.   3600   IN   TXT   "v=spf1 a mx include:spf.hosting.example include:spf.protection.outlook.com ~all"

Watch the limit of ten DNS lookups: every include counts, and Microsoft's own includes add further lookups of their own.

Step 4: DKIM with two CNAME records

Microsoft signs your mail with a key that it holds itself. You only create two references, as CNAME records:

selector1._domainkey.example.com.   3600   IN   CNAME   selector1-example-com._domainkey.example.x-v1.dkim.mail.microsoft.
selector2._domainkey.example.com.   3600   IN   CNAME   selector2-example-com._domainkey.example.x-v1.dkim.mail.microsoft.

Since May 2025, new domains get this format, ending in dkim.mail.microsoft. The letter before -v1 (here x) differs per subscription. Older domains often still have the format ending in onmicrosoft.com, for example selector1-example-com._domainkey.example.onmicrosoft.com. Both work. Here too: copy the values from the admin centre (under DKIM settings in the Defender portal) rather than making them up yourself.

Why two? Microsoft rotates the keys from time to time (key rotation). If only selector1 is in your DNS, DKIM works until the first rotation and then suddenly stops. So always create both.

Once the CNAME records are visible, turn on DKIM in the admin centre. A common mistake is creating a TXT record where a CNAME is required; Microsoft will then report that the CNAME is missing.

Watch the name: in your panel, you usually only enter selector1._domainkey. If you type the full name and your panel also appends your domain, you'll end up with selector1._domainkey.example.com.example.com (lesson 8.4).

Step 5: autodiscover

When setting up an account, Outlook looks for autodiscover.<your domain>. Point that name to Microsoft:

autodiscover.example.com.   3600   IN   CNAME   autodiscover.outlook.com.

Is there already an A record or a wildcard sending autodiscover to your web server? A CNAME can't sit alongside another record with the same name: remove the A record for autodiscover first. You don't need to do anything about a wildcard (*): a name that's set separately takes priority (lesson 3.3).

And DMARC?

Microsoft doesn't ask for it during setup, but without DMARC, mail is more likely to end up in spam. If you already have a DMARC record, it can stay. Just make sure SPF and DKIM for Microsoft are working correctly before you set the policy to quarantine or reject (lesson 4.5).

In practice: what it looks like in a panel

In the example panel My WebOké, the DNS tab of a domain has an Email settings card with Quick setup. If you choose Microsoft 365 there, you'll see in advance which records will be added: MX, SPF addition and autodiscover, and local delivery is switched off. You get the verification TXT and the DKIM CNAMEs from Microsoft itself; you add these separately using Add Record. In DirectAdmin, you do the same thing via MX Records (the Microsoft 365 template, with the tick for delivery switched off) and DNS Administration.

Using a different panel, such as cPanel, Plesk, Cloudflare or your registrar's DNS screen? The buttons there have different names, but the fields are the same: name, type, value and TTL. Some registrars also have a "Microsoft 365" button that sets all the records in one go.

Summary

Copy all values from the Microsoft 365 admin centre, not from an example.
Verification: TXT MS=ms... on @. MX: the address Microsoft gives for your domain; remove old MX records.
SPF: add include:spf.protection.outlook.com to your existing record, don't create a second one.
DKIM: two CNAMEs, selector1 and selector2, both needed because of key rotation.
Autodiscover: CNAME to autodiscover.outlook.com, and switch off local delivery at your web host.

Quiz

Exercise

Exercise Z7.1: Recognising Microsoft 365. Look at how two real organisations use Microsoft 365: microsoft.com and sidn.nl (the website of SIDN, the registry of .nl in the Netherlands).

Look up the MX record of sidn.nl and of microsoft.com. Which of the two uses the old format (mail.protection.outlook.com) and which uses the new one (mx.microsoft)?
Find the Microsoft include in the SPF record of sidn.nl and copy it out.
Look up the CNAME record of selector1._domainkey.sidn.nl. What word does the target name end in (the last two labels)?

Enter your answers in the input field. The check looks up the records live at the moment you submit, so if the organisation changes something, the new answer counts.

Exercise O7.1: Setting it up yourself in your practice zone. Connect your practice zone <code>.dnspractice.eu to a simulated Microsoft 365. In the practice zone, you use the fake service office-demo.dnspractice.eu; for your real domain, you copy the values from the Microsoft 365 admin centre.

Verification: add a TXT record to <code>.dnspractice.eu with the code the exercise page gives you (MS=oefen-<code>-<...>).
MX: have <code>.dnspractice.eu receive mail at mail.protection.office-demo.dnspractice.eu. with priority 0. Remove any other MX records on <code>.dnspractice.eu.
SPF: add include:_spf.office-demo.dnspractice.eu to the existing SPF record on <code>.dnspractice.eu, keeping mx in place. There can only be one SPF record.
DKIM: create a CNAME selector1._domainkey.<code>.dnspractice.eu pointing to selector1.dkim.office-demo.dnspractice.eu. and a CNAME selector2._domainkey.<code>.dnspractice.eu pointing to selector2.dkim.office-demo.dnspractice.eu.
Autodiscover: create a CNAME autodiscover.<code>.dnspractice.eu pointing to autodiscover.office-demo.dnspractice.eu.

Exercise O7.1

You'll do this exercise in your own practice zone: a real DNS zone on WebOké's nameservers, just for you. Sign up with your email address. You'll get a login link by email and then come back to this lesson. We only use your address for the course.

Cookies at WebOké

Cookie settings

Necessary

Marketing