At AutoSPF, our mission is simple: help organizations optimize email deliverability and security with the right sender authentication setup. In this comprehensive guide, we’ll walk you through step-by-step how to configure SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) for your Microsoft 365 environment.
Whether you’re new to SPF/DKIM, a seasoned admin, or somewhere in between, this post will give you both why and how — not just checklists — so you can confidently strengthen your email authentication posture and reduce fraud, spoofing, and spam.
Why SPF & DKIM Matter for Microsoft 365
Before jumping into configuration steps, let’s make sure we understand what SPF and DKIM do — and why they’re critical for Microsoft 365 mail.
SPF: Telling the World Who Can Send for Your Domain
SPF is a DNS TXT record that lists all mail servers authorized to send email on behalf of your domain. When a receiving email system checks SPF, it verifies that the sending server’s IP or domain is included in your SPF record.
- If the sending IP is listed, SPF passes.
- If not, SPF fails — and the receiving server may reject or flag the email as spam.
Without SPF properly set up, your legitimate Microsoft 365 messages might fail authentication checks and get blocked or spam-filtered — hurting deliverability and brand trust.
DKIM: Cryptographic Signing for Message Integrity
DKIM works differently. Instead of a TXT record listing senders, DKIM uses public key cryptography to cryptographically sign emails.
- Microsoft 365 generates private keys used by its mail servers.
- You publish corresponding public keys in DNS as CNAME records.
- Receiving servers check the DKIM signature against your public key.
If the signature matches, the message is verified as authentic and hasn’t been tampered with in transit. This is especially important for defending against sophisticated phishing and domain spoofing.
When both SPF and DKIM are properly in place, Microsoft 365 mail has a much stronger standing in modern authentication flows like DMARC — significantly improving deliverability and trust.
Part 1: Configuring SPF for Microsoft 365
Step 1 — Understand Your Domain’s Email Sources
The first thing you must do before making changes is inventory all email sources that send mail using your domain:
✔ Microsoft 365
✔ CRM tools
✔ Marketing automation platforms
✔ Transactional email services
✔ Legacy mail systems
Every service that sends email on your domain’s behalf must be included in your SPF record — otherwise, SPF checks can fail.
Step 2 — Build a Correct SPF Record
A basic SPF record for Microsoft 365 includes the Outlook protection servers:
v=spf1 include:spf.protection.outlook.com ~allLet’s break this down:
- v=spf1 — SPF versio
- include:spf.protection.outlook.com — authorizes Microsoft 365 mail
- ~all — soft fail for other sources not listed
Use ~all (soft fail) during rollout to avoid legitimate mail being rejected while you verify everything. Once you’re confident everything is covered, you can change to -all (hard fail).
Step 3 — Add All Other Mail Services
If other platforms send mail on behalf of your domain, they must be included in the same SPF TXT record — do not create multiple SPF records or SPF lookups will fail (resulting in a PermError).
A combined SPF record might look like:
v=spf1 include:spf.protection.outlook.com include:mailgun.org include:sendgrid.net ~all💡 Tip: Keep your SPF record under the DNS lookup limit (10 includes) to avoid failures.
Step 4 — Publish the SPF Record in DNS
- Go to your DNS provider dashboard.
- Create or edit a TXT record for the domain with:
- Name/Host = @ (or blank based on provider)
- Value = your SPF string
- Save and wait for propagation (most DNS updates complete within a few hours, though 48 hours is typical).
Step 5 — Monitor and Validate SPF
You can test your SPF record using tools like AutoSPF’s SPF Validator, MXToolbox, or DNS reporting tools to confirm it passes checks and includes all expected senders.
Part 2: Configuring DKIM for Microsoft 365
Step 1 — Access the Microsoft 365 DKIM Page
- Sign in to your Microsoft 365 Admin or Microsoft Defender portal.
- Search for “DKIM” or go directly to the DKIM configuration page.
From here, Microsoft will show you a Prepare DKIM interface where you can enable DKIM for your domains and generate DNS records.
Step 2 — Enable DKIM and Retrieve CNAMEs
When you click to Enable DKIM, Microsoft 365 will generate two selector records.
These look like:
selector1._domainkey.yourdomain.com
selector2._domainkey.yourdomain.com
And they point to corresponding Microsoft 365 hosted DKIM endpoints, unique to your tenant.
Step 3 — Add DKIM CNAME Records to DNS
In your DNS provider:
- Add a CNAME record:
- Host: selector1._domainkey
- Points to: selector1-yourdomain-dkim-value provided by Microsoft
- Add a second CNAME for selector2:
- Host: selector2._domainkey
- Points to: selector2-yourdomain-dkim-value provided by Microsoft
These CNAME entries allow Microsoft to serve your DKIM public keys from their infrastructure.
Step 4 — Enable Signing in Microsoft 365
After adding and saving both CNAME records:
- Return to the Microsoft Defender DKIM dashboard.
- Click Enable again.
- If DNS has propagated and both records resolve correctly, DKIM will activate successfully.
You should see active status (often with a green check) for both selectors.
Troubleshooting DKIM Issues
✔ DNS records not resolving?
- DNS propagation may still be in progress (up to 48 hours).
✔ DKIM still not active after time?
- Verify there are no typos in the CNAME host or target records.
✔ Emails without DKIM signatures?
- DKIM signing must be toggled on in Microsoft Defender — not just published in DNS.
Optional: DMARC for Full Protection (Recommended)
While the focus here is SPF & DKIM, DMARC ties them together and tells receiving servers what to do if a message fails your SPF/DKIM checks.
A basic DMARC TXT record looks like:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comStart with p=none so you can monitor failures before enforcing stricter policies. Once you confirm everything is working, you can move to quarantine or reject.
Common Microsoft 365 SPF Mistakes We See at AutoSPF
Even organizations that believe they’ve “set SPF correctly” often run into hidden issues. At AutoSPF, we routinely audit Microsoft 365 domains and uncover problems that quietly damage deliverability.
1. Multiple SPF Records (The Silent Killer)
One of the most common SPF misconfigurations is publishing more than one SPF TXT record for the same domain. DNS will allow it — but SPF validation will not.
When a receiving server sees multiple SPF records, it returns a PermError, which is treated as a failure. This can cause legitimate Microsoft 365 messages to land in spam or be rejected outright.
✔ Always consolidate all sending services into a single SPF record
✔ Never publish separate SPF records for different tools
AutoSPF strongly recommends auditing DNS regularly to ensure only one SPF record exists.
2. Exceeding the SPF 10-Lookup Limit
SPF has a strict limit of 10 DNS lookups during evaluation. Each include, a, mx, or redirect mechanism can count toward this total.
Microsoft 365’s include alone consumes multiple lookups. Add a few marketing platforms, CRMs, or transactional services — and suddenly SPF breaks.
When the lookup limit is exceeded:
- SPF returns a PermError
- Authentication fails
- DMARC alignment can fail too
This is where SPF flattening or automation becomes critical for scaling email programs without breaking deliverability.
3. Using -all Too Early
While -all (hard fail) is best practice long-term, using it too early can block legitimate email.
If you’re still:
- Adding new tools
- Unsure of all senders
- Migrating to Microsoft 365
Start with ~all, monitor authentication results, and only move to -all once you’re confident everything is authorized.
