SPF record for Microsoft 365

Microsoft 365 sends mail from Exchange Online mailboxes and anything else sending through your tenant. To send that mail as your domain and pass DMARC, publish the records below and check the alignment notes.

The SPF record

Add this include to the SPF record on your sending domain:

A complete record for a domain that also sends through Google Workspace:

This include covers the whole service. It's a flat list of address blocks with no nested includes, so it uses few of your lookups. Check the live count with the checker, because Microsoft can change the record without notice.

If your tenant sends through a third-party filtering gateway on the way out, the gateway's addresses are what receivers see, and they need to be in the record too.

Then count your lookups, because SPF allows ten DNS lookups across the whole chain of includes. A sender that receivers need an eleventh lookup to find gets a permerror and fails SPF, even though the record looks right when you read it. Run the domain through the SPF checker after every change. The count also moves when a provider changes its own records.

DKIM

Microsoft 365 publishes DKIM through two CNAME records, which lets it rotate keys without you:

Replace contoso with your tenant's initial domain and note the shape of the target: your domain with the dots turned into hyphens. Publish both, then enable signing for the domain in the Defender portal under Email and collaboration, Policies and rules, Threat policies, Email authentication settings.

DMARC alignment with Microsoft 365

DMARC passes when SPF or DKIM passes and the domain it authenticated matches the domain in your visible From address. A provider can pass both checks for its own domain while your mail fails DMARC.

• Mail signed only with your onmicrosoft.com domain does not align with a custom From domain. Enable DKIM for each custom domain so the signature carries that domain.
• Direct send and connectors from on-premises devices, scanners and line-of-business apps skip the signing path. They are the usual source of a 550 5.7.515 against your own domain.
• Microsoft adds its own compauth= verdict alongside the standard Authentication-Results line. A compauth=fail with SPF passing usually means an alignment problem, and the SPF record itself is fine. The dmarc=fail page shows how to read that header.
• Every accepted domain in the tenant needs its own pair of CNAMEs and its own enable step.

The DMARC alignment guide covers the general case, and the dmarc=fail page shows how to read the Authentication-Results header.

Verification

Substitute your domain, and run these after the TTL on anything you replaced has expired:

Then send one message through Microsoft 365 to a Gmail address you control, open Show original, and look for dkim=pass with your domain in header.i. A test message shows what a receiver does with your mail. A DNS lookup only shows what you published.

Our SPF checker gives you the lookup count. The DKIM checker shows whether a selector resolves and whether the key is long enough, and the DMARC checker reads your policy back to you. You can use them free, without an account.

I checked the values here against Microsoft 365's own documentation, at Microsoft Learn. Providers change their DNS requirements without much notice. If their screen shows something different from this page, follow their screen and tell us.

A record can be correct and still fail alignment once real mail goes through it. Receivers record that result in the reports they send. We read the reports for you, and on a paid plan we email you the day a new sender fails. See whether this sender passes. Your first domain is free.