Set up SPF, DKIM and DMARC on Microsoft 365

The DNS records that make Outlook and Gmail trust your Microsoft 365 mail — publish the SPF line, the two DKIM CNAMEs and DMARC, switch DKIM on in the Defender portal, then confirm it landed.

Check your setup free → Microsoft 365 docs ↗

Before you start

What Microsoft 365 needs from your DNS.

Microsoft 365 sends your mail through Exchange Online, but receivers judge it on what your DNS says, not on the fact that Microsoft carried it. SPF authorises Microsoft's servers to send for you, DKIM signs each message so tampering shows, and DMARC ties both to the domain your recipients see and tells receivers what to do when they fail.

DKIM on a custom domain is not on by default. Microsoft generates two selector keys for you, but until you publish both CNAME records and slide the toggle to Enabled on the DKIM tab of the Defender portal, your mail from the custom domain is signed only by the shared *.onmicrosoft.com domain — which never aligns with your From address for DMARC. That missed toggle is the most common reason a Microsoft 365 domain fails DKIM alignment.

Since February 2024, Google and Yahoo require anyone sending in bulk to their users to publish SPF, DKIM and a DMARC record. On Microsoft 365, authenticating your custom domain is no longer good practice you can defer — it is the gate to your own recipients' inboxes.

The records to publish

Copy these into your DNS.

Add each record at your DNS provider — the company where your domain is registered, not Microsoft 365. Then run the checker to confirm every one resolves.

SPF record

host @ type TXT

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

One SPF record only. Microsoft recommends -all (hard fail) because you also run DKIM and DMARC. If other services send for you — a CRM, a newsletter tool — add their include: to this same line rather than publishing a second SPF record, which is a permerror that voids both.

DKIM selector 1 record

host selector1._domainkey type CNAME

value generated by Microsoft 365

A CNAME, not a TXT. The target is generated per-domain — new domains get the selector1-<domain>._domainkey.<prefix>.<char>-v1.dkim.mail.microsoft format (since May 2025), older domains the selector1-<domain>._domainkey.<prefix>.onmicrosoft.com format. Copy the exact value from the DKIM tab in the Defender portal (security.microsoft.com); do not hand-type the dynamic character.

DKIM selector 2 record

host selector2._domainkey type CNAME

value generated by Microsoft 365

The second selector, also a CNAME. Microsoft rotates signing between the two keys, so both records must exist even though only one signs at a time. Take its exact target from the same Publish CNAMEs panel in the Defender portal.

DMARC record

host _dmarc type TXT

v=DMARC1; p=none; pct=100; rua=mailto:[email protected]

Start at p=none to watch who sends as you, then raise to quarantine and reject once your reports show every legitimate sender aligning. Point rua at a mailbox you actually read, not a personal inbox.

Step by step

The whole setup, in order.

1 Publish SPF at your DNS host. At your registrar or DNS provider — not in Microsoft 365 — add the TXT record above at the root of your domain. If an SPF record already exists, edit it to include spf.protection.outlook.com rather than adding a second one. Microsoft 365 has no portal for SPF; it lives entirely in your DNS.
2 Get the two DKIM CNAME targets from the Defender portal. Go to the DKIM tab of Email authentication settings at security.microsoft.com, select your custom domain, and read the required selector1 and selector2 CNAME values from the Publish CNAMEs panel. The targets differ per domain, so copy them exactly.
3 Publish both DKIM CNAME records. At your DNS host, add the two CNAME records at selector1._domainkey and selector2._domainkey pointing to the targets you copied. They are CNAMEs, not TXT records. Both are required even though Microsoft signs with one selector at a time.
4 Enable DKIM signing. Back on the DKIM tab, once the CNAMEs resolve, slide the toggle for your domain from Disabled to Enabled. Until you do, your custom domain is not DKIM signed and DMARC will not align. This is the click most people miss.
5 Publish DMARC. Add the _dmarc TXT record above at the root of your domain. Begin at p=none so you break nothing while you read the reports, and keep the rua address pointed at a monitored mailbox.
6 Wait, then verify. DNS and Microsoft can take time to detect the CNAMEs. Once they have, run a full check here to confirm SPF resolves under the 10-lookup limit, the selector1 CNAME is found and signing, and DMARC is graded.

