How to set up SPF, DKIM, and DMARC for Microsoft 365?

Setting up SPF, DKIM, and DMARC correctly for Microsoft 365 (formerly Office 365) is the single highest-leverage thing you can do to protect your domain's email deliverability. Microsoft's documentation is extensive but scattered, and there are a few non-obvious steps that trip up most admins. This guide gives you a linear, known-good setup for the 2026 Microsoft 365 tenant model.

Prerequisites

• You have admin access to the Microsoft 365 admin center.
• You control DNS for the domain (Cloudflare, Route 53, GoDaddy, whatever).
• You have already added the domain to your tenant and completed the MX and Autodiscover records.

If your domain is still on the *.onmicrosoft.com default, you cannot configure custom DKIM — add the custom domain first.

Step 1: SPF

Microsoft 365's SPF include is spf.protection.outlook.com. This single include covers all Exchange Online mail flow, including Safe Links and ATP. Your SPF record at the apex:

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

If you send from other services as well, include them too. But watch the 10-lookup limit. spf.protection.outlook.com currently chains 3 lookups, so you have 7 left for other senders.

A common mistake is keeping a legacy include like include:outlook.com or include:mail.protection.outlook.com. These are either redundant or invalid — only spf.protection.outlook.com is supported today.

Use ~all (softfail) during initial rollout. Move to -all (hardfail) after a few weeks if reports are clean.

Step 2: DKIM

Microsoft 365 uses two selectors: selector1 and selector2. They are CNAMEs to targets inside your tenant's onmicrosoft.com domain. The exact targets depend on your tenant name and the organizational domain.

For a tenant named "contoso" with a verified domain example.com:

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

Note the hyphen convention: dots in the domain become hyphens in the CNAME target (example.com → example-com).

To get the exact values for your tenant:

1. Go to security.microsoft.com.
2. Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM.
3. Select your domain. Microsoft shows the exact CNAME values.
4. Publish both CNAMEs in DNS.
5. Return to the DKIM page and toggle Sign messages for this domain with DKIM signatures to On.

If you toggle on before the CNAMEs resolve, the toggle fails with an error. Wait for DNS to propagate (usually minutes on Cloudflare/Route 53; up to 24 hours on slower providers).

Key length: Microsoft defaults to 1024-bit. In 2026 this is still accepted everywhere, but 2048-bit is recommended. You can rotate to 2048-bit in the same page — Microsoft rotates the keys and publishes new CNAME targets for you to update. This is a one-time change per domain.

Step 3: DMARC

Once SPF and DKIM are verified as passing (check headers on a sent message), publish DMARC.

Starting policy:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1; adkim=r; aspf=r; pct=100"

Leave this on p=none for at least 14 days. Collect the daily aggregate reports. Identify every source of mail for your domain that is failing alignment — typical culprits:

• A marketing platform (Mailchimp, HubSpot, Marketo) that is not yet domain-aligned.
• A transactional sender (SendGrid, Postmark) signing with its own domain.
• Internal devices (printers, scanners, SaaS notifications) that use SMTP with no DKIM.

Fix each one. Then progress to p=quarantine; pct=10, then 50, then 100. Then p=reject; pct=25, up to 100.

Step 4: Enhanced filtering for DMARC

Microsoft 365 has a per-recipient "Honor DMARC policy" setting. It is enabled by default for new tenants, but older tenants sometimes still have it disabled, causing p=reject mail to land in Junk instead of being rejected.

security.microsoft.com → Threat policies → Anti-phishing → Default policy → Edit action. Ensure "Honor DMARC record policy when the message is detected as spoof" is set to Quarantine the message for p=quarantine and Reject the message for p=reject.

Step 5: MTA-STS and TLS-RPT (optional but recommended)

MTA-STS and TLS-RPT are separate standards that improve inbound transport security. Microsoft 365 supports both.

_mta-sts.example.com. IN TXT "v=STSv1; id=20260101"
mta-sts.example.com. IN A 203.0.113.10   # or CNAME to a hosting endpoint

Plus the policy file at https://mta-sts.example.com/.well-known/mta-sts.txt:

version: STSv1
mode: enforce
mx: *.mail.protection.outlook.com
max_age: 86400

TLS-RPT:

_smtp._tls.example.com. IN TXT "v=TLSRPTv1; rua=mailto:[email protected]"

Step 6: Safe attachments / Safe Links

Not authentication-related, but often misconfigured alongside SPF/DKIM/DMARC. Ensure Safe Attachments and Safe Links policies are applied to the domain so that incoming mail is scanned and outbound URL rewriting is consistent with your DKIM.

Common gotchas

DKIM signs, but DMARC fails. Check the d= tag in the DKIM signature on an outbound message. It should be example.com, not contoso.onmicrosoft.com. If it is the onmicrosoft.com, you enabled DKIM on the wrong domain.

