Setup Guide

How to Set Up SPF, DKIM, and DMARC for Microsoft 365

Microsoft 365 (formerly Office 365) is one of the most widely used business email platforms. Configuring SPF, DKIM, and DMARC correctly ensures your emails are delivered reliably and protects your domain from being spoofed.

This guide covers the DNS records and configuration steps required for full email authentication with Microsoft 365.

SPF Configuration

Microsoft 365 uses a single SPF include that covers all of its sending infrastructure, including Exchange Online and Microsoft-hosted outbound mail servers.

DNS Record:

Type:  TXT
Host:  @
Value: v=spf1 include:spf.protection.outlook.com -all

If you have additional sending services, combine them into one record:

v=spf1 include:spf.protection.outlook.com include:sendgrid.net ~all

Microsoft recommends -all (hard fail) rather than ~all (soft fail) for domains exclusively using Microsoft 365. If you're still configuring other services, use ~all until everything is in place.

Note: spf.protection.outlook.com typically consumes 2–3 DNS lookups. Verify your total with the SenderClarity SPF Checker.

DKIM Configuration

Microsoft 365 supports DKIM signing through the Defender portal. Unlike Google Workspace, Microsoft uses two CNAME records instead of TXT records for DKIM.

  1. Sign in to the Microsoft Defender portal (security.microsoft.com).
  2. Navigate to Email & Collaboration → Policies & Rules → Threat policies → Email authentication settings → DKIM.
  3. Select your domain.
  4. Microsoft will display two CNAME records to add to your DNS:
Type:  CNAME
Host:  selector1._domainkey
Value: selector1-yourdomain-com._domainkey.yourdomain.onmicrosoft.com

Type:  CNAME
Host:  selector2._domainkey
Value: selector2-yourdomain-com._domainkey.yourdomain.onmicrosoft.com

The exact values will include your specific domain name. Copy them directly from the Defender portal.

  1. Add both CNAME records to your DNS.
  2. Return to the Defender portal and toggle DKIM signing to Enabled.

Microsoft uses two selectors for key rotation. When a key is rotated, traffic shifts to the other selector automatically.

DMARC Configuration

Start with monitoring mode:

Type:  TXT
Host:  _dmarc
Value: v=DMARC1; p=none; rua=mailto:your-address@reports.senderclarity.com; fo=1

Once you've confirmed all legitimate mail passes SPF and DKIM via your DMARC reports, move toward enforcement:

  1. p=quarantine; pct=25
  2. p=quarantine; pct=100
  3. p=reject

DMARC Considerations for Microsoft 365

  • SPF and DKIM both align natively: Microsoft 365 is one of the few platforms where both SPF and DKIM align with your domain out of the box (once DKIM is enabled in Defender). The return-path uses your domain, and DKIM signs with your domain. This dual alignment makes Microsoft 365 domains strong candidates for moving to p=reject relatively quickly.

  • Forwarding and shared mailboxes can cause DMARC failures: Exchange Online mail flow rules that forward or redirect email to external addresses will break SPF alignment at the destination. If you see unexpected DMARC failures from Microsoft IPs in your reports, investigate auto-forwarding rules — they're one of the most common sources of legitimate-but-failing traffic.

  • Third-party connectors introduce hidden senders: If you've configured connectors in Exchange Online for services like CRM platforms, helpdesks, or marketing tools that relay through Microsoft 365, those messages inherit Microsoft's SPF but may not have DKIM aligned to your domain. Check your DMARC reports for traffic volume that doesn't match your expected direct-send patterns.

Verification

After configuring all three records:

  • Check your SPF record →
  • Send a test email from Outlook and check the message headers for spf=pass, dkim=pass, dmarc=pass
  • Review DMARC aggregate reports in SenderClarity for any failing sources

Common Issues

DKIM toggle won't enable: The most common cause is DNS propagation delay. CNAME records can take up to 48 hours to propagate. If it still fails, double-check the CNAME host and value match exactly — even small typos (extra dots, wrong domain format) will prevent activation.

SPF failures from shared/delegated sending: If your organization uses Microsoft 365 shared mailboxes or Power Automate to send email, these should be covered by the standard SPF include. However, third-party connectors or relays may require additional SPF entries.

Emails from onmicrosoft.com subdomain: If users send from the default @yourdomain.onmicrosoft.com address instead of your custom domain, those messages won't align with your domain's DMARC policy. Ensure all users are configured to send from your custom domain.

SPF Lookup Impact

Include Estimated Lookups
spf.protection.outlook.com 2–3