Email Authentication for Microsoft 365

The short answer: For Microsoft 365, publish an SPF TXT record containing include:spf.protection.outlook.com, publish two DKIM CNAME records (selector1._domainkey and selector2._domainkey) and switch signing on in the Microsoft Defender portal, then add a DMARC TXT record at _dmarc.yourdomain.com, starting at p=none. Microsoft 365 does not do any of this for a custom domain on its own.

Microsoft 365 signs and authenticates mail for its default yourtenant.onmicrosoft.com domain out of the box. Your own domain is different: SPF, DKIM, and DMARC are DNS records and settings you have to publish, and DKIM signing has to be switched on. This guide gives the exact records, the portal path, and the checks that prove each one works.

Admin menus change regularly. Where this guide names a portal path, the direct URL is included as well, and the record formats come from Microsoft's own documentation.

What Microsoft 365 Does and Does Not Do for Your Domain

If your DNS is hosted by Microsoft or your registrar supports Microsoft's automated domain connection, the domain wizard may add the MX and SPF records for you. Check what actually exists with the SPF checker rather than assuming.

Until DKIM is enabled for your custom domain, Microsoft signs outbound mail with a default key tied to your onmicrosoft.com domain. That signature is valid, but its d= domain does not match your From address, so it cannot satisfy DMARC alignment. Only SPF can carry DMARC in that state, and SPF breaks whenever mail is forwarded.

Step 1: SPF for Microsoft 365

The record

Publish one TXT record at the root of your domain (@):

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

The include spf.protection.outlook.com is Microsoft's published sending range for Exchange Online. -all tells receivers to reject anything not listed. If you are not yet sure every sender is covered, start with ~all and tighten later. The trade-offs are in SPF hard fail vs soft fail.

Rules that cause most SPF failures

• One SPF record per domain. Two TXT records starting with v=spf1 produce a permanent error (RFC 7208, section 4.5). Merge them.
• 10 DNS lookups maximum. Every include: counts, and so do the lookups nested inside it. Going over returns permerror, which receivers treat as a failure. The fix is in SPF too many DNS lookups.
• Add other senders to the same record. A mailing platform, CRM, or invoicing tool needs its own include. Example with two extra senders:

v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net include:_spf.hubspot.com -all

Check each vendor's current documentation for its include string, as they change. Adding third-party senders to your SPF record covers the process.

• Hybrid or on-premises servers. If an on-premises Exchange server or a printer or scanner relays mail directly to the internet, add its public IP with ip4:203.0.113.25.
• Domains that send no mail. Publish v=spf1 -all on parked domains and unused subdomains so they cannot be spoofed.

Build the record with the SPF generator if you have several senders. For syntax details see the SPF record syntax guide.

Step 2: DKIM for Microsoft 365

What you publish

Microsoft uses two selectors so it can rotate keys without downtime. For each custom domain you publish two CNAME records. The hostnames are always the same:

For contoso.com in a tenant called contoso, the first record is:

selector1._domainkey.contoso.com.  CNAME  selector1-contoso-com._domainkey.contoso.onmicrosoft.com.

The domain's dots become dashes, which is why contoso.com turns into contoso-com.

Newer tenants use a different target. Microsoft's documentation now shows targets of the form selector1-contoso-com._domainkey.contoso.n-v1.dkim.mail.microsoft for many tenants (the letter before -v1 varies). The older onmicrosoft.com pattern still appears in older tenants. Because of this, never build the values by hand. Copy them from the portal or from PowerShell.

Get the exact values and enable signing

1. Open the Microsoft Defender portal at security.microsoft.com.
2. Go to Email & collaboration > Policies & rules > Threat policies > Email authentication settings, then open the DKIM tab. The direct URL is security.microsoft.com/authentication?viewid=DKIM. Menus change, so search for "Email authentication settings" if the path differs.
3. Select your custom domain. The flyout lists the two CNAMEs under Publish CNAMEs.
4. Publish both at your DNS provider.
5. Wait for DNS to update. This is often minutes, but allow up to 48 hours.
6. Reopen the flyout and switch Sign messages for this domain with DKIM signatures to Enabled.

If you enable it too early, the portal reports that the CNAME records do not exist yet. Publish them, wait, and try again.

The PowerShell route

Connect to Exchange Online PowerShell, then:

Get-DkimSigningConfig -Identity yourdomain.com | Format-List Selector1CNAME, Selector2CNAME, Enabled
New-DkimSigningConfig -DomainName yourdomain.com -KeySize 2048 -Enabled $false
Set-DkimSigningConfig -Identity yourdomain.com -Enabled $true

