Microsoft 365 SPF, DKIM, and DMARC Setup
A practical guide to setting up SPF, DKIM, and DMARC for Microsoft 365, including the DNS records to publish and the checks to run after setup.
Tools For This Topic
What a good Microsoft 365 mail setup should achieve
For Microsoft 365, a strong mail setup usually means Exchange Online is receiving mail where expected, Microsoft 365 is authorised in SPF, outbound mail is signed with DKIM, and DMARC is published so failures can be monitored and eventually enforced.
The goal is not only to make mail flow work, but to make authentication and reporting trustworthy enough to support deliverability and anti-spoofing.
Set up SPF for Microsoft 365
A common SPF starting point for a Microsoft 365-only sending environment uses include:spf.protection.outlook.com. If other platforms also send mail for the domain, they must be included carefully in the same single SPF policy.
v=spf1 include:spf.protection.outlook.com -allIf multiple SPF records exist, SPF can fail with PermError. This is especially common after migrations when old providers were never fully removed.
Set up DKIM for Microsoft 365
Microsoft 365 typically uses two DKIM selector CNAMEs that point back into the tenant's onmicrosoft.com namespace. After those records are published, DKIM signing still needs to be enabled in Microsoft 365.
selector1._domainkey.example.com CNAME selector1-example-com._domainkey.yourtenant.onmicrosoft.com
selector2._domainkey.example.com CNAME selector2-example-com._domainkey.yourtenant.onmicrosoft.comA common failure pattern is that the CNAMEs are live in DNS but DKIM signing was never switched on in the tenant.
Set up DMARC after authentication is stable
Once SPF and DKIM are behaving as expected, publish a DMARC record so receivers can evaluate alignment and send reports. A monitoring policy is usually the safest place to begin.
_dmarc.example.com TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"Only move toward quarantine or reject after legitimate Microsoft 365 and third-party senders are consistently aligned.
Watch for mixed-provider and gateway setups
Many Microsoft 365 environments also use inbound filtering or outbound marketing tools. That can leave MX, SPF, and DKIM looking more complicated than a simple Microsoft-only deployment.
If the domain uses gateways such as Mimecast or Proofpoint, or if other services send mail using the same visible domain, the provider design needs to be reflected in authentication and alignment.
What to verify after setup
- The MX record matches the intended Microsoft 365 tenant pattern
- The SPF policy authorises Microsoft 365 and only one SPF record exists
- The DKIM selectors resolve correctly and signing is enabled
- The DMARC record is valid and reporting is intentional
- A real test message shows the expected Authentication-Results
A practical Microsoft 365 workflow
- Confirm the intended Microsoft 365 MX and autodiscover setup
- Publish one valid SPF policy
- Publish the Microsoft 365 DKIM selector CNAMEs
- Enable DKIM signing in the tenant
- Publish a DMARC record starting with monitoring
- Send a real test message and inspect the resulting headers
Use These DNS Pro Tools
If you want to validate this topic in practice, these DNS Pro tools are the fastest next step.
Related Tools
Related Articles
Google Workspace SPF, DKIM, and DMARC Setup
A practical guide to setting up SPF, DKIM, and DMARC for Google Workspace, including what to publish in DNS and what to verify after setup.
How to Check Microsoft 365 DNS
A practical guide to checking Microsoft 365 DNS records, including MX, autodiscover, SPF, DKIM, DMARC, and the signs of an incomplete migration.
DNS Records Required for Microsoft 365 (Complete Setup Guide)
Complete guide to Microsoft 365 DNS records including MX, SPF, CNAME, DKIM, and DMARC. Includes real record examples and migration best practices.