How to set up SPF, DKIM, and DMARC for Microsoft 365

To authenticate mail from your domain on Microsoft 365 you publish four DNS records. DKIM is the one that trips people up: instead of a single generated TXT key, Microsoft has you publish two selector CNAME records that point back to your tenant, then flip a switch in the Microsoft Defender portal. The other three — SPF, DMARC, and MX — are ordinary DNS entries. The values below are the stable ones; confirm the exact steps against Microsoft's current guide, because the Defender portal layout changes.

SPF

Publish one TXT record at your domain's root (host @):

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

include:spf.protection.outlook.com authorizes Microsoft's Exchange Online servers. Microsoft recommends ending the record with -all, a hard fail, rather than the softer ~all. If you also send through another service — a marketing platform, a ticketing system — add its include: before the -all, in the same single record. A domain may publish only one SPF record, and stacking too many includes can trip the ten-lookup limit and cause a PermError. Check the result with the SPF checker.

DKIM

This is where Microsoft 365 differs from Google Workspace. Microsoft generates the key pair on its side, so your job is to publish two CNAME records that point at your tenant, then turn signing on:

1. Add two CNAME records in your DNS:

   • Host selector1._domainkey pointing to selector1-<yourdomain>._domainkey.<tenant>.onmicrosoft.com
   • Host selector2._domainkey pointing to selector2-<yourdomain>._domainkey.<tenant>.onmicrosoft.com

   In the target, <yourdomain> is your domain with the dots replaced by dashes, so contoso.com becomes contoso-com, and <tenant> is your initial onmicrosoft.com name. The Microsoft 365 admin center lists the exact target for each selector under your domain — copy those values rather than build them by hand.

2. Open the Microsoft Defender portal at security.microsoft.com and go to Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM. That path has moved before and may move again, so if a menu name differs, follow Microsoft's DKIM guide.

3. Select your domain and toggle Enable. Microsoft checks that the two CNAMEs resolve and then starts signing your outgoing mail.

Publish the CNAMEs before you touch the toggle. Enabling DKIM while the records are still propagating returns an error, because Microsoft cannot find the keys it expects to sign with. Once both are live, confirm them with the DKIM checker using the selector selector1.

DMARC

With SPF and DKIM in place, publish a DMARC policy as a TXT record at host _dmarc:

v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

Start at p=none, which only monitors and sends you aggregate reports at the rua address. Read the reports until you are confident every legitimate source is aligned, then raise the policy to p=quarantine and finally p=reject. Moving straight to p=reject risks blocking a legitimate sender you did not know about. Read your current record with the DMARC checker.

MX

Microsoft 365 uses a single MX record. Its value follows the form <domain-with-dashes>.mail.protection.outlook.com — the same dots-to-dashes substitution as the DKIM targets, so contoso.com becomes contoso-com.mail.protection.outlook.com. At your domain's root, publish:

Host: @   Priority: 0   Value: yourdomain-com.mail.protection.outlook.com

Rather than assemble the value yourself, copy the exact one the Microsoft 365 admin center lists under your domain's DNS records. Microsoft shows it for your specific domain, and copying it avoids a typo that would silently break inbound mail. Check yours with the MX lookup. If you are moving from another host, only switch MX once mailboxes are ready in Microsoft 365, because MX controls where all inbound mail lands.

Check your work

DNS changes can take up to a day to propagate. After you publish, run a check from the Relaymetry home page to read all four records at once and confirm SPF, DKIM, and DMARC pass. For the mechanics behind these records rather than the Microsoft-specific steps, see email authentication explained. If you run the domain on Google Workspace instead, its single generated TXT key is covered in the Google Workspace guide, and the setup hub lists every provider.