New-DkimSigningConfig is only needed if the domain has no DKIM configuration yet. Microsoft's documentation lists 1024 and 2048 as the key sizes. Use 2048 unless a DNS provider limitation stops you.

DNS provider gotchas

• Doubled domain names. Some providers append your domain automatically. If you enter selector1._domainkey.yourdomain.com there, you may end up with selector1._domainkey.yourdomain.com.yourdomain.com. Enter just selector1._domainkey in that case.
• Cloudflare. Set the two CNAMEs to DNS only (grey cloud). A proxied CNAME will not resolve to the DKIM key.
• Existing selectors. Microsoft's selectors are separate from Google's google selector or an ESP's selector, so they can coexist in the same zone.

Rotating keys

Rotation is available from the same flyout and via Rotate-DkimSigningConfig. Microsoft states that a rotation takes four days and that you cannot start another while one is in progress. Do not delete either CNAME afterwards, since signing alternates between them.

Step 3: DMARC for Microsoft 365

DMARC is a DNS record, not a Microsoft 365 setting. Publish a TXT record:

p=none is monitoring only. Mail delivery is unchanged, and receivers begin sending aggregate reports to the rua address. Read them for two to four weeks to find every system that sends as your domain, then move to p=quarantine and p=reject. The staging plan is in DMARC policy: none, quarantine, reject, and reading the XML is covered in DMARC aggregate reports.

Build the record with the DMARC generator.

Why DKIM matters for DMARC

DMARC passes when SPF or DKIM passes and aligns with the From domain. Once DKIM is enabled on your custom domain, Microsoft signs with d=yourdomain.com, which aligns. Forwarded mail usually breaks SPF but keeps the DKIM signature, so DKIM is what keeps forwarded mail passing.

Inbound handling is a separate setting

Your DMARC policy governs how other people's servers treat mail claiming to be you. How Exchange Online treats inbound mail that fails someone else's DMARC is controlled by the anti-phishing policy (the option to honor the sender's DMARC record policy). Those are different settings.

Step 4: Verify All Three

Read the headers

Send a message to a Gmail address, open Show original, and look for:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@yourdomain.com header.s=selector1 header.b=AbC123;
       spf=pass (google.com: domain of user@yourdomain.com designates 40.107.x.x as permitted sender) smtp.mailfrom=user@yourdomain.com;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=yourdomain.com

Three things to confirm: header.i=@yourdomain.com (not onmicrosoft.com), a selector of selector1 or selector2, and dmarc=pass. The email header analyzer parses pasted headers, and how to read email headers explains each field.

Check the DNS

• SPF checker: confirms a single record, the Microsoft include, and the lookup count.
• DKIM checker: enter your domain and the selector selector1 (then selector2).
• DMARC checker: confirms the record and policy.
• Email security score: runs everything in one pass.

Troubleshooting

Common Mistakes

• Assuming Microsoft publishes DKIM and DMARC for you.
• Publishing the DMARC record at the root instead of _dmarc.
• Jumping straight to p=reject with no monitoring period.
• Forgetting subdomains that send mail. The sp= tag sets policy for subdomains, and without it they inherit p=.
• Never rechecking after adding a new SaaS sender.

If you are comparing platforms, the Google Workspace DMARC guide shows the Google equivalents and Google Workspace vs Microsoft 365 email security compares both. For the bigger picture, see SPF, DKIM, and DMARC explained.

Frequently Asked Questions

What is the SPF record for Microsoft 365?

v=spf1 include:spf.protection.outlook.com -all, published as a TXT record at your root domain. Add other senders to that same record rather than creating another one.

Why are there two DKIM CNAME records for Microsoft 365?

Two selectors let Microsoft rotate signing keys without interrupting mail. One selector is active while the other waits for the next rotation. You need both published at all times.

Where do I enable DKIM in Microsoft 365?

In the Defender portal under Email & collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM tab. Select the domain, publish the CNAMEs, then toggle signing on. Menus change, so use the portal search if needed.

Do I need DMARC if SPF and DKIM already pass?

Yes. SPF and DKIM alone do not tell receivers what to do with spoofed mail, and they do not require alignment with your visible From address. DMARC adds both, plus reporting.

How long does Microsoft 365 DKIM take to start working?

Usually minutes to a few hours after the CNAMEs resolve, though DNS caches can stretch that to 48 hours. The toggle will not enable until Microsoft can see the records.

Next step: run the free email audit to see your SPF, DKIM, and DMARC status in one report. If you would rather not do the DNS work yourself, the email security setup service covers it.