What's the SPF record for Microsoft 365?

Microsoft 365 needs a single TXT record at the root of your domain that authorises Microsoft's outbound servers. The standard value is v=spf1 include:spf.protection.outlook.com -all, where the include covers Microsoft's full sending infrastructure and -all instructs receivers to reject anything not listed. Remember two rules: a domain may have only one SPF record, so if you already send through a CRM or marketing tool you must merge their include into the same record rather than creating a second one; and SPF resolution is capped at ten DNS lookups, so stacking too many providers causes a permerror that silently breaks authentication. If you are still migrating, you can start with a soft fail ~all and tighten to -all once you are confident every legitimate sender is accounted for.

Why won't Microsoft 365 let me enable DKIM?

The Enable toggle in the Defender portal stays greyed out or throws an error until both DKIM CNAME records resolve in public DNS. Microsoft 365 publishes two records, selector1._domainkey and selector2._domainkey, that both point back to your onmicrosoft.com tenant, and the portal validates that both exist before it will let you switch signing on. If you only created one, or if DNS has not finished propagating, enabling fails. Use a dig or nslookup check on both selectors first, wait for propagation, then retry. Note that publishing the CNAMEs is necessary but not sufficient: even once both resolve, DKIM signing does not start until you manually flip the toggle to Enabled. The DNS records merely unlock the setting; the signing itself is a tenant-side switch you control.

Do I use a TXT or CNAME for M365 DKIM?

Microsoft 365 uses CNAME records for DKIM, not a TXT public key. Many other providers hand you a single long TXT record containing the public key directly, but Microsoft instead gives you two CNAMEs, selector1._domainkey and selector2._domainkey, that point at targets inside your onmicrosoft.com tenant where the actual keys are hosted. The two-selector design lets Microsoft rotate signing keys automatically behind the scenes without you ever editing DNS again, because one selector can stay live while the other is rolled over. So when you set this up, create two CNAME records exactly as shown in the Defender portal, do not paste a TXT key, and do not skip the second selector.

How do I set DMARC for Microsoft 365?

Publish a single TXT record at the _dmarc subdomain of your domain. Start in monitoring mode with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com so that nothing is blocked but aggregate reports begin arriving, letting you confirm legitimate mail passes SPF or DKIM alignment. After a week or two of clean reports, raise the policy to p=quarantine, which sends failing mail to junk, and finally to p=reject, which refuses spoofed mail outright. Always keep a rua address so you can see who is sending as your domain; tightening the policy without reports is guesswork. The key discipline is to advance only when reports show your real senders authenticating cleanly. Jumping straight from none to reject is the most common way to silently lose legitimate mail.

Set Up SPF, DKIM & DMARC on Microsoft 365 (Office 365)

Microsoft 365 (formerly Office 365) sends mail for your custom domain through its own shared infrastructure, so receiving servers cannot tell your legitimate messages from a spoofer's unless you publish the three email-authentication records: SPF, DKIM and DMARC. Microsoft does not configure these in your DNS for you — it can only sign and route the mail.

The records themselves live at your domain's DNS host (GoDaddy, Cloudflare, Route 53 or wherever your nameservers point), and you publish them by hand. This guide walks through each record in the order that actually works: SPF first, then DKIM, then a DMARC policy you tighten over time.

For the site owner (plain English)

This is a configuration task, not an emergency. You are authorising Microsoft to send mail for your domain and letting receivers reject anyone who forges it. Three records do the work. SPF and DMARC are short text lines you add wherever your domain's DNS is hosted; DKIM is a pair of records Microsoft shows you in its admin portal that you paste into DNS. The step people overlook is not in DNS at all — after the DKIM records resolve you have to flip DKIM to Enabled in the Microsoft Defender portal, or nothing gets signed. You do not need a developer. If a scanner said your domain can be spoofed, the record that closes that gap is DMARC: publish it at the _dmarc host starting at p=none, then raise it after watching the reports.

What SPF record does Microsoft 365 need?

SPF (Sender Policy Framework) is a single TXT record at the root of your domain that lists which servers are allowed to send mail using your domain in the envelope. For Microsoft 365, the only thing you need to authorise is Microsoft's outbound infrastructure, which is covered by one include:

Type: TXT
Host: @
Value: v=spf1 include:spf.protection.outlook.com -all

The -all at the end is a hard fail: it tells receivers that anything not listed should be rejected. If you are still mid-migration and unsure whether every sender is accounted for, you can start with a soft fail (~all) and tighten to -all once you are confident. Microsoft itself recommends ending with -all for production domains.

One record, ten lookups

