How to set up SPF, DKIM and DMARC for Microsoft 365

Setting up email authentication for Microsoft 365 means publishing three DNS records: an SPF record containing include:spf.protection.outlook.com, two CNAME records that point your DKIM selectors at Microsoft's keys (then enabling signing in the Defender portal), and a DMARC TXT record you write yourself. Microsoft configures none of this fully on your behalf, so each step needs deliberate action.

What does Microsoft 365 configure by default?

Less than most administrators assume. When you add a custom domain to your tenant, the admin centre asks you to publish an SPF record, but it cannot publish it for you unless your DNS is delegated to Microsoft. DKIM signing for your custom domain is not enabled until you create the CNAME records and switch it on. DMARC is never configured automatically.

Out of the box, mail from your custom domain is DKIM-signed with your tenant's default onmicrosoft.com domain rather than your own. That signature is cryptographically valid, but because the signing domain does not match your From address, it does nothing for DMARC. Understanding why requires a quick grasp of DMARC alignment: DMARC only counts an SPF or DKIM pass when the domain that passed matches the domain in the visible From header.

The practical consequence: a fresh Microsoft 365 tenant with the standard SPF record can pass DMARC via SPF alignment, but has no aligned DKIM at all. One forwarding hop, which usually breaks SPF, and your mail fails DMARC outright. Enabling DKIM properly is not optional.

How do I set up SPF for Microsoft 365?

Sender Policy Framework (SPF) lists the servers allowed to send mail using your domain in the envelope sender (the Return-Path), as defined in RFC 7208. For a domain that sends only through Microsoft 365, the record is short:

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

Publish it as a TXT record at the root of your domain in your DNS provider's control panel. A few rules to observe:

• Publish exactly one SPF record per domain. If a record already exists (for a marketing platform, say), merge the mechanisms into a single record rather than adding a second one, because multiple SPF records produce a permanent error.
• The Microsoft include counts against the ten DNS lookup limit, currently resolving to a small number of nested lookups. If your record carries several other includes, check the total before you hit the limit.
• Use -all (fail) rather than ~all (softfail) once you are confident the record lists every legitimate source. Microsoft's own guidance accepts either; DMARC treats both the same for alignment purposes.

Remember what SPF actually checks: the envelope sender, not the From header your users see. Mail sent through Microsoft 365 uses your domain in both places for ordinary messages, so SPF normally aligns. But automatic forwarding, distribution list expansion to external recipients, and some connector configurations rewrite the envelope sender, which is why SPF alone is fragile and DKIM matters so much.

How do I enable DKIM for Microsoft 365?

DomainKeys Identified Mail (DKIM, RFC 6376) attaches a cryptographic signature to each outbound message. Microsoft hosts the keys; you publish two CNAME records that point standard selector names at Microsoft's key records, then enable signing.

Step 1: create the two CNAME records

Microsoft uses two selectors, selector1 and selector2, so it can rotate keys without you touching DNS again. The records follow a fixed pattern. For a domain example.co.uk in a tenant whose initial domain is contoso.onmicrosoft.com, they look like this:

selector1._domainkey.example.co.uk
  CNAME selector1-example-co-uk._domainkey.contoso.onmicrosoft.com

selector2._domainkey.example.co.uk
  CNAME selector2-example-co-uk._domainkey.contoso.onmicrosoft.com

Note how the dots in your domain become hyphens in the target hostname. Do not guess the targets: the Defender portal (under the email authentication settings for the domain) displays the exact values for your tenant, and copying them from there avoids typos. If you are unfamiliar with how selectors let one domain hold several keys at once, what a DKIM selector is covers the mechanism.

Step 2: enable signing

Once the CNAMEs have propagated, enable DKIM signing for the domain in the Microsoft Defender portal, or with Exchange Online PowerShell (New-DkimSigningConfig and Set-DkimSigningConfig -Enabled $true). If the portal reports that it cannot find the records, wait for DNS propagation and retry; the check is strict and a missing trailing label or a proxied CNAME will fail it.

Microsoft signs with 2048-bit RSA keys for new configurations. Older tenants may still be on 1024-bit keys, which you can upgrade by rotating: because both selectors exist, Microsoft publishes the new key under the inactive selector, switches signing over, and the old selector ages out. You trigger this from the portal or with Rotate-DkimSigningConfig, and it needs no DNS changes on your side.

Step 3: verify the signature

Send a message to an external mailbox (a personal account works) and inspect the headers. You want to see dkim=pass in the Authentication-Results header with header.d= set to your custom domain, not the onmicrosoft.com domain. That d= value is what DMARC aligns against.

What about the onmicrosoft.com domain?

Every tenant has an initial domain like contoso.onmicrosoft.com, sometimes called the MOERA (Microsoft Online Email Routing Address) domain. It deserves attention for three reasons.

First, until you enable DKIM for your custom domains, all outbound mail is signed as the onmicrosoft.com domain. Those signatures verify but never align with your From address, so DMARC reports will show DKIM passing with the wrong domain. This is the single most common source of confusion when teams first read their reports.

