Microsoft 365 SPF, DKIM and DMARC: DNS records, the Defender portal and testing

To authenticate Microsoft 365 email on your own domain, publish three things in DNS: an SPF TXT record with v=spf1 include:spf.protection.outlook.com -all, two DKIM CNAMEs (selector1._domainkey and selector2._domainkey) using the values the Defender portal gives you, and a DMARC TXT record at _dmarc, starting with p=none. Then switch DKIM signing on.

To check it on your own site: SEO audit

One line on each. SPF is the list of servers allowed to send with your domain. DKIM is a signature on every message that the recipient checks against a public key published in your DNS. DMARC says what to do with mail that passes neither SPF nor DKIM in alignment with the visible sender, and where to send reports. This guide applies all three to Microsoft 365, using Microsoft Learn documentation updated on 3 July 2026; if you use Google, the equivalent guide is Google Workspace SPF, DKIM and DMARC.

What does Microsoft 365 do for you, and what do you have to do?

That is how Microsoft sums it up across its three guides123. One detail matters: Microsoft 365 has no portal or cmdlet for managing SPF; you write it in your domain's DNS, at your registrar or DNS host1.

Step 1: the SPF record

If Microsoft 365 is your only source of email, the TXT record at the root of the domain is1:

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

What Microsoft says about each part:

1. -all rather than ~all. Microsoft recommends the hard fail (-all) because it also recommends DKIM and DMARC. It explains that DMARC treats both as an SPF failure, but with ~all the DMARC policy has practically no effect on messages that fail SPF and carry no DKIM signature1. Google, by contrast, recommends ~all for Google Workspace.
2. One SPF record per domain or subdomain. Two records make SPF return permerror1. If another service also sends for you, add its include: to the same record.
3. Fewer than 10 DNS lookups. include:, a, mx, exists and redirect count; ip4:, ip6: and all do not. Nested include: statements add their own lookups, so fewer than ten include: statements does not guarantee fewer than ten lookups1.
4. Do not "flatten" Microsoft's include (replace it with IP addresses): its sending infrastructure uses addresses that change often1.
5. A TTL of at least 3600 seconds, to avoid DNS lookup timeouts1.

Every subdomain that sends email needs its own SPF record. For services you do not control, such as a newsletter platform, Microsoft recommends a subdomain (marketing.example.com) so their problems do not hurt the main domain's reputation1.

Step 2: DKIM with the two CNAMEs

Microsoft 365 generates two key pairs per domain and publishes the public keys in its own zone. You only create two CNAME records pointing at them; one is active and the other waits for the next rotation2.

The CNAME format changed in May 2025

Custom domains added since May 2025 use a new target format2:

selector1._domainkey  →  selector1-<domain-with-dashes>._domainkey.<initial-prefix>.<letter>-v1.dkim.mail.microsoft
selector2._domainkey  →  selector2-<domain-with-dashes>._domainkey.<initial-prefix>.<letter>-v1.dkim.mail.microsoft

<domain-with-dashes> is your domain with dashes instead of dots (example-com), <initial-prefix> is the variable part of your onmicrosoft.com domain, and <letter> is a character Microsoft assigns (for example n or r) that you cannot choose. Domains that already existed keep the old format, selector1-example-com._domainkey.example.onmicrosoft.com, and the two formats cannot coexist on the same selector2. That is why Microsoft insists: copy the exact value from the portal or PowerShell; the values in its documentation are illustrative.

Enabling it in the Microsoft Defender portal

1. Open Email & collaboration > Policies & rules > Threat policies > Email authentication settings, or go straight to https://security.microsoft.com/authentication?viewid=DKIM2.
2. On the DKIM tab, find your domain. Its status should be NoDKIMKeys and the toggle disabled.
3. Try to switch the toggle on. An error appears containing the CNAME values; dismiss it. The status becomes CnameMissing.
4. Open the domain's details and copy both values from Publish CNAMEs.
5. At your DNS provider, create the two CNAMEs.
6. After a while (Microsoft says a few minutes, possibly longer), return to the details and switch on Sign messages for this domain with DKIM signatures. The status should change to "Signing DKIM signatures for this domain"2.

Or with Exchange Online PowerShell

# Status and CNAME values for every domain
Get-DkimSigningConfig | Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME

# If the domain is not listed: create the configuration with a 2048-bit key (the default is 1024)
New-DkimSigningConfig -DomainName example.com -Enabled $false -KeySize 2048

# Once both CNAMEs are published: turn signing on
Set-DkimSigningConfig -Identity example.com -Enabled $true

All three cmdlets and the -KeySize parameter (1024 by default, or 2048) come from Microsoft's guide2. If Set-DkimSigningConfig cannot find the CNAMEs, it returns an error with the expected values: check the dashes, dots and underscores, wait and try again. To rotate keys later there is Rotate-DkimSigningConfig, and the change takes four days (96 hours) to take effect2.

Step 3: DMARC in phases

