How to Set Up SPF, DKIM and DMARC in Microsoft 365

This guide shows you how to set up SPF, DKIM and DMARC in Microsoft 365 for a custom domain — the three DNS-based checks that prove your mail really comes from you and stop others from sending as your domain. The steps are specific to Microsoft 365: the SPF include is spf.protection.outlook.com, DKIM is switched on in the Microsoft Defender portal using two CNAME selectors, and DMARC is a _dmarc TXT record you publish yourself.

Every record here was verified in August 2026 against Microsoft's own Defender for Office 365 documentation. One record most admins forget — a DMARC record for your onmicrosoft.com domain — is covered near the end, because Microsoft sets up SPF and DKIM there for you but not DMARC.

The short answer#

Email authentication in Microsoft 365 is three separate records doing three separate jobs. SPF lists who is allowed to send for your domain. DKIM cryptographically signs your outbound mail. DMARC tells receivers what to do when a message fails both, and turns on reporting so you can see who is sending as you.

For a custom domain such as contoso.com, the minimum working setup is three records:

• SPF: one TXT record at your DNS host with the value v=spf1 include:spf.protection.outlook.com -all.
• DKIM: switch the domain on in the Microsoft Defender portal, then publish the two CNAME records — selector1._domainkey and selector2._domainkey — that it generates for you.
• DMARC: one TXT record at host _dmarc, starting at v=DMARC1; p=none; rua=mailto:[email protected], then tightened over time.

Before you start#

A few things need to be true before the steps below will work. Check them first — most failed setups trace back to a missing prerequisite rather than a mistyped record.

• Your custom domain is already added and verified in Microsoft 365. DKIM only becomes available after the domain is added, under Microsoft 365 admin center > Settings > Domains.
• You can edit DNS for the domain, at your registrar or DNS host such as GoDaddy, Cloudflare, or Route 53. SPF and custom-domain DMARC records are created there, not inside Microsoft 365.
• You have an admin role that can open the Microsoft Defender portal at security.microsoft.com, where DKIM is enabled.
• You know your initial domain prefix — the custom part of your onmicrosoft.com address. For contoso.onmicrosoft.com it is contoso, and DKIM CNAME targets are built from it.
• Plan to set a TTL of at least 3600 seconds (one hour) on these records; Microsoft recommends it to avoid DNS lookup timeouts.

Step 1 — Publish your SPF record#

SPF is a single TXT record you add at your DNS host. There is no SPF setting inside Microsoft 365 — Microsoft states plainly that there are no admin portals or PowerShell cmdlets for managing SPF, so this happens at your registrar.

If Microsoft 365 is the only thing sending mail for contoso.com, the record is short:

The include:spf.protection.outlook.com part authorizes Microsoft's sending servers. The -all at the end is a hard fail — Microsoft recommends it for Microsoft 365 domains because you will also add DKIM and DMARC, and DMARC is what decides how failing mail is actually handled. A softer ~all (soft fail) is the more forgiving alternative some people use while testing.

Two rules trip people up. Only one SPF record is allowed per domain; a second one makes SPF return permerror. And the whole record must resolve in fewer than 10 DNS lookups, so if you send through several outside services, move the ones you do not control onto a subdomain with its own SPF record.

Step 2 — Enable DKIM in the Defender portal#

DKIM is the part that is configured inside Microsoft and then finished at your DNS host. For a custom domain, Microsoft 365 does not DKIM-sign your mail until you switch it on and publish two CNAME records.

1. 1

   Open the Email authentication settings

   In the Microsoft Defender portal at security.microsoft.com, go to Email & collaboration > Policies & rules > Threat policies > Email authentication settings, then select the DKIM tab. The direct link is security.microsoft.com/authentication.

2. 2

   Generate the keys

   Select your custom domain and try to slide its toggle toward Enabled. Because the CNAME records don't exist yet, you get a client error listing the values you need — that is expected. The status changes to CnameMissing.

3. 3

   Copy the two CNAME targets

   Open the domain's details flyout and read the Publish CNAMEs section, or run Get-DkimSigningConfig in Exchange Online PowerShell. Copy the selector1 and selector2 targets exactly. Do not type them out by hand.

