All guides

Set up SPF, DKIM and DMARC for Microsoft 365

Last reviewed 2026-10-21 · Based on the official references linked below

For a business domain on commercial worldwide Microsoft 365, the setup has three parts: one reviewed SPF record, two DKIM aliases followed by signing activation, and a DMARC policy with reports.

SPF lists authorized senders. DKIM signs outgoing mail. DMARC connects those checks to the domain in your visible From address. Authentication does not promise inbox placement.

1. Prepare your domain and sender list

Your custom business domain must already be added to Microsoft 365. You need an authorized Microsoft 365 administrator and someone who can edit the domain's authoritative DNS records. The DNS host may differ from your registrar or website host. Keep all account credentials and verification codes private.

• List staff mail, billing tools, newsletters, website forms and any other service sending as your domain. Include infrequent senders.
• Save an export of your existing DNS records, full values and TTLs (cache times), plus any relevant admin settings, before changing them.
• Keep working DKIM configurations and existing DMARC enforcement. Do not replace a working quarantine or reject policy with monitoring mode just to match this guide.

2. Review SPF in DNS

Find the TXT record beginning v=spf1 at your DNS host. Microsoft 365 enrollment may already have set it up. Edit the existing policy after checking your senders; do not publish a second SPF record for the same domain.

If commercial worldwide Microsoft 365 is your only sender, the documented SPF value is:

v=spf1 include:spf.protection.outlook.com -all

Publish as type TXT at the domain root, often shown as @ (blank at Wix). This example does not cover extra sending services, hybrid mail routes, or government and China cloud variants. Use the matching provider instructions for those setups.

Reconcile every legitimate sender before changing the policy. Check the ten-DNS-lookup limit, including nested lookups. Preserve unrelated TXT records, MX records and website settings.

Reference: Microsoft's SPF setup instructions.

3. Copy both DKIM CNAMEs and enable signing

1. Open the DKIM page in Microsoft Defender. The menu route is Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM. Find your custom domain.
2. For a new domain showing NoDKIMKeys, try moving the toggle to Enabled. Microsoft's documented flow shows a Client error with DNS instructions. Select OK; the status becomes CnameMissing and signing stays disabled. If it already says CnameMissing, continue below.
3. Open the domain row outside its checkbox or toggle. Under Publish CNAMEs, copy both generated targets. Note Last checked.
4. At your DNS host, create two CNAME records: selector1._domainkey pointing to the first copied target, and selector2._domainkey pointing to the second. Use CNAME, not TXT. Confirm the full saved names include your domain only once.
5. Wait for Microsoft to detect the records, then return to the domain details and turn on Sign messages for this domain with DKIM signatures. Acknowledge the synchronization dialog.
6. Confirm the toggle is Enabled, the status says Signing DKIM signatures for this domain, and Last checked is newer.

Copy the targets exactly; do not build them from an example tenant name. Newer targets can use dkim.mail.microsoft; older ones can use onmicrosoft.com. Publish both selectors so key rotation is supported. CNAME targets are hostnames, without https:// or a path.

If your DNS is at Cloudflare, use DNS only for these CNAMEs and turn off CNAME flattening for them. If the domain is absent or you cannot open the page, resolve domain setup or admin access before continuing. Preserve any error rather than guessing targets.

Reference: Microsoft's DKIM setup instructions.

4. Start DMARC reporting

If the domain is new to DMARC, start with monitoring while you verify your senders. First prepare a dedicated mailbox or reporting service that can receive the reports. Replace the example address below with your actual destination before publishing.

v=DMARC1; p=none; rua=mailto:[email protected]

Publish as a TXT record named _dmarc in the sending domain's DNS zone. Review any existing DMARC record and preserve its report destinations. For a subdomain inside a parent zone, include the subdomain in the name, such as _dmarc.mail for mail.example.com.

p=none does not request blocking. rua requests aggregate reports from participating receivers. If the report address belongs to another domain, its operator must authorize the reports in that destination domain's DNS. Verify actual report receipt; a published policy alone is insufficient.

References: Microsoft's DMARC setup reference and Google's explanation of DMARC reports and external destinations. The reporting requirement applies to the destination domain. See when to move beyond p=none.

5. Verify with an external message

Send a direct test from the Microsoft 365 account to an unrelated external mail system. An internal tenant-to-tenant message is insufficient for this check. In the received message's headers, inspect the trusted receiving system's Authentication-Results for spf=pass, dkim=pass and dmarc=pass.

Check that the DKIM signing domain aligns with your visible From domain, and that the message's actual selector (the s= value) resolves. Also check SPF's return-path domain alignment. DMARC can pass through either aligned SPF or aligned DKIM; a raw pass for an unrelated domain is insufficient.

Test each additional legitimate sending service and review aggregate reports before tightening DMARC. The free checker provides a first look at public SPF and DMARC records; it does not test DKIM, sender alignment or nested SPF lookups.