Microsoft 365 custom domains and .onmicrosoft.com: what SPF, DKIM, and DMARC to publish

Microsoft 365 email authentication gets confusing faster than it should, mostly because every tenant has at least two domain stories happening at once:

• your real public domain, like example.com
• the tenant's built-in .onmicrosoft.com domain

And those two do not behave the same way.

That is where many rollouts go sideways. Teams verify example.com, see Microsoft 365 mail flowing, maybe publish the basic SPF record during tenant setup, and assume the rest is automatic. It is not. Microsoft handles some pieces for the tenant domain, but for custom domains you still need to publish and enable the right records yourself.

Microsoft's current guidance is spread across its email authentication overview, SPF setup, DKIM setup, and DMARC setup. Read those if you want the vendor wording. This post focuses on the operational version: what to publish, where to publish it, and the mistakes that keep showing up.

The key distinction: custom domain vs tenant domain

In Microsoft 365, your tenant gets a built-in Microsoft Online Email Routing Address, usually written as your <tenant>.onmicrosoft.com domain.

At the same time, most organizations also add one or more custom domains for actual user-facing mail, such as:

• example.com
• marketing.example.com
• billing.example.com

Receivers care about the domain that is actually used in the message identities. So the first practical question is not "What does Microsoft 365 own for us?" It is:

Which domain appears in From: on the mail you send?

If users send as alice@example.com, then example.com needs its own correct SPF, DKIM, and DMARC posture. The fact that Microsoft already controls your tenant's .onmicrosoft.com namespace does not automatically protect example.com.

If DMARC alignment still feels slippery, DMARC identifier alignment deep dive is the right refresher.

What Microsoft 365 already does for .onmicrosoft.com

Microsoft's documentation is fairly clear on this part:

• SPF for the tenant's .onmicrosoft.com domain is already maintained by Microsoft
• outbound mail from the tenant's .onmicrosoft.com domain is already DKIM-signed by default
• DMARC for the tenant's .onmicrosoft.com domain is not automatically done for you

That last bullet surprises people.

If you actually send mail using the .onmicrosoft.com domain in From:, Microsoft says you should add a DMARC TXT record for that domain in the Microsoft 365 admin center. If you do not use the .onmicrosoft.com domain for email, Microsoft also recommends protecting it with a rejecting DMARC policy so nobody can spoof it more easily.

So the short operational rule is:

• used .onmicrosoft.com domain: add DMARC
• unused .onmicrosoft.com domain: add DMARC with p=reject

This matters because many tenants never intend to send visible mail from .onmicrosoft.com, but the domain still exists and is still associated with the organization.

What to publish for a Microsoft 365 custom domain

For a custom domain like example.com, think in three layers.

SPF

If Microsoft 365 is the only source of mail for example.com, Microsoft's documented SPF record is:

example.com. IN TXT "v=spf1 include:spf.protection.outlook.com -all"

If you also send from somewhere else, such as an on-premises server or a third-party platform, the SPF record has to include those legitimate sources too.

Two details matter here:

• publish one SPF record per domain or subdomain, not multiple SPF TXT records
• each sending subdomain needs its own SPF record

That second point is easy to miss. example.com does not cover marketing.example.com for SPF. Microsoft says this explicitly.

If your SPF record is starting to sprawl, SPF 10 DNS lookup limit explained is worth keeping open while you edit DNS.

DKIM

This is the piece most Microsoft 365 custom-domain setups are missing.

For custom domains, Microsoft does not just start signing with your domain automatically. You need to enable DKIM for that domain and publish the two CNAME records Microsoft gives you.

The current Microsoft model is:

1. Add the custom domain to Microsoft 365.
2. Open the DKIM settings in Defender or use Get-DkimSigningConfig in Exchange Online PowerShell.
3. Copy the exact selector1 and selector2 CNAME targets Microsoft gives for that domain.
4. Publish those two CNAMEs in DNS.
5. Enable DKIM signing for the domain after Microsoft detects the records.

This is important in 2026 because Microsoft introduced an updated DKIM CNAME format for newer custom domains. The target values now include a dynamic partition character, so old blog posts and old screenshots can be wrong for your tenant. In other words, do not guess the DKIM targets from memory.

Use the values Microsoft shows for your actual domain.

Microsoft's own PowerShell example for checking the right values is:

Get-DkimSigningConfig -Identity example.com | Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME

If DKIM is not enabled for the visible domain, DMARC often ends up leaning too heavily on SPF. That works until forwarding, relaying, or a sender-path change exposes the weakness.

DMARC

After SPF and DKIM are in place, publish DMARC on the custom domain itself:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Starting with p=none is still the sane move for active domains, especially if the domain has multiple senders or any history of "one forgotten app sends invoices sometimes." Microsoft recommends a gradual rollout from p=none to p=quarantine and then p=reject.

For a normal Microsoft 365 custom-domain rollout, the order should be:

1. SPF valid for every domain that sends
2. DKIM enabled for every domain that sends
3. DMARC published at p=none
4. DMARC reports reviewed until legitimate sources are clean
5. policy tightened later

