Microsoft's cloud-based email and office productivity platform. This guide covers the complete email authentication stack for Microsoft 365: SPF, DKIM, and DMARC. Each section gives you the exact DNS records, step-by-step instructions, common pitfalls, and how to verify your setup.
Add the correct SPF record to authorize Microsoft 365 (Exchange Online) to send email on behalf of your domain.
TXT
@
v=spf1 include:spf.protection.outlook.com ~all
This is the standard include for all Microsoft 365 / Exchange Online tenants.
Log in to the DNS management portal for your domain (e.g., GoDaddy, Cloudflare, Namecheap, or Microsoft if they manage your DNS).
Look for a TXT record starting with v=spf1. You must have only one SPF record per domain.
dig TXT yourdomain.com +short | grep spfAdd a new TXT record (or modify the existing one) with host @ and the value below.
v=spf1 include:spf.protection.outlook.com ~allDNS changes can take up to 48 hours to propagate, though most providers update within minutes.
Go to the Microsoft 365 Admin Center > Settings > Domains > select your domain > DNS records. Microsoft will check your SPF record and show a green checkmark when valid.
v=spf1 ~allv=spf1 include:spf.protection.outlook.com ~allYou need a TXT record at @ with the value v=spf1 include:spf.protection.outlook.com ~all. This authorizes Exchange Online servers to send email for your domain.
If you run a hybrid Exchange deployment, you need both the Microsoft 365 include and your on-premises server IPs: v=spf1 include:spf.protection.outlook.com ip4:YOUR.SERVER.IP ~all.
Use include:spf.protection.outlook.com for SPF records. The hostname protection.outlook.com (without the spf. prefix) is used for MX records, not SPF.
Enable DKIM signing in Microsoft 365 Defender and publish CNAME records to allow Microsoft to sign outgoing email with your domain.
CNAME
selector1._domainkey
selector1-yourdomain-com._domainkey.yourtenant.onmicrosoft.com
You need two CNAME records: selector1._domainkey and selector2._domainkey. Replace yourdomain-com and yourtenant with your actual values.
Go to security.microsoft.com and sign in with your admin account. Navigate to Email & collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM.
Click on your custom domain in the DKIM page. Microsoft will display the two CNAME records you need to publish.
Create two CNAME records in your DNS provider with the host names and values shown by Microsoft.
selector1._domainkey CNAME selector1-yourdomain-com._domainkey.yourtenant.onmicrosoft.com
selector2._domainkey CNAME selector2-yourdomain-com._domainkey.yourtenant.onmicrosoft.comReturn to the Microsoft 365 Defender DKIM page and toggle the "Sign messages for this domain with DKIM signatures" switch to Enabled.
Send a test email and check the headers. Look for DKIM-Signature with d=yourdomain.com and a pass result in Authentication-Results.
Microsoft 365 uses selector1 and selector2 as DKIM selectors. Both are published as CNAME records pointing to Microsoft-managed keys under your tenant's onmicrosoft.com domain.
Yes. Because the DKIM records are CNAMEs pointing to Microsoft-managed DNS, Microsoft can rotate the underlying keys without requiring you to update your DNS records.
CNAME records allow Microsoft to manage and rotate the DKIM keys on their side without requiring customers to update DNS records each time a key rotation occurs.
Publish a DMARC policy to protect your Microsoft 365 domain from spoofing and phishing by instructing receivers how to handle unauthenticated email.
TXT
_dmarc
v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1
Start with p=none to monitor before enforcing. Ensure SPF and DKIM pass first.
DMARC requires at least one of SPF or DKIM to pass and align. Verify both are set up for your Microsoft 365 domain.
Choose a mailbox or DMARC reporting service to receive aggregate (rua) and forensic (ruf) reports.
Add a TXT record in your DNS with host _dmarc and your policy value.
v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1Monitor aggregate reports for 2-4 weeks. Ensure all legitimate senders (marketing platforms, CRM, etc.) pass SPF or DKIM with domain alignment.
Gradually tighten the policy: p=quarantine with pct=25, then pct=50, pct=100, and finally p=reject.
v=DMARC1; p=reject; rua=mailto:[email protected]; fo=1(no DMARC record)v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1Yes. SPF and DKIM authenticate email, but DMARC tells receiving servers what to do when authentication fails. Without DMARC, receivers make their own decisions about unauthenticated mail.
Yes. Microsoft 365 (Exchange Online Protection) sends DMARC aggregate reports to domains that have a rua tag in their DMARC record.
The recommended final policy is p=reject, which instructs receivers to reject any email that fails DMARC authentication. Only move to reject after confirming all legitimate senders pass.
Once your SPF, DKIM, and DMARC records are in place, run a full domain scan to confirm everything is configured correctly. DNS changes typically propagate within minutes but can take up to 48 hours.