Where it goes wrong

The mistakes specific to Microsoft 365.

DKIM CNAMEs published, mail still unsigned The records resolve but you never slid the toggle to Enabled on the DKIM tab. Until you do, Microsoft signs your custom-domain mail only with the shared onmicrosoft.com key, which never aligns for DMARC.

DKIM added as TXT records Microsoft 365 DKIM uses CNAME records that point at Microsoft-hosted keys, not TXT records you paste. Publishing a TXT at selector1._domainkey does nothing; the record type must be CNAME.

Only one selector published Both selector1._domainkey and selector2._domainkey are required. If you publish only one, enabling DKIM fails and signing never starts, because Microsoft needs both keys in place to rotate between them.

Hand-typing the CNAME target The target contains a dynamically assigned character (for new-format domains) and your onmicrosoft.com prefix. Guessing it produces a CNAME that resolves nowhere. Always copy the exact value from the Defender portal.

A second SPF record Adding v=spf1 include:spf.protection.outlook.com as a new record alongside an existing one is a permerror. Merge every sender into a single SPF line.

SPF or DKIM on a subdomain without its own record SPF and DKIM do not inherit. If you send from marketing.yourdomain.com, that subdomain needs its own SPF record and its own DKIM CNAMEs — the root domain's records do not cover it.

Confirm it worked

Do not trust it until you have checked it.

DNS takes a few minutes to propagate. Once it has, run a full check: it reads all three records live, counts your SPF lookups, confirms the Microsoft 365 DKIM selector resolves, and grades your DMARC policy — the exact things that decide whether Gmail and Outlook trust your mail.

Check your domain → Or send a test email

Common questions

About Microsoft 365, specifically.

What is the SPF record for Microsoft 365? v=spf1 include:spf.protection.outlook.com -all, published as a TXT record at the root of your domain. Microsoft recommends -all rather than ~all because you also run DKIM and DMARC. If other services send for you, add their include: to the same record — never publish two.

What is the Microsoft 365 DKIM selector? Microsoft 365 uses two selectors, selector1 and selector2, published as CNAME records at selector1._domainkey and selector2._domainkey. Each points to a Microsoft-hosted key whose target is generated per-domain; copy the exact values from the DKIM tab in the Defender portal.

Why is my Microsoft 365 DKIM failing? Almost always one of three things: you published the CNAMEs but never enabled DKIM on the DKIM tab, so mail is signed only by onmicrosoft.com and does not align; you added the records as TXT instead of CNAME; or you published only one of the two selectors. Fix the record type, publish both, then toggle DKIM on.

Are Microsoft 365 DKIM records CNAME or TXT? CNAME. Unlike some providers that give you a TXT value to paste, Microsoft 365 points two CNAME records at keys it hosts, so it can rotate them without you touching DNS. Publishing a TXT at the selector host does nothing.

Do I need DMARC for Microsoft 365? Yes if you send in bulk to Gmail or Yahoo — both have required it since February 2024. Publish a _dmarc TXT record starting at p=none with a report address, then move to quarantine and reject once your reports show every legitimate sender aligning.

Where do I add these records — in Microsoft 365 or at my registrar? At your DNS host: the registrar or provider that controls your domain's DNS. Microsoft 365 generates the DKIM CNAME targets in the Defender portal and you enable signing there, but every record is published in your own DNS, not inside Microsoft 365.

Set it once. Know it stays set.

A DKIM key rotates, a vendor changes its SPF, an IP gets listed — and your carefully-configured domain quietly breaks. Monitoring watches all of it and tells you the day it changes.

Check your domain free → See monitoring