SPF has two rules that trip people up constantly. First, a domain may have exactly one SPF record. If you already send through another service — a CRM, a help desk, a marketing platform — you do not create a second v=spf1 record; you merge the includes into the one you already have, for examplev=spf1 include:spf.protection.outlook.com include:_spf.example-crm.com -all. Second, SPF resolution is capped at 10 DNS lookups by RFC 7208. Each include costs at least one lookup, and stacking too many providers will push you over the limit and cause a permerror, which silently breaks authentication.

How do I enable DKIM on Microsoft 365?

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every outbound message so receivers can confirm the body and key headers were not altered in transit. Microsoft 365 handles the signing for you, but you have to publish the public-key references and switch signing on.

Publish the two CNAMEs

Sign in to the Microsoft Defender portal at security.microsoft.com and go to Email & collaboration → Policies & rules → Threat policies → DKIM. Select your domain and Microsoft will display two records to create. Unlike many providers that hand you a single long TXT public key, Microsoft 365 uses rotating keys and points you at two CNAME records instead:

Host:  selector1._domainkey
Value: selector1-<domainGUID>._domainkey.<tenant>.onmicrosoft.com

Host:  selector2._domainkey
Value: selector2-<domainGUID>._domainkey.<tenant>.onmicrosoft.com

The CNAMEs point back to your onmicrosoft.com tenant, where the actual public keys are hosted. Because there are two selectors, Microsoft can rotate the active key behind the scenes without you ever touching DNS again — one selector stays live while the other is rolled over.

Toggle DKIM to Enabled

Once both CNAMEs have propagated, return to the DKIM page in the portal and switch the toggle for your domain to Enabled. This is the step everyone forgets: publishing the DNS records alone does not start signing. Microsoft only begins applying DKIM signatures after you flip the switch, and it will refuse to flip if it cannot resolve both CNAMEs.

The most common Microsoft 365 DKIM failure has two parts. First, M365 publishes two CNAME records (selector1 andselector2._domainkey) that both point back to youronmicrosoft.com tenant — the portal will not let you enable DKIM until both resolve, so if you only created one, the Enable button stays greyed out or throws an error. Second, even after both CNAMEs propagate you must manually toggle DKIM to Enabled in the Defender portal. DNS alone does not sign anything; the signing is a tenant-side setting that the CNAMEs merely unlock.

How do I set the DMARC policy for Microsoft 365?

DMARC (Domain-based Message Authentication, Reporting and Conformance) ties SPF and DKIM together. It tells receivers what to do when a message fails authentication and where to send reports. It is a single TXT record published at the_dmarc subdomain:

Type: TXT
Host: _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com

The p= tag is the policy, and you should walk it up in three stages rather than jumping straight to enforcement:

p=none — monitor only. Nothing is blocked, but aggregate reports start arriving at the rua address so you can see who is sending as your domain and confirm legitimate mail is passing SPF or DKIM alignment.
p=quarantine — failing mail is sent to the spam or junk folder. Move here once your reports show legitimate sources authenticating cleanly.
p=reject — failing mail is refused outright. This is the goal: full protection against spoofing of your domain.

Always include a rua address so you receive the daily aggregate reports; without them you are tightening the policy blind. Stay at each stage for a week or two until the reports are clean before advancing. Rushing fromnone to reject is the fastest way to silently lose legitimate mail.

How do I verify everything works?

DNS changes can take anywhere from a few minutes to a couple of hours to propagate. Once they have, confirm each record resolves as expected. From a terminal you can check SPF and DMARC directly:

dig +short TXT yourdomain.com
dig +short TXT _dmarc.yourdomain.com
dig +short CNAME selector1._domainkey.yourdomain.com

You want the SPF record to contain include:spf.protection.outlook.com, the DMARC record to show your chosen p= value, and the selector CNAME to resolve to your onmicrosoft.com target. Then send a test message to an external mailbox you control and inspect the headers: a passing message showsspf=pass, dkim=pass and dmarc=pass in theAuthentication-Results header. If DKIM still saysnone after the CNAMEs resolve, you almost certainly forgot to toggle signing on in the Defender portal.

Confirm your Microsoft 365 SPF, DKIM and DMARC records are published and aligned.

Check your SPF, DKIM and DMARC →

For the full picture of how these three records reinforce each other across any mail provider, read the pillar guide on email authentication. If your DNS is hosted at GoDaddy rather than configured through a different registrar, the step-by-step record entry differs slightly — see setting up SPF, DKIM and DMARC on GoDaddy. If you also run Google Workspace, see the Google Workspace walkthrough, and once you enforce, use why DMARC fails and how to fix it and why a p=none policy is not enough to diagnose any remaining problems.

How to Set Up SPF, DKIM and DMARC on Microsoft 365 (Office 365)