4. 4

   Create the CNAMEs at your DNS host

   Add two CNAME records with hosts selector1._domainkey and selector2._domainkey, each pointing to the target Microsoft gave you. Wait a few minutes for DNS to propagate.

5. 5

   Turn signing on

   Back in the flyout, enable Sign messages for this domain with DKIM signatures. Once Microsoft detects both records, the status becomes Signing DKIM signatures for this domain.

Step 3 — Publish your DMARC record#

DMARC ties SPF and DKIM together and, crucially, requires the domain in your visible From address to align with the one that passed SPF or signed with DKIM. Like SPF, the custom-domain DMARC record is a TXT record you create at your DNS host.

Start in monitoring mode so you can watch reports before you enforce anything:

p=none takes no action on failing mail but turns on the aggregate reports sent to your rua address. Read those reports, confirm your legitimate mail aligns, then raise the policy over weeks: p=none to p=quarantine to p=reject, which is the enforcement goal Microsoft recommends. Send the reports to a dedicated shared mailbox or Microsoft 365 Group, not a personal inbox.

Unlike SPF and DKIM, one DMARC record automatically covers every subdomain that doesn't have its own. You don't need a separate record per subdomain unless you want to override the parent for one of them.

Don't forget the onmicrosoft.com domain#

Here is the record almost everyone misses. Microsoft owns the onmicrosoft.com domain, so it already publishes SPF and DKIM for your contoso.onmicrosoft.com address — but it does not create a DMARC record there. You have to, and you do it in a different place: the Microsoft 365 admin center, not your registrar.

1. 1

   Open Domains in the admin center

   In the Microsoft 365 admin center at admin.microsoft.com, go to Settings > Domains and select your onmicrosoft.com domain from the list.

2. 2

   Add the DMARC record

   On the DNS records tab, choose Add record. Set Type to TXT, the TXT name to _dmarc, and the TXT value to v=DMARC1; p=reject. Leave TTL at one hour and save.

Because you send little or no mail from the onmicrosoft.com domain, Microsoft's own guidance goes straight to p=reject for it. The same logic applies to parked domains — registered names you never send from at all. Protect those with SPF v=spf1 -all and DMARC v=DMARC1; p=reject;, and for parked domains do not publish DKIM records, since the absence of a DKIM key helps block forgeries.

The three records at a glance#

Here is the whole setup in one view for a custom domain in Microsoft 365, with the extra DMARC record for the onmicrosoft.com domain.

How Microsoft 365 differs from Google Workspace#

If you have set this up in Google Workspace before, three things are genuinely different in Microsoft 365 — which is why a Workspace guide won't translate cleanly.

The exact Google Workspace records — the precise include and selector name — live in our Google Workspace guide, and you should verify them against Google's admin help, since this page is Microsoft-specific. The important shape difference is DKIM: Microsoft uses two CNAMEs that delegate key management and rotation to Microsoft, while Workspace hands you a single public key to publish as a TXT record.

What to do when it doesn't work#

Most authentication problems come down to a handful of DNS mistakes. Match your symptom to the likely cause, then fix that one thing rather than rebuilding everything.

Work top down. A broken or misaligned DMARC record is the single most common reason mail that looks authenticated still fails, because SPF and DKIM can each pass on their own while alignment quietly fails underneath them.

Where AI Emaily fits — and where it doesn't#

None of this happens inside an email client, and it is worth being clear about that. Setting up SPF, DKIM and DMARC is DNS and portal work — no mail app publishes these records for you, and AI Emaily doesn't either. If your job today is getting the records right, the steps above are the whole answer.

Where AI Emaily fits is the receiving side of the same standards. We build AI Emaily, an AI email client that connects to your Microsoft 365 or Outlook account, and its spam and phishing protection reads the SPF, DKIM and DMARC results on the mail arriving to you. Messages that fail those checks — including senders spoofing a domain — get caught instead of landing in your inbox. The records you just published protect your outbound reputation; the filtering is what handles the inbound side once they are in place.