DKIM, SPF and DMARC for Microsoft 365: the complete setup

Microsoft 365 signs outgoing mail from the first day, but with its own onmicrosoft.com domain, not yours. DMARC only counts a signature made in the name of the domain shown in the From address, so a custom domain without DKIM set up relies on SPF alone, and fails as soon as a message is forwarded. This guide follows Microsoft’s documentation, read on 14 November 2026.

1. SPF

One TXT record on the domain:

v=spf1 include:spf.protection.outlook.com -all

If other services send mail in your name, add their include: to the same record: one SPF record per domain, ten DNS lookups at most. The free SPF record checker counts them.

2. Find your two CNAME values

DKIM in Microsoft 365 uses two CNAME records, not a TXT record with a key. Microsoft keeps the keys and rotates them; your DNS only points to them.

In the Microsoft Defender portal, go to Email & collaboration → Policies & rules → Threat policies → Email authentication settings, open the DKIM tab and select your domain. The details show the two records to publish. Or, in Exchange Online PowerShell:

Get-DkimSigningConfig -Identity yourdomain.example | Format-List Selector1CNAME,Selector2CNAME

The host names are the same for everyone: selector1._domainkey and selector2._domainkey. The targets are not. Older domains point to a name ending in .onmicrosoft.com; newer ones to a name ending in -v1.dkim.mail.microsoft, with a character Microsoft assigns. Copy the values shown for your domain; do not build them by hand from an example.

3. Publish both records

Create the two CNAME records at your DNS provider. Both are required, even though only one selector signs at a time: the other is used when the keys rotate. Publishing the key as a TXT record instead does not work.

Some DNS providers add the domain name to the host automatically: enter selector1._domainkey, not selector1._domainkey.yourdomain.example, when that is the case.

4. Turn signing on

Back on the DKIM tab, slide the toggle of your domain to Enabled. If Microsoft does not see the CNAME records yet, it says so and shows them again: wait for the DNS change to spread, then try again. Once it works, the status reads Signing DKIM signatures for this domain.

5. Check a real message

Send a message to a mailbox outside your organisation and read its headers: dkim=pass with header.d= set to your domain, not to onmicrosoft.com. The e-mail header analyzer reads them for you, and the DKIM record checker looks up selector1 and selector2.

6. DMARC

Start by watching:

_dmarc  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.example"

Read the reports for two weeks: they show every service that sends in your name, and which ones fail. Then follow From p=none to p=reject.

What goes wrong

• The toggle will not stay on: the CNAME records are missing, mistyped or not visible yet. The status CnameMissing says the same thing.
• Only selector1 was published: signing works today and breaks at the next key rotation. Publish both.
• A CNAME built from an old example: the format changed for newer domains. Use the values of the portal.
• DKIM passes with onmicrosoft.com: signing with the custom domain is not enabled, so DMARC still fails on forwarded mail.
• Another service sends as you: a newsletter or invoicing tool needs its own DKIM set up with your domain; Microsoft’s records do not cover it.

Once everything is published, the full e-mail authentication check reads SPF, DKIM and DMARC at once.