Second, some services and scripts genuinely send From the onmicrosoft.com address, and users can too if a mailbox has it as a proxy address. Microsoft has progressively tightened what unauthenticated or bulk mail the MOERA domain may emit, and its own DNS for that domain is managed by Microsoft, not you. You cannot publish your own SPF or DMARC record for it, so avoid using it as a customer-facing sending domain at all.

Third, when reading DMARC reports, traffic attributed to your tenant but authenticated only as onmicrosoft.com is usually a sign that DKIM enablement was missed for one of your accepted domains, not evidence of spoofing.

How do I add a DMARC record for Microsoft 365?

Domain-based Message Authentication, Reporting and Conformance (DMARC, RFC 7489) is a TXT record at _dmarc.yourdomain. Microsoft 365 needs nothing special here; the record is standard. Start in monitoring mode:

_dmarc.example.co.uk  TXT
"v=DMARC1; p=none; rua=mailto:dmarc-reports@example.co.uk"

The p=none policy changes nothing about delivery; it asks receivers to send you aggregate reports so you can see every source claiming to send as your domain. Run this monitoring phase for several weeks: most organisations discover senders they had forgotten about, such as a payroll platform, a scan-to-email copier, or a line-of-business application relaying through a connector.

Once the reports show your legitimate mail passing with alignment, tighten the policy through p=quarantine towards p=reject. The mechanics and the judgement calls involved are covered in moving from p=none to p=reject. Do not skip straight to reject on a Microsoft 365 estate of any size; connectors and legacy devices have a habit of surfacing late.

What are the hybrid Exchange caveats?

Hybrid deployments, where Exchange Server on premises coexists with Exchange Online, complicate every layer of this setup.

• SPF must cover both paths. Mail leaving directly from your on-premises servers comes from your own IP addresses, which spf.protection.outlook.com does not include. Add an ip4: mechanism for your outbound gateway, or route all outbound mail through Exchange Online so a single include suffices.
• On-premises mail is not DKIM-signed by Exchange Server. Exchange Server has no native DKIM signing. Messages that leave directly from on premises rely on SPF alone for alignment unless you add a signing gateway or third-party agent. Routing outbound via Exchange Online gets those messages signed by the service, provided the sending domain has DKIM enabled in the tenant.
• Centralised mail transport changes the path. If cloud mailboxes route outbound through on premises for compliance stamping, the last hop the internet sees is your gateway, and any body-modifying appliance in that path (disclaimers, banners) can break signatures already applied, producing a DKIM body hash failure.
• Internal relay devices are the long tail. Printers, monitoring systems and applications that submit through the on-premises servers all inherit that outbound path. Your DMARC reports are how you find them.

If most of your estate is still on premises, the dedicated guide to DMARC for on-premises Exchange goes deeper on gateway signing options.

What about other services sending as your domain?

SPF, DKIM and DMARC are domain-wide, not tenant-wide. If a CRM, a newsletter platform or a helpdesk sends as example.co.uk, the Microsoft records above do nothing for that mail. Each third-party service needs its own authentication: usually its own DKIM selector CNAMEs, and either an SPF include or, better, reliance on aligned DKIM alone. Inventory these senders during the monitoring phase; finding all your email senders describes a systematic approach.

How do I know it is all working?

Three checks, in increasing order of rigour:

1. Header inspection. Send to an external mailbox and confirm spf=pass, dkim=pass with your domain in header.d=, and dmarc=pass in Authentication-Results.
2. Record validation. Query the three records with nslookup or dig and confirm the published values match what you intended, including at the _dmarc and selector1._domainkey hostnames.
3. Aggregate reports. The reports arriving at your rua address are the only view that covers every receiver and every source. They arrive as XML attachments, which are tedious to read by hand; a DMARC monitoring service such as DMARCHub turns them into readable dashboards so you can watch alignment climb before tightening policy (see /features).

Frequently asked questions

Why does my Microsoft 365 mail fail DMARC even though SPF passes?

Almost always because the SPF pass is not aligned. Forwarded mail, some distribution list traffic and certain connector paths carry an envelope sender on a different domain (often the forwarder's), so SPF passes for that domain rather than yours. With DKIM enabled for your custom domain, the signature survives ordinary forwarding and keeps DMARC passing. If DKIM is still signing as onmicrosoft.com, fix that first.

Do I need to rotate the Microsoft 365 DKIM keys myself?

Rotation is worth doing periodically but is low effort: because your CNAMEs point at Microsoft-hosted key records, rotating from the Defender portal or PowerShell swaps selectors without any DNS change on your side. Tenants still signing with 1024-bit keys should rotate once to move to 2048-bit keys.

Should the onmicrosoft.com domain have its own DMARC policy?

Microsoft controls DNS for the initial domain, so you cannot publish records for it yourself. Treat it as an internal routing name: do not send customer-facing mail from it, and do not be alarmed when DMARC reports show DKIM passes attributed to it, which normally just means a custom domain in the tenant has DKIM enablement outstanding.

Does Microsoft 365 enforce my DMARC policy on inbound mail?

Yes, with local nuances. Exchange Online Protection evaluates DMARC on inbound mail and honours reject and quarantine policies, though like any receiver it applies local overrides in some cases, for example routeing certain failures to junk rather than rejecting at the gateway. Receivers are explicitly permitted this discretion under RFC 7489, so expect small differences between what your policy requests and what each receiver does.