Microsoft 365 SPF record, DKIM and DMARC: set up Office 365 email authentication

The Microsoft 365 SPF record is one TXT record at your domain's root: v=spf1 include:spf.protection.outlook.com -all. To set up DKIM in Office 365, publish the two CNAME records the Microsoft Defender portal shows for your domain (selector1._domainkey and selector2._domainkey) and switch signing on. Finish with a DMARC record at _dmarc. All three live in your domain's DNS; Microsoft 365 only generates the values and signs the mail.

This guide is for Microsoft 365 administrators, whether you run a tenant for a five-person office or inherited one. It gives each record with its exact value, where to click, the PowerShell alternative, and how to confirm it works. For how the three standards relate, see the SPF, DKIM and DMARC setup guide.

Quick answer

• MX: the value the Microsoft 365 admin centre shows for your domain, usually example-com.mail.protection.outlook.com.
• SPF: v=spf1 include:spf.protection.outlook.com -all at the root. Add includes for other senders before the -all, in the same record.
• DKIM: Microsoft Defender portal → Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM. Publish both CNAMEs it shows, then turn on signing.
• DMARC: TXT at _dmarc with v=DMARC1; p=none; rua=mailto:[email protected], then tighten once reports are clean.
• Check it with the free email and DNS health check.

Before you start

You need an admin account with rights to change domain and email security settings (a Global Administrator can do everything below), and access to the DNS for your domain. If the domain was added to Microsoft 365 with "Microsoft manages your DNS", the admin centre may add some records for you; most businesses manage DNS at their registrar, Cloudflare or a web host instead.

Your tenant also has a built-in *.onmicrosoft.com domain. Microsoft publishes SPF and DKIM for that one; everything below is for your own custom domain.

Step 1: the Microsoft 365 SPF record

For a domain that sends only through Microsoft 365, publish this TXT record at the root (@):

example.com.  3600  IN  TXT  "v=spf1 include:spf.protection.outlook.com -all"

Special clouds use a different include, from Microsoft's own documentation:

If you have other senders, add them to the same record, never as a second SPF record:

example.com.  TXT  "v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net ip4:203.0.113.25 -all"

Microsoft's include cost 1 of SPF's 10 DNS lookups when we checked in September 2026, so it leaves room for other services. Two SPF records, or more than 10 lookups in total, make SPF fail with a permanent error; the guide to multiple SPF records and the 10-lookup limit shows how to merge and trim.

-all or ~all? Microsoft's examples end with -all (hard fail). That is fine once every sender is listed. If you are still discovering which tools send as you, ~all is the safer start, and DMARC decides what happens to failing mail in either case.

Step 2: set up DKIM in Office 365

Until you configure DKIM for your custom domain, Microsoft 365 signs outgoing mail with your onmicrosoft.com domain (d=example.onmicrosoft.com). The signature is valid, but it is not your domain, so it does not count for DMARC.

In the Microsoft Defender portal:

1. Go to Email & collaboration → Policies & rules → Threat policies → Email authentication settings, and open the DKIM tab.
2. Select your custom domain. The details pane shows its status and, if DKIM is not set up yet, the two CNAME records to publish.
3. Publish both CNAMEs at your DNS provider, exactly as shown.
4. Wait until they resolve, return to the same pane and switch Sign messages for this domain with DKIM signatures on. The status changes to "Signing DKIM signatures for this domain".

The records look like this for a domain that has been in Microsoft 365 for a while:

selector1._domainkey.example.com.  3600  IN  CNAME  selector1-example-com._domainkey.example.onmicrosoft.com.
selector2._domainkey.example.com.  3600  IN  CNAME  selector2-example-com._domainkey.example.onmicrosoft.com.

Domains added to Microsoft 365 since May 2025 get targets in a newer format that ends in dkim.mail.microsoft and includes a partition part specific to your tenant. Do not build these by hand; copy both values from the portal. Microsoft keeps two selectors so it can rotate keys: it signs with one while the other is prepared, and the CNAMEs let it change the key without you touching DNS.

With PowerShell, in Exchange Online PowerShell:

Get-DkimSigningConfig -Identity example.com | Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME
Set-DkimSigningConfig -Identity example.com -Enabled $true

If the domain has no signing configuration yet, create one first with New-DkimSigningConfig -DomainName example.com -Enabled $false, publish the CNAMEs from the first command, then enable it.

The guide to DKIM, selectors and the DKIM record explains what the selectors and keys do.

Step 3: add DMARC

DMARC is a DNS record only; there is nothing to switch on in Microsoft 365. Add a TXT record with the host _dmarc:

_dmarc.example.com.  3600  IN  TXT  "v=DMARC1; p=none; rua=mailto:[email protected]"

