Microsoft 365 SPF, DKIM & DMARC setup: the exact clicks

Microsoft 365 sends your mail, but it does not authenticate it by default. SPF and DMARC live in your DNS, DKIM starts in the Defender portal, and your mail flow depends on one more record — the MX record. Here are the exact clicks and copy-paste records to get all of them right.

What are the three things you need to set up?

Email authentication has three parts, and they belong in two different places:

• SPF — a TXT record at your domain root, added in your DNS host (your registrar, not Microsoft). It lists Microsoft's servers as authorized senders.
• DKIM — two CNAME records created in the Microsoft 365 Defender portal, then published in your DNS. Microsoft then signs every outgoing email with your domain.
• DMARC — a TXT record at _dmarc, added in your DNS. It tells receivers what to do when SPF and DKIM fail.

Do them in this order — SPF, then DKIM, then DMARC — and start DMARC in monitor mode. You will need a Microsoft 365 admin account for the portal steps. If you use Google Workspace instead, the clicks are different — see the Google Workspace setup guide.

Step 1: Add and verify your domain in Microsoft 365

Sign in to the Microsoft 365 admin center (admin.microsoft.com) as an admin, then go to Settings → Domains → Add domain. Enter your domain and follow the verification step: Microsoft asks you to add a TXT record at your domain root in your DNS host, then click Verify back in the admin center. DNS changes can take up to 48 hours to show up, so if verification fails, wait and try again — nothing is broken in the meantime.

Do not change your MX record at this stage if your mail currently lives somewhere else. Changing the MX record moves incoming mail to Microsoft 365, so only do that when you are ready to receive mail there (see Step 5).

Step 2: Add the SPF record in your DNS

Log in to your domain host (Spaceship, GoDaddy, Cloudflare, or wherever your name servers point) and find the DNS records page. Add this TXT record at the root of your domain (often labelled @):

Two things to get right here. First, a domain can have only one SPF record — if you already have one from another sender, merge the includes into a single record instead of adding a second, and keep -all at the very end. Second, Microsoft recommends -all (hard fail), which is stricter than Google's ~all default: any sender not listed in the record will fail SPF, so every tool that sends as your domain must be in the record. See the SPF guide for how the syntax works, and the SPF 10-lookup limit guide if you have many includes.

Step 3: Create your DKIM keys in the Defender portal

Sign in to the Microsoft 365 Defender portal (security.microsoft.com) as an admin, then follow these clicks exactly:

1. Go to Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM.
2. Select your domain from the list.
3. Click Create DKIM keys (if keys already exist for the domain, this step is skipped and the records are shown instead).

Microsoft generates two selectors, selector1 and selector2, and shows you two CNAME records to publish. They follow this pattern — here shown for example.com in a tenant whose initial domain is example.onmicrosoft.com:

Replace example.com with your own domain, and the onmicrosoft.com part with your tenant's initial domain — copy both values exactly as Microsoft shows them for your domain, rather than typing them from this example. Two selectors exist so Microsoft can rotate keys without breaking signing: one stays live while the other is updated.

Step 4: Publish the DKIM records in DNS, then click "Enable"

Back in your DNS host, add both CNAME records exactly as shown. Then return to the DKIM page in the Defender portal, select your domain, and click Enable. Microsoft checks DNS for the records; propagation can take up to 48 hours, and if Microsoft cannot see them yet, wait and click again later. Once it succeeds, DKIM signing is on and your outbound mail gets signed with your domain.

Step 5: Point your MX record at Microsoft 365 — only when you are ready

If Microsoft 365 will also receive your mail, add this MX record at your domain root, with priority 0:

Replace example-com with your own domain name, with its dots turned into dashes (for example.com, that is example-com.mail.protection.outlook.com — Microsoft shows the exact value during domain setup). The warning from Step 1 applies here: the moment this record propagates, incoming mail for your domain starts arriving in Microsoft 365 instead of your old mailbox, so finish any mailbox migration first.

Step 6: Add a DMARC record — start at p=none

Add one more TXT record in your DNS, this time at host _dmarc:

Replace [email protected] with an inbox you control. Starting at p=none puts DMARC in monitor mode: receivers check your mail and send you aggregate reports, but take no action on failures. That is deliberate — you watch the reports for a week or two, confirm every legitimate sender passes, and only then move to p=quarantine and eventually p=reject. The DMARC rollout guide covers that path in detail.

How do I verify everything is working?

Send a test email from your Microsoft 365 account to another inbox (a personal Gmail is fine), open the message, and view the original headers — look for spf=pass, dkim=pass, and dmarc=pass in the authentication results. For a readable breakdown, paste those headers into the free email header analyzer, and run the SPF and DMARC audit tools on your domain to review the records you published. The email headers guide explains how to read the full results.

What are the most common mistakes?

• Clicking "Enable" for DKIM before DNS propagates. Microsoft cannot see the CNAME records yet. Wait, then click again — nothing breaks in the meantime.
• Publishing only one DKIM selector. Both CNAME records are needed; with one missing, signing can fail when Microsoft rotates to that selector.
• Publishing two SPF records. Multiple records invalidate SPF entirely; merge everything into one.
• Using -all while other tools also send. If a CRM or outreach tool sends as your domain, it must be in your SPF record or DKIM-signed, or it will fail.
• Changing the MX record too early. Incoming mail moves to Microsoft 365 as soon as it propagates, before your old mailbox is migrated.
• Starting DMARC at p=reject on day one. One forgotten sending service and its mail starts bouncing. Monitor first.