Microsoft 365 DNS setup: MX, SPF, DKIM, autodiscover and DMARC

Steps

1. Add and verify the domain. In the Microsoft 365 admin center add the domain and publish the verification TXT record it shows (it starts with MS=).
2. Create mailboxes and assign licences. Every address that should receive mail needs a mailbox, shared mailbox, group or alias before MX is moved.
3. Publish the MX record. Copy the MX host from the admin center. It is derived from your domain name and ends in mail.protection.outlook.com, or in mx.microsoft for domains with DNSSEC-protected inbound mail. Priority 0, and no other MX records.
4. Publish SPF. Add one TXT record at the apex: v=spf1 include:spf.protection.outlook.com -all. Add other senders to the same record.
5. Turn on DKIM. Publish the two CNAME records selector1._domainkey and selector2._domainkey with the targets the Defender portal shows for your domain, wait until they resolve, then enable signing for the domain.
6. Add autodiscover, DMARC and check. Publish the autodiscover CNAME so Outlook finds the mailbox, add a DMARC record with p=none, then run the checks on this page.

DMARC

DMARC is the same for every provider: one TXT record at _dmarc.example.com. Start with p=none and a reporting address, so you receive reports without affecting delivery.

Read the reports for a few weeks. When every legitimate sender passes SPF or DKIM with an aligned domain, move to p=quarantine and then p=reject. Moving to reject before DKIM is on for all senders is the usual way legitimate mail gets lost.

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

Optional: MTA-STS, TLS-RPT and BIMI

MTA-STS tells sending servers to require TLS when delivering to you. It needs a TXT record and a policy file served over HTTPS at mta-sts.example.com; the policy must list the MX hosts of your provider exactly.

TLS-RPT asks senders to report TLS delivery failures to an address you choose. One TXT record, no effect on delivery.

BIMI lets some mailbox providers show your logo. It requires DMARC at quarantine or reject, and most providers also require a verified mark certificate.

_mta-sts.example.com.  3600  IN  TXT  "v=STSv1; id=20260921T000000"
_smtp._tls.example.com.  3600  IN  TXT  "v=TLSRPTv1; rua=mailto:tls-reports@example.com"
default._bimi.example.com.  3600  IN  TXT  "v=BIMI1; l=https://example.com/logo.svg"

Mail clients: autodiscover and autoconfig

Outlook locates the mailbox through the CNAME record autodiscover.example.com → autodiscover.outlook.com. Without it, desktop Outlook may ask for server settings or connect to an old on-premises server that still answers under that name.

TTL advice

Before changing MX records on a domain that already receives mail, lower their TTL to 300 seconds and wait for the old TTL to run out. Resolvers then pick up the new records within minutes.

When the new setup has worked for a few days, raise the TTL again: 3600 seconds is a common value. SPF, DKIM and DMARC records change rarely and are fine at 3600.

How long do the changes take?

Your authoritative nameservers answer with the new record as soon as your DNS host has published it. A resolver that cached the old answer keeps it until the old TTL runs out; a name that did not exist before may be remembered as missing for the negative-caching time in your SOA record.

There is no moment at which a change is everywhere at once. The propagation tool shows what a fixed set of public resolvers answer at the time of the check, reported as a count such as "9 of 12 resolvers", and nothing more than that.

Providers re-check your records on their own schedule, so a verification button in the panel can stay red for a while after DNS is already correct.

Common mistakes

• Building the MX host or the DKIM targets by hand. A one-character difference is enough for verification to fail.
• Enabling DKIM before both CNAME records resolve: the portal refuses, and mail stays signed with the onmicrosoft.com domain, which does not align for DMARC.
• Two SPF records. A domain may have only one TXT record that starts with v=spf1; a second one makes SPF fail with a permanent error. Merge the include: mechanisms into one record.
• Leaving the old provider’s MX records next to the new ones. Mail is then delivered to either, depending on priority and chance.
• Typing the full name into a host field that appends the domain, which produces google._domainkey.example.com.example.com. Look the record up after saving it.
• A DKIM key cut in half. Long TXT values must be split into quoted strings of at most 255 characters; most DNS hosts do this for you, some do not.
• More than ten DNS lookups in SPF after adding several include: mechanisms. The SPF checker counts them.
• An MX record that points to a CNAME or to an IP address. It must point to a hostname that has A or AAAA records.