Microsoft 365 email authentication requires SPF with include:spf.protection.outlook.com, DKIM enabled through the Defender portal with two CNAME records, and DMARC at minimum p=none progressing toward enforcement. Microsoft began enforcing bulk sender requirements for Outlook.com, Hotmail.com, and Live.com in May 2025, matching the Gmail and Yahoo requirements from February 2024. Misconfiguration causes the majority of Microsoft 365 deliverability complaints.
Microsoft 365 is the email backbone for over 400 million paying users and hundreds of thousands of organizations worldwide. Despite this scale and Microsoft long history in email, authentication setup remains a consistent pain point. The documentation is fragmented across multiple product pages, the Defender portal interface has shifted several times in the last two years, and the DKIM CNAME structure differs meaningfully from the Google Workspace model.
This guide consolidates the complete Microsoft 365 authentication setup into one reference, covering SPF, DKIM, DMARC, the May 2025 Outlook bulk sender enforcement, and the specific issues that catch administrators off guard. It is written for Microsoft 365 and Office 365 administrators who need authentication to work correctly the first time.
- The correct Microsoft 365 SPF record is v=spf1 include:spf.protection.outlook.com -all for domains sending only through Microsoft. Using ~all instead of -all weakens enforcement.
- DKIM in Microsoft 365 uses two CNAME records (selector1 and selector2) that point to Microsoft DNS zone, not TXT records like Google Workspace.
- DKIM signing is disabled by default for custom domains. After publishing the CNAME records, you must explicitly enable signing in the Microsoft Defender portal.
- Microsoft began enforcing bulk sender requirements on Outlook.com, Hotmail.com, and Live.com in May 2025. Domains sending 5,000 or more daily messages to these receivers without DMARC will see degraded deliverability.
- Microsoft includes 3 DNS lookups in the SPF include, leaving 7 for additional senders. This is slightly more generous than Google Workspace 4-lookup footprint.
The May 2025 Microsoft Enforcement Changes
Microsoft spent 2024 signaling that consumer mailbox enforcement was coming, then activated it in May 2025. Bulk senders targeting Outlook.com, Hotmail.com, and Live.com now face substantially the same requirements Gmail introduced in February 2024:
- Full SPF, DKIM, and DMARC authentication with alignment
- One-click unsubscribe via RFC 8058 List-Unsubscribe-Post header
- Spam complaint rate below 0.3%
- Proper reverse DNS on sending IPs
- TLS connections for message transport
Microsoft has signaled that these requirements will expand throughout 2026, potentially dropping the 5,000 daily message threshold for enforcement entirely. Administrators who have not completed authentication setup are working against a tightening timeline.
Step 1: Configure SPF for Microsoft 365
SPF for Microsoft 365 requires a single include: mechanism pointing to Microsoft authorized sending infrastructure. The baseline record for a domain sending only through Microsoft 365:
v=spf1 include:spf.protection.outlook.com -allPublish this as a TXT record at the root of your domain. Note the use of -all (hard fail) rather than ~all (soft fail). Hard fail tells receiving servers to reject non-matching senders outright; soft fail tells them to accept with a caution flag. Microsoft own documentation recommends -all once you are confident all legitimate sources are included.
For domains that send through additional services, add the relevant include: mechanisms to the same record:
v=spf1 include:spf.protection.outlook.com include:sendgrid.net include:_spf.salesforce.com -allThe Microsoft include uses 3 DNS lookups (slightly less than Google Workspace 4-lookup footprint), leaving 7 of the RFC 7208 10-lookup budget for additional senders. Use a SPF checker to verify your record resolves and stays under the lookup limit.
Warning: Microsoft legacy SPF include (outlook.com directly) is no longer authoritative. Always use spf.protection.outlook.com. Records that include outlook.com without the spf.protection prefix may pass validators but will produce inconsistent authentication results as Microsoft sending infrastructure shifts.
Step 2: Enable DKIM in Microsoft 365
DKIM setup in Microsoft 365 differs significantly from Google Workspace. Rather than a single TXT record with the full public key, Microsoft uses two CNAME records pointing to selector zones in the Microsoft DNS namespace. The two selectors (selector1 and selector2) allow for key rotation without downtime.
Publishing the DKIM CNAME Records
Microsoft provides the CNAME targets dynamically based on your tenant configuration. Typical targets look like this:
selector1._domainkey.yourdomain.com CNAME selector1-yourdomain-com._domainkey.yourtenant.onmicrosoft.com
selector2._domainkey.yourdomain.com CNAME selector2-yourdomain-com._domainkey.yourtenant.onmicrosoft.comReplace yourdomain-com with your actual domain name (with hyphens replacing dots) and yourtenant with your Microsoft 365 tenant name. The specific values are visible in the Defender portal under Email and Collaboration, then Policies and Rules, then Threat Policies, then Email Authentication Settings.
Activating DKIM Signing
Publishing the CNAME records alone does not enable DKIM. After DNS propagation (typically 15 minutes to 2 hours), you must explicitly enable signing:
- Open the Microsoft Defender portal at security.microsoft.com
- Navigate to Email and Collaboration, then Policies and Rules
- Click Threat Policies, then DKIM under Rules
- Select your custom domain from the list
- Click the toggle to Enable signatures for this domain
If the toggle cannot be activated and shows an error, the CNAME records have not yet propagated or are incorrectly configured. Verify with a DKIM checker by querying selector1._domainkey.yourdomain.com.
Critical: DKIM signing is disabled by default in Microsoft 365 for all custom domains. Many administrators publish the CNAME records, verify them with external tools, and believe DKIM is working. Without the toggle enabled in Defender portal, the CNAME records are published but Microsoft is not signing outgoing mail. This is the single most common Microsoft 365 authentication failure.
Step 3: Publish a DMARC Record
DMARC for Microsoft 365 follows the same RFC 7489 structure as any other sender. Create a TXT record at _dmarc.yourdomain.com:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1Start at p=none for 30 to 60 days to monitor sending sources via aggregate reports, then progress through quarantine to reject. See our detailed walkthrough on DMARC progression and alignment for the full enforcement roadmap.
Microsoft-Specific DMARC Behavior
Microsoft honors DMARC policy but has some behaviors worth knowing about:
- Outlook.com, Hotmail.com, and Live.com enforce DMARC per the published policy (reject, quarantine, or none)
- Microsoft 365 tenants (hosted business mail) use a slightly different enforcement logic that incorporates tenant-level anti-spam policy
- Microsoft does not send DMARC forensic (ruf=) reports, consistent with Google and Yahoo. Only aggregate (rua=) reports arrive.
- Microsoft supports publishing DMARC records on subdomains, and the sp= tag applies organizational policy to all subdomains that do not have their own record.
Use a DMARC generator to build records with custom tag combinations.
Verifying All Three Work Together
Send a test message from your Microsoft 365 account to a personal email address at Gmail, Yahoo, or Outlook.com. Open the message headers and locate the Authentication-Results field. Expected output:
Authentication-Results: spf=pass (sender IP is 40.92.xxx.xxx)
smtp.mailfrom=yourdomain.com; dkim=pass (signature was verified)
header.d=yourdomain.com; dmarc=pass action=none
header.from=yourdomain.com; compauth=pass reason=100All three (spf, dkim, dmarc) should show pass. The compauth field is a Microsoft-specific composite authentication result that considers SPF, DKIM, and DMARC together. A compauth=pass with reason=100 is the healthiest possible result.
Common failure modes and what they indicate:
| Result | Likely Cause | Fix |
|---|---|---|
| dkim=none | DKIM signing not enabled in Defender portal | Toggle on in portal after CNAME records publish |
| dkim=fail | CNAME records published but incorrect | Verify target values match Defender portal |
| spf=softfail | Using ~all instead of -all with unknown senders | Identify sender, add to record, switch to -all |
| dmarc=fail, reason=alignment | From domain not aligned with authenticated domain | Fix third-party sender to use domain-aligned DKIM |
| compauth=fail, reason=000 | Multiple authentication failures | Debug each protocol individually in order |
Six Common Microsoft 365 Authentication Mistakes
1. DKIM CNAMEs Published but Signing Not Enabled
Covered above but worth repeating. This is the single most common failure. External verification tools will show the CNAMEs are live, but Microsoft is not actually signing outgoing mail because the Defender portal toggle is off.
2. Using the Wrong SPF Include
Older documentation references outlook.com or mail.protection.outlook.com. The current correct include is spf.protection.outlook.com. Using legacy values may pass validators but produces inconsistent results.
3. Missing Rotation Selector
Publishing only selector1 but not selector2 breaks DKIM key rotation. Microsoft periodically rotates keys between the two selectors for security. If only one CNAME is published, rotation causes DKIM failures until the second is added.
4. DMARC at p=reject on New Configuration
Moving to p=reject without 30 to 60 days of monitoring breaks legitimate third-party senders (Mailchimp, Salesforce, HubSpot, support tools) that were not correctly configured for DKIM alignment. Always progress through p=none, then p=quarantine, then p=reject.
5. Hybrid Environments Forgetting On-Premises Exchange
Organizations running Microsoft 365 alongside on-premises Exchange Server often forget to include the on-premises sending IPs in SPF. Messages sent from the on-premises server appear to come from your domain but fail SPF because Microsoft SPF include does not cover them.
6. Ignoring the compauth Header
The Microsoft-specific compauth field provides more detail than standard SPF, DKIM, and DMARC results combined. Administrators who only check spf/dkim/dmarc miss nuances that compauth surfaces clearly. Always read the full authentication-results block.
The Defender portal submissions page (under Email and Collaboration, then Submissions) surfaces authentication failures reported by recipients. Check this weekly during any DMARC enforcement progression. Patterns in submissions often reveal specific legitimate senders that are failing alignment before the DMARC aggregate reports make the issue obvious.
Hybrid Exchange and Microsoft 365 Considerations
Organizations running Exchange Online (Microsoft 365) alongside on-premises Exchange Server need careful SPF configuration to authenticate mail from both sources:
v=spf1 include:spf.protection.outlook.com ip4:203.0.113.10 -allThe ip4: mechanism adds the on-premises Exchange sending IP. If you have multiple on-premises IPs, add each individually or use an ip4: range.
DKIM for hybrid environments is more complex. Mail that flows out through Microsoft 365 gets signed by Microsoft; mail that flows directly from on-premises Exchange does not unless you configure signing at the on-premises server (Exchange 2016 and later support this via transport agents or third-party plugins).
For organizations with significant on-premises volume, the cleanest architecture is to route all outbound mail through Microsoft 365 Exchange Online connectors, ensuring consistent DKIM signing regardless of where the message originated.
BIMI and Verified Mark Certificates for Microsoft 365
Once DMARC reaches p=quarantine or p=reject, you unlock eligibility for BIMI brand logo display in supporting receivers. Apple Mail and Yahoo both display BIMI logos; Gmail displays them with an added Verified Mark Certificate. Microsoft Outlook.com does not yet display BIMI logos, but Microsoft has signaled that BIMI support is on their roadmap.
The BIMI setup workflow for Microsoft 365 domains is identical to any other sender:
- Achieve DMARC at p=quarantine or p=reject (100% enforcement)
- Create an SVG Tiny Portable logo meeting the BIMI specification
- Publish a BIMI TXT record at default._bimi.yourdomain.com
- Optionally obtain a Verified Mark Certificate for the blue checkmark in Gmail
Microsoft documentation specifically recommends strict DMARC alignment (aspf=s; adkim=s) for domains where mail is sent from subdomains you do not control. This is more aggressive than the Google recommendation of relaxed alignment but provides stronger spoofing protection at the cost of potential legitimate-send disruption if a subdomain sender falls out of alignment.
Verifying Compliance With 2025 Microsoft Enforcement
For Microsoft 365 senders delivering to Outlook.com, Hotmail.com, and Live.com at volumes above 5,000 daily messages, compliance with the May 2025 requirements is essential. A complete compliance check:
- SPF published with include:spf.protection.outlook.com and -all
- DKIM CNAME records published AND signing enabled in Defender portal
- DMARC at minimum p=none with valid rua= reporting address
- List-Unsubscribe header and RFC 8058 List-Unsubscribe-Post header in all bulk messages
- Spam complaint rate monitored (Microsoft SNDS is the authoritative source)
- Valid PTR records on sending IPs (typically automatic for Microsoft 365 tenants)
Microsoft Smart Network Data Services (SNDS) is the Microsoft equivalent of Google Postmaster Tools and the authoritative source for how Microsoft sees your sending. Enrollment is free but requires your sending IPs to be under your direct control or explicitly delegated by your ESP.
Frequently Asked Questions
For Microsoft 365-only sending, the correct SPF record is v=spf1 include:spf.protection.outlook.com -all published as a TXT record at your domain root. For hybrid environments with on-premises Exchange, add the on-premises IP addresses with ip4: mechanisms. Additional third-party senders are added with their own include: references, watching the 10 DNS lookup limit.
Two steps are required. First, publish two CNAME records (selector1 and selector2) in your DNS pointing to the targets shown in the Microsoft Defender portal. Second, after DNS propagation, open the Defender portal, navigate to Email and Collaboration then Threat Policies then DKIM, select your domain, and toggle signatures to enabled. Publishing the CNAMEs without enabling signing is the most common setup mistake.
Yes, for domains sending 5,000 or more daily messages to Outlook.com, Hotmail.com, and Live.com under the enforcement that began May 2025. DMARC is also strongly recommended for Microsoft 365 tenant-to-tenant mail. The minimum acceptable policy is p=none, with progression to p=quarantine and eventually p=reject strongly recommended for full anti-spoofing protection.
Microsoft uses CNAME records pointing to their hosted DNS zone so they can rotate DKIM keys automatically without requiring customer DNS changes. When Microsoft rotates a key, the selector zone is updated in Microsoft infrastructure and the CNAME resolution produces the new key. This design simplifies key rotation but means the CNAME targets must match the exact values shown in the Defender portal for your specific tenant.
SPF pass indicates the sending IP is authorized by the SPF record. compauth pass is a Microsoft-specific composite authentication result that combines SPF, DKIM, and DMARC alignment into a single verdict. A compauth=pass with reason=100 means all three protocols aligned cleanly. compauth is more meaningful than any individual protocol result because it reflects how Microsoft filter stack actually evaluates the message.