If you want the mechanics behind the DMARC tags themselves, DMARC record tag cookbook covers them in plain language.

Where each record actually lives

This is the easiest way to keep the setup straight.

For example.com used as a Microsoft 365 sending domain:

• SPF: publish in DNS for example.com
• DKIM: publish the two CNAMEs in DNS for example.com, then enable signing in Microsoft 365
• DMARC: publish TXT at _dmarc.example.com

For a sending subdomain like marketing.example.com:

• SPF: publish in DNS for marketing.example.com
• DKIM: publish DKIM records for marketing.example.com and enable DKIM for that subdomain in Microsoft 365
• DMARC: either inherit from the parent domain or publish a separate _dmarc.marketing.example.com policy if you need different handling

For the tenant's .onmicrosoft.com domain:

• SPF: already handled by Microsoft
• DKIM: already handled by Microsoft for the default tenant domain
• DMARC: add it yourself in the Microsoft 365 admin center

That last line is the one people tend not to expect.

Common pitfalls

1. Assuming the .onmicrosoft.com setup covers the custom domain

It does not.

If your users send as user@example.com, receivers evaluate example.com identities. You still need SPF for example.com, DKIM signing for example.com, and DMARC for example.com.

The tenant domain is not a magic umbrella.

2. Leaving custom-domain DKIM disabled

This is probably the single most common Microsoft 365 authentication gap.

Tenant mail is flowing. SPF passes. People stop there.

But Microsoft's custom-domain guidance explicitly says you need to configure DKIM signing with the custom domain or subdomain if you want aligned DKIM and proper DMARC support. Without that, a lot of mail is one forwarding hop away from pain.

3. Publishing the wrong DKIM CNAME targets

Older Microsoft 365 DKIM guides, cached screenshots, and forum answers often show selector targets that no longer match what newer tenants receive.

If the domain status in Defender says CnameMissing, do not immediately assume DNS is broken in general. First check whether the target values were copied exactly from the current Microsoft interface or current Get-DkimSigningConfig output.

This is especially easy to get wrong with:

• dashes replacing dots in the domain name
• the _domainkey labels
• the newer dynamic partition character in the target value

4. Forgetting subdomains are separate for SPF and DKIM

Microsoft says DMARC can inherit from the parent domain, but SPF and DKIM do not work that way.

So if you send some mail as alerts@billing.example.com, then billing.example.com needs its own sending-domain treatment. Reusing the parent domain's records is not enough.

This is one reason DMARC subdomain policy guide matters operationally, not just academically.

5. Testing with internal mail and concluding DKIM is broken

Microsoft documents a detail that catches people during verification: DKIM signatures can be omitted when the sender and recipient are in the same domain, or in different domains controlled by the same organization.

So if you are checking headers only on internal Microsoft 365 mail flow, you can end up proving almost nothing.

For verification, send to an external mailbox and inspect the full headers there.

6. Forgetting the unused .onmicrosoft.com domain still deserves DMARC

A tenant can be fully standardized on example.com and still leave the .onmicrosoft.com domain unprotected because "nobody uses it."

That is exactly why it should usually have a rejecting DMARC policy.

7. Using the main corporate domain for every third-party sender

Microsoft recommends subdomains for services you do not directly control. That advice is good for two reasons:

• it limits reputation blast radius
• it keeps SPF and DKIM changes for external platforms from turning the main employee mail domain into a fragile mess

If a marketing platform is sending on your behalf, marketing.example.com is often a much healthier choice than forcing everything through example.com.

A practical rollout that usually works

If the environment is messy, use this order:

1. List every domain and subdomain that appears in From:.
2. For each one, confirm whether Microsoft 365, a third-party service, or both send mail for it.
3. Publish exactly one SPF record per sending domain.
4. Enable DKIM for each Microsoft 365 custom domain or subdomain using the current Microsoft-provided CNAME values.
5. Publish DMARC with p=none and rua= on active sending domains.
6. Send test mail to an external mailbox and read Authentication-Results.
7. Review DMARC aggregate reports until all legitimate senders are accounted for.
8. Move active domains toward enforcement.
9. Put p=reject on unused domains, including the tenant's .onmicrosoft.com domain if it is not used for visible mail.

If you are troubleshooting header-level results while doing that, DMARC troubleshooting with real headers is the shortest route to seeing what receivers are actually evaluating.

Bottom line

In Microsoft 365, the built-in .onmicrosoft.com domain and your custom domains are related, but they are not interchangeable.

Microsoft already handles SPF and default DKIM signing for the tenant domain. For custom domains, you still need to publish SPF, enable DKIM with the exact CNAME targets Microsoft gives you, and publish DMARC yourself. And for the tenant's .onmicrosoft.com domain, DMARC still needs deliberate attention, whether that domain is used or parked.

Once that model clicks, the setup becomes much less mysterious: protect the domain people actually see, do not assume custom-domain DKIM is automatic, and treat the .onmicrosoft.com domain as a real domain that needs an explicit DMARC decision.