If you are searching for , , or , the easiest way to get into trouble is to copy a static CNAME example from an old blog post.

Microsoft's current guidance is more precise than that. For custom domains, you should get the actual DKIM values for your tenant from Microsoft 365 itself, then publish the matching CNAME records and enable signing only after Microsoft can see them.

That is the difference between "we published something that looks right" and "the tenant is actually signing our custom domain in production."

Quick answer

For Microsoft 365 or Office 365 custom domains, the normal DKIM flow is:

  1. add and verify the custom domain in Microsoft 365
  2. open the DKIM area in the Defender or email authentication settings
  3. retrieve the required and CNAME targets for the domain
  4. publish both CNAME records in DNS
  5. wait for Microsoft to detect the records
  6. enable DKIM signing for the domain
  7. verify a real message shows

Microsoft documents two important implementation details:

  • Microsoft 365 uses two selectors, commonly exposed as and
  • for new custom domains created after May 2025, the target format uses a dynamic partition character before

That second point is why you should not guess the CNAME target pattern from an old screenshot.

What this guide covers

This page is for teams that need to answer:

  • does Office 365 sign custom domains automatically?
  • where do we get the correct selector targets?
  • what changed in the newer Microsoft 365 DKIM format?
  • how do we verify DKIM after Microsoft says the records are present?

If your issue is SMTP transport settings rather than DKIM, use Office 365 SMTP settings first.

Office 365 DKIM vs Microsoft 365 DKIM

In practice, many teams still search for even when they are working in the modern Microsoft 365 admin and Defender surfaces.

The practical question is the same:

  • enable DKIM signing for a custom domain
  • publish the right DNS records
  • confirm outbound mail is signed correctly

This guide uses the older language where it matches the search, but the operational guidance is for the current Microsoft 365 model.

Does Microsoft 365 sign every domain automatically?

Not in the way many teams assume.

Microsoft documents that outbound mail for the initial domain is already DKIM-signed. Custom domains are the important part here. If you want Microsoft 365 to sign mail for your own branded domain, you need to configure that domain explicitly.

That means a working mailbox alone is not proof that your custom domain is ready for DKIM-aligned delivery.

Where to get the correct CNAME records

Microsoft's guidance is to retrieve the required values from Microsoft 365, not from a generic template.

You can do that through the UI or by using PowerShell:

That gives you the exact selector targets for the specific custom domain in your tenant.

This matters because Microsoft's documentation notes that newer custom domains use a target format like:

The partition element is dynamic. It is not something you should invent manually.

The Office 365 DKIM setup flow

Use this sequence:

  1. confirm the custom domain is added and healthy in Microsoft 365
  2. open the DKIM settings for the domain
  3. retrieve the exact and values
  4. publish both CNAME records in DNS
  5. wait for propagation
  6. let Microsoft detect the records
  7. enable DKIM signing
  8. verify a real message header

Do not enable DKIM based on assumption alone. Microsoft needs to see the records first, and your verification step still happens after that.

Why Microsoft uses two selectors

Using two selectors is normal DKIM practice. It supports cleaner rotation and safer changes over time.

Operationally, that gives you:

  • room for key rollover
  • less disruption during certificate or signing changes
  • a more controlled recovery path if one selector has to be replaced

The mistake is publishing only one record because it looked like enough for a quick test. Publish both.

Common Office 365 DKIM setup mistakes

Copying a stale CNAME example

This is the biggest one. Old blogs often show a fixed target pattern that does not match your current tenant.

Publishing the wrong host name

The visible selector target may be correct, but the DNS provider UI expects only the host portion, not the fully qualified name.

Enabling DKIM before Microsoft can see the records

That creates a noisy gap where teams assume the feature is active when the tenant still cannot sign correctly.

Forgetting subdomains or additional branded domains

Each domain using Microsoft 365 sending needs its own review. One working domain does not mean all of them are correctly configured.

Treating DKIM as a complete deliverability fix

DKIM matters, but it still has to align with SPF, DMARC, sender identity, and the actual sending systems in use.

How to verify Office 365 DKIM after setup

Use a real outbound message and inspect the headers.

Look for:

  • a header
  • showing
  • a signing domain that matches your intended brand and DMARC strategy
  • selector information that maps back to the records you published

The key point is that the Microsoft 365 admin surface telling you DKIM is enabled is not the end of verification. The real message header is the final proof.

Office 365 DKIM and DMARC alignment

A valid DKIM signature is not enough if the visible From domain strategy is inconsistent across your other senders.

That means you should review Office 365 DKIM together with:

Why?

Because many "Office 365 DKIM" incidents are really mixed-sender incidents. Microsoft 365 may be signing correctly while another platform, such as billing or support tooling, is still sending misaligned mail from the same domain.

Troubleshooting when Microsoft 365 DKIM still fails

Use this workflow:

  1. retrieve the current selector targets from Microsoft 365 again
  2. confirm the DNS records match exactly
  3. query the published selectors with DKIM checker
  4. send a real test message to a controlled mailbox
  5. inspect the header with Email header analyzer
  6. validate DMARC with DMARC checker

This narrows the problem to one of four buckets:

  • wrong CNAME target
  • incomplete propagation
  • signing not actually enabled
  • alignment conflict with the wider sender environment

Office 365 DKIM during migrations

Be especially careful during:

  • Microsoft 365 tenant migrations
  • brand-domain cutovers
  • subdomain segmentation
  • shared-to-dedicated sender changes
  • support or notification system consolidations

The most common bad sequence looks like this:

  1. DNS is changed quickly
  2. a test message "seems fine"
  3. real mail volume starts
  4. some paths still fail DKIM or DMARC alignment
  5. the incident appears as a deliverability issue instead of a setup issue

That is why DKIM should sit in the release checklist, not in the postmortem.

How MailSlurp helps

MailSlurp helps teams turn DKIM setup into a repeatable validation workflow.

Use it to:

That makes the Office 365 DKIM change testable before it becomes a customer-facing delivery issue.

FAQ

Does Office 365 sign custom domains automatically?

No. Microsoft 365 signs the initial domain automatically, but custom domains need their own DKIM configuration.

How many DKIM records does Office 365 need?

Microsoft 365 uses two selectors, usually exposed as and , and both CNAME records should be published.

Can I use a generic CNAME example from a blog?

No. Microsoft documents that the exact selector targets should come from your tenant configuration, and newer domains use a dynamic partitioned target format.

How do I verify Office 365 DKIM is working?

Send a real message and inspect the headers for and the expected signing domain.

Is Office 365 DKIM enough for deliverability on its own?

No. It needs to work with SPF, DMARC, clean sender identity, and the rest of your outbound mail architecture.

Final take

Office 365 DKIM setup is no longer a copy-paste DNS trick. The correct process is to get the real selector targets from Microsoft 365, publish both CNAMEs accurately, enable signing deliberately, and confirm the result in live message headers before assuming the custom domain is production-ready.