Create the dmarc@ mailbox or a shared mailbox first, or point rua at a report service. Mail from Microsoft 365 passes DMARC as soon as custom-domain DKIM is on. Leave p=none for two to four weeks, read the DMARC reports to find the other tools that send as you, then move to p=quarantine and p=reject as the DMARC policy guide describes.

How Microsoft 365 handles DMARC on incoming mail

Your DMARC record protects your domain at every receiver. Separately, Microsoft 365 applies other domains' DMARC policies to the mail your users receive. By default, a message that fails DMARC for a domain with p=reject is rejected with 550 5.7.509 Access denied, sending domain … does not pass DMARC verification and has a DMARC policy of reject, and p=quarantine sends it to junk or quarantine. Administrators can change this in the anti-phishing policy.

If one of your own senders shows up in a 5.7.509 bounce from another company, the problem is on your side: that tool is not signing with DKIM for your domain. The guide to DMARC fail and 554 5.7.5 bounces walks through the diagnosis.

Outlook.com, Hotmail and Live addresses have had their own rule since 5 May 2025: domains sending more than 5,000 messages a day need SPF, DKIM and DMARC, or mail is rejected with 550 5.7.515 Access denied. See the guide to Gmail, Yahoo and Outlook bulk-sender requirements.

Other senders on a Microsoft 365 domain

• Newsletter, CRM and helpdesk tools: set up domain authentication in each one. Many need only DKIM CNAMEs, not an SPF include.
• Multifunction printers and apps using SMTP relay through a connector send through Microsoft 365, so they are covered by its SPF include and DKIM.
• Apps that send directly from your own server need their IP address in SPF (ip4:), and ideally DKIM of their own.
• A third-party security gateway for outbound mail changes the path: the gateway's addresses must be in SPF, and a gateway that rewrites messages after Microsoft signed them breaks DKIM unless it signs again.
• Hybrid Exchange: on-premises servers that send to the internet directly need their addresses in SPF.

Verify each record

Run the check on your domain. It recognises Microsoft 365 from the MX record, so any record it suggests is written for Microsoft 365. SPF should show "valid" with the lookup count, DMARC should name your policy, and DKIM should show a key for selector selector1 or selector2.

Then test real mail: send from Outlook to a Gmail address, open the message and choose Show original. You want SPF: PASS, DKIM: 'PASS' with domain example.com (not onmicrosoft.com) and DMARC: PASS. Microsoft's own Message Header Analyzer shows the same results for a message received in Outlook.

Common mistakes

• Two SPF records after a migration from another host. Merge them into one.
• Publishing the CNAMEs and never enabling signing. Microsoft keeps signing with onmicrosoft.com until you switch it on.
• Typing the CNAME targets yourself. The format depends on your tenant and when the domain was added; copy them from the portal or PowerShell.
• Proxied DKIM CNAMEs on Cloudflare.
• A -all SPF record before every sender is listed. Your newsletter tool's mail then fails SPF; with a strict DMARC policy and no DKIM, it is rejected.

Questions people ask

What is the SPF record for Microsoft 365?

For the worldwide Microsoft 365 service it is a TXT record at your domain's root with the value v=spf1 include:spf.protection.outlook.com -all. GCC High and DoD tenants use include:spf.protection.office365.us, and tenants operated by 21Vianet use include:spf.protection.partner.outlook.cn. Add other senders' includes to the same record rather than creating a second one.

How do I set up DKIM in Office 365?

Open the Microsoft Defender portal, go to Email authentication settings and the DKIM tab, and select your domain. Publish the two CNAME records it shows, selector1._domainkey and selector2._domainkey, at your DNS provider. When they resolve, switch on signing for the domain. Until you do, Microsoft signs with your onmicrosoft.com domain, which does not help DMARC.

Why does Microsoft 365 say the DKIM CNAME records are missing?

Because it cannot find them in public DNS yet, or they do not match. Check that both CNAMEs exist at selector1._domainkey and selector2._domainkey, point to exactly the targets the portal shows, are not proxied on Cloudflare, and were not created as selector1._domainkey.example.com.example.com. After a fix, allow for the old record's TTL before retrying.

Should the Microsoft 365 SPF record end with -all or ~all?

Microsoft's examples use -all, which is right once every service that sends as your domain is listed. While you are still finding them, ~all is the safer start. With DMARC in place the difference is small: DMARC, not the SPF qualifier, decides what happens to mail that fails, and it looks at DKIM too.

Does Microsoft 365 enforce DMARC on incoming email?

Yes. By default Microsoft 365 rejects incoming mail that fails DMARC for a sender domain with p=reject, with the error 550 5.7.509, and sends mail that fails under p=quarantine to junk or quarantine. Administrators can adjust this in the anti-phishing policy. It applies other domains' policies; your own DMARC record protects your domain at other receivers.