SPF and DKIM by provider

SPF record for Microsoft 365

Last updated 2026-08-26

Microsoft 365 sends mail from Exchange Online mailboxes and anything else sending through your tenant. Here is what to publish so it can do that as your domain, and what has to line up before DMARC will pass.

The SPF record

Add one mechanism to the SPF record on your sending domain:

In a complete record, alongside Google Workspace, that looks like:

One include covers the whole service. It is a flat record of address blocks rather than a stack of nested includes, so it is cheap by the standards of this list, but check the live number with the checker rather than trusting a count you read somewhere.

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. SPF allows ten DNS-querying mechanisms across the entire nested chain, and the eleventh turns the record into a permerror that authorises nothing. The record still reads correctly to a human while every check fails. Run the domain through the SPF checker after every change, because the number moves when your providers change their own records, not just when you change yours.

DKIM

Microsoft 365 uses two CNAMEs, not TXT records, so that it can 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 and leave you failing. These are the Microsoft 365 specifics:

• Mail signed only with your onmicrosoft.com domain does not align with a custom From domain. Enabling DKIM per custom domain is the whole point of the exercise.
• 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 is almost always alignment, not SPF. Reading the header covers it.
• Every accepted domain in the tenant needs its own pair of CNAMEs and its own enable step.

The general case is covered in alignment, explained, and the header you read to prove it is on the dmarc=fail page.

Verify it

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. That single check is worth more than any number of DNS lookups, because it tests the thing receivers actually do.

Our SPF checker gives you the lookup count, the DKIM checker confirms a selector resolves and the key is long enough, and the DMARC checker reads your policy back to you. All three are free and none of them ask for an account.

Values here were checked against Microsoft 365's own documentation, at Microsoft Learn. Providers change DNS requirements without much announcement, so if their screen disagrees with this page, believe their screen and tell us.

A record can read correctly and still fail alignment once real mail moves through it. Receivers write that verdict into the reports they send. We read them for you, and paid plans email you the same day one names a new sender that failed, instead of holding it for Monday. See whether this sender passes. Your first domain is free.