SPF passes, but alignment fails. This happens when you forward mail through a shared relay. Solution: use DKIM, which is alignment-friendly.

Autodiscover records conflict with custom SPF. The old _autodiscover._tcp SRV and its CNAME are not SPF-relevant, but some admins add an SPF include for autodiscover.outlook.com by accident. That include does not exist and will cause PermError.

Mail flow connectors override DKIM. If you have a connector sending through a smart host (e.g., a third-party archiving gateway), the smart host may re-sign the mail with its own DKIM and break alignment. Confirm the connector is not modifying headers.

SMTP Auth disabled on mailboxes. Not an SPF/DKIM issue but causes confusion. Modern Microsoft 365 disables legacy SMTP AUTH by default. Devices using SMTP AUTH (printers, scanners, custom apps) need to use the smtp.office365.com endpoint with OAuth 2.0 or a dedicated authenticated SMTP relay.

Testing

Send a test message to an external mailbox you control (Gmail works well). View the full headers and look for:

• Received-SPF: pass with spf.protection.outlook.com as the permitted sender.
• Authentication-Results: ... spf=pass ... dkim=pass ... dmarc=pass.
• A DKIM-Signature header with d=example.com and s=selector1 or s=selector2.

All three should pass. If any shows neutral, fail, or none, revisit the corresponding step.

Subdomain policy

Add sp=reject to your DMARC once the root is clean. Subdomains without their own SPF/DKIM will inherit the reject policy, which blocks spoofing of billing.example.com and similar.

If you use Microsoft 365 on a subdomain (e.g., mail.example.com for all mail), apply the same SPF/DKIM/DMARC setup on the subdomain and align the DMARC policy accordingly.

When to use IntoDNS.ai

IntoDNS.ai runs the full Microsoft 365 email authentication check in seconds: SPF record validity and lookup count, both DKIM selectors (selector1 and selector2) with proper CNAME resolution, DMARC policy and alignment, MTA-STS and TLS-RPT records. If any piece is missing or misconfigured, it shows you the specific DNS change to make. For ongoing monitoring across multiple tenant domains, IntoDNS.ai gives you a single view of which ones are clean and which need attention.

DKIM rotation in Microsoft 365

Microsoft 365 supports dual keys (selector1 and selector2). When you rotate, Microsoft generates a new key for the currently-inactive selector and publishes the new CNAME target. The UI shows a "Rotate DKIM key" button:

1. Click Rotate. Microsoft generates the new key.
2. The DKIM page shows a warning that a new CNAME target exists.
3. Update the CNAME in your DNS.
4. Return to the page; Microsoft verifies the update and switches signing over.
5. After the rotation window, the old key is disabled.

Best practice: rotate every 6 months. Automate nothing here — the CNAME change is one-time per rotation and needs human verification.

Setting up a dedicated outbound IP (Exchange Online Protection)

By default, Microsoft 365 uses a shared IP pool for outbound. Your mail mingles with every other tenant's — reputation is shared. For high-volume senders, Microsoft offers High Volume Email and, historically, dedicated outbound IPs through the Exchange Online High Volume connector or a third-party smart host.

If you do not qualify for dedicated IPs:

• Your SPF must cover every possible outbound IP in the shared pool. This is what spf.protection.outlook.com does.
• Rely heavily on DKIM for DMARC alignment, since SPF alignment can be affected by outbound-pool quirks.
• Monitor Microsoft's SNDS service for IP-level reputation signals.

Troubleshooting checklist

"DKIM is enabled in the admin center but messages do not have a signature." The toggle has been on for less than an hour. Wait. Microsoft propagates the enable signal across regions slowly.

"DKIM toggle refuses to flip." The CNAMEs have not resolved. Verify:

dig +short CNAME selector1._domainkey.example.com
dig +short CNAME selector2._domainkey.example.com

Both should return selector{1,2}-example-com._domainkey.contoso.onmicrosoft.com (with your tenant name).

"Messages pass DMARC for most receivers but fail for Google." Google is strict about alignment. Check that the From header uses your verified domain exactly, not a variant like example.co.

"From: address displayed as [email protected] (on behalf of contoso.onmicrosoft.com) in Outlook." This happens when Exchange rewrites the From for specific connectors. Check Mail Flow → Connectors for any transform rules.

Compliance considerations

In regulated industries (banking, healthcare, government) Microsoft 365's default setup may not meet full compliance. Additional requirements:

• Journaling for archival (separate from authentication).
• Third-party archive connectors that preserve DKIM signatures.
• DLP policies that do not strip authentication headers.
• S/MIME or Microsoft Purview Message Encryption for content confidentiality — separate from SPF/DKIM/DMARC.

None of these replace authentication; they supplement it.