Before DMARC, Microsoft asks you to have SPF and DKIM configured on every domain and subdomain that sends from Microsoft 3653. The record is a TXT on the host _dmarc, which is mandatory.

Microsoft suggests starting with a low-volume domain or subdomain and moving up in phases3:

1. p=none: no action requested. You read the aggregate reports (rua) and fix the senders that fail.
2. p=quarantine: failing mail is accepted but flagged, for example into the junk folder.
3. p=reject: failing mail is rejected. This is the end goal for all your domains.

Two points from the documentation. With p=quarantine or p=reject, outbound Microsoft 365 mail that fails DMARC at the destination is routed through its high-risk delivery pool, and there is no override3. And aggregate reports usually arrive once a day as a compressed XML file that is hard to read by hand: Microsoft suggests automating it or using a DMARC reporting service3.

Microsoft's examples include pct=100. RFC 9989, published in May 2026 to replace the original DMARC specification, removed that tag and lists it as historic4; since 100 is also the default according to Microsoft, the example below leaves it out.

Do not forget the onmicrosoft.com domain if you do not send from it: Microsoft recommends publishing v=DMARC1; p=reject there from the Microsoft 365 admin centre, under Settings > Domains > your onmicrosoft.com domain > DNS records > Add record3.

The example records for example.com

This is the DNS zone for a domain added after May 2025, with the initial domain example.onmicrosoft.com. The letter n in the CNAMEs is illustrative: yours may be different.

example.com.                       3600 IN TXT   "v=spf1 include:spf.protection.outlook.com -all"
selector1._domainkey.example.com.  3600 IN CNAME selector1-example-com._domainkey.example.n-v1.dkim.mail.microsoft.
selector2._domainkey.example.com.  3600 IN CNAME selector2-example-com._domainkey.example.n-v1.dkim.mail.microsoft.
_dmarc.example.com.                3600 IN TXT   "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

What does Outlook.com require from high-volume senders?

On 2 April 2025 Microsoft announced requirements for domains sending more than 5,000 messages a day to its consumer service, Outlook.com, which covers outlook.com, hotmail.com and live.com addresses5:

Enforcement began on 5 May 2025. In an update on 29 April 2025, Microsoft dropped its original plan to send non-compliant mail to junk and decided to reject it with the error 550; 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level.5 If you see that error in a bounce, the problem is your domain's authentication, not the recipient.

How to check it

1. On a real message: send an email to an account on another system (Gmail or Outlook.com). Microsoft warns that messages within your own organisation carry no DKIM signature, and advises against testing with AOL2. In the header, DKIM-Signature should show d=example.com, and Authentication-Results should show dkim=pass, spf=pass and dmarc=pass.
2. With the header analyser: Microsoft points to the Message Header Analyzer at https://mha.azurewebsites.net for reading long headers2.
3. In PowerShell: Get-DkimSigningConfig should show Enabled: True and Status: Valid for your domain2.
4. In DNS: look up the TXT records at the root and at _dmarc.example.com, and the CNAMEs for both selectors, with any public DNS tool.

What SmoothSeen does with this

SmoothSeen queries the DNS of the domain you analyse and checks whether it has an SPF record and a DMARC record, and with which policy. It does not check DKIM: the public key lives at a name that depends on the selector, and although Microsoft 365 calls its selectors selector1 and selector2, other providers use different names that cannot be guessed from outside. For DKIM, the reliable proof is the header of a real message.

What to do this week

Run Get-DkimSigningConfig or open the DKIM tab in the Defender portal and check your custom domains show "Valid". If any is still at CnameMissing, publish the CNAMEs today and leave DMARC at p=none so you can read the first reports. Afterwards, to review the rest of your site, analyse it with SmoothSeen.

Frequently asked questions

Why does Microsoft recommend -all while Google recommends ~all?

Each provider applies its own reasoning. Google prefers mail from unlisted servers to be flagged as suspicious. Microsoft prefers -all because, according to its documentation, with ~all the DMARC policy has practically no effect on messages that fail SPF and carry no DKIM signature. If you use both services, publish a single SPF record with both include: statements.

Why do my DKIM CNAMEs look different from the tutorials?

Because Microsoft changed the format in May 2025. Domains added since then point to a name ending in dkim.mail.microsoft, with a letter Microsoft assigns; older domains still point to your onmicrosoft.com domain. Always copy the values from the Defender portal or from Get-DkimSigningConfig, never from an example.

Do I need DMARC for the onmicrosoft.com domain?

Microsoft recommends it. SPF and DKIM come preconfigured on that domain, but DMARC does not. If you do not send from it, publish v=DMARC1; p=reject from the Microsoft 365 admin centre, in the domains section under DNS records. That way nobody can successfully spoof it with servers that enforce DMARC.

What does error 550 5.7.515 mean?

It is Outlook.com rejecting a domain that sends it more than 5,000 messages a day without meeting its authentication requirements: SPF passing, DKIM passing and DMARC at p=none or stricter, aligned with one of the two. The fix lies in the DNS and DKIM signing of the sending domain, not in the recipient's mailbox.