Defaults.Exposed › Setup walkthroughs › DKIM › Microsoft 365

How to set up DKIM on Microsoft 365

Microsoft 365 is the one platform where getting the DNS (Domain Name System) right is only three quarters of the job. Two CNAME (Canonical Name) records go into whichever company answers DNS for your domain, and then you come back to the Microsoft portal and switch signing on. Skip that last click and you end up with two correct records in DNS and mail still leaving unsigned, which is the most common way this setup fails.

Which half Microsoft does

Microsoft 365 both generates the DKIM (DomainKeys Identified Mail) keys for your tenant and does the signing, so you never see a long public key here the way you would with most other platforms. What Microsoft shows you instead is a pair of short pointers: two CNAME targets named after your tenant, each standing in front of a key Microsoft holds and can rotate on its own schedule. That indirection is deliberate and it is why you publish hostnames rather than key material.

What Microsoft does not do is publish those records. Unless you have separately chosen Microsoft to host your domain’s DNS, the zone lives at a registrar or a web host, and the two CNAMEs have to be created there. Microsoft also does not start signing on its own. It waits until you turn the toggle on, and it checks that both records resolve before it will let you.

There is a detail here that catches people who think DKIM is already handled. Every tenant gets its initial onmicrosoft.com domain signed by Microsoft from the start, so mail can carry a valid DKIM signature before you configure anything. That signature belongs to the onmicrosoft.com domain, not to yours, so it does not align with your domain for DMARC (Domain-based Message Authentication, Reporting and Conformance) purposes, and a check of your own domain will report no key. Configuring your custom domain is what changes that. The DKIM guide explains what alignment means on the receiving side.

The two records, and why they are CNAMEs

Both records use type CNAME, never TXT. The targets come in two formats. A custom domain added to Microsoft 365 from May 2025 onwards gets the newer one, under dkim.mail.microsoft:

selector1._domainkey    CNAME   selector1-<your-domain>._domainkey.<your-tenant>.<x>-v1.dkim.mail.microsoft
selector2._domainkey    CNAME   selector2-<your-domain>._domainkey.<your-tenant>.<x>-v1.dkim.mail.microsoft

Domains set up before then keep the older format, under onmicrosoft.com:

selector1._domainkey    CNAME   selector1-<your-domain>._domainkey.<your-tenant>.onmicrosoft.com
selector2._domainkey    CNAME   selector2-<your-domain>._domainkey.<your-tenant>.onmicrosoft.com

Microsoft’s documentation says the two formats can’t coexist for the same selector, so publish whichever one the portal shows for your domain.

The Name or Host field takes only selector1._domainkey or selector2._domainkey, since almost every DNS host appends your domain itself; typing the domain a second time produces a broken host such as selector1._domainkey.yourdomain.com.yourdomain.com. The Value, Points to or Target field takes Microsoft’s target exactly as shown on the DKIM page, with no surrounding quote marks, because a CNAME target is a plain hostname and quoting is a TXT (Text) convention. Leave TTL (Time to Live) on the default and save both records.

The second selector is what makes rotation invisible to you. Microsoft signs with one while keeping the other ready, then swaps, and because you published pointers rather than keys, nothing in your DNS needs to change when it does. That only works if both records are present, which is why Microsoft checks for both.

The <your-tenant> part of each target is the prefix of your tenant’s onmicrosoft.com name and the <your-domain> part is your domain with the dots replaced by hyphens, so example.com becomes example-com. In the newer format, <x> is a single character Microsoft assigns, such as n or r, giving n-v1 or r-v1. Copy the targets from the portal rather than assembling them by hand, because one wrong character stops the lookup dead.

Confirm where your DNS actually lives

The records belong wherever your domain’s nameservers point, and that is frequently not where people assume. Check the Nameservers section of your registrar account to see which company answers DNS for the domain. If it names a web host, a CDN (Content Delivery Network) or a DNS provider, the two CNAMEs go there. If the nameservers point at Microsoft, publish them in the Microsoft admin centre’s own DNS management for the domain.

Adding the records in the wrong console is not an error anything will report. The Microsoft portal will keep telling you it cannot find them.

Add the records, then switch signing on

1. Sign in as an administrator and open the Microsoft security portal at security.microsoft.com.
2. Go to the Email & collaboration area in the left-hand menu.
3. Open Policies & rules, then Threat policies, then Email authentication settings, then DKIM.
4. Select your domain from the list shown on the DKIM page.
5. Read off Host 1, selector1._domainkey, and its target, which ends in either dkim.mail.microsoft or onmicrosoft.com.
6. Read off Host 2, selector2._domainkey, and its target in the same format.
7. Publish both CNAME records at your DNS host, then return to this DKIM page.
8. Switch the control labelled Sign messages for this domain with DKIM signatures to On, shown in some tenants as Enable.

Step 8 is the one people lose. Microsoft starts signing only when you switch that control on; the records are what let it accept the instruction.

If the toggle refuses, DNS timing is the usual cause. Microsoft verifies both CNAMEs resolve before it will enable signing, so an attempt made a minute after publishing can fail while everything is correct. Wait, then try again.

Traps specific to Microsoft 365

• Microsoft’s DKIM record is a CNAME, not a TXT public key, so pasting a TXT value the way another provider’s guide describes will not work here.
• Publishing both CNAMEs is not the same as switching signing on. Microsoft signs nothing until you return to the DKIM page and set the toggle to On.
• Each target carries your tenant name, your domain written with hyphens and, in the newer format, a partition code such as n-v1, so one wrong character stops DKIM validating.
• A CNAME target is a plain host name and takes no quote marks, unlike a TXT record.
• Publishing only one of the two records leaves DKIM unverified, because Microsoft checks for both before it passes.
• Every custom domain in the tenant is configured separately. Turning signing on for one domain does nothing for the others.

Save, wait, then check

Publishing can take from a few minutes up to a couple of hours to be visible everywhere, and Microsoft cannot confirm the records until they are. The pair you save stays visible on the same DKIM page in the security portal, against your domain, so the portal is where you can see what Microsoft currently thinks the state is.

Once the toggle is on, run the free scan against your domain. It looks up the selector in DNS the way a receiving server does and reports whether the key is published and readable.

How the scan grades this record: the DKIM check, with its pass and fail rules and how many domains pass it.

Then check from the mail side, since that is the only check that covers the signing as well as the publishing. Send a message from the domain to an outside mailbox you can read, then open its Authentication-Results header. dkim=pass with your own domain in header.d= is the result you want. header.d= showing the onmicrosoft.com name instead means Microsoft is still signing with the tenant’s default domain and your custom domain has not been enabled.

When it still does not pass

Work it in this order. If the toggle would not switch on, the records are not visible yet or one of them is wrong, so recheck both targets character by character against the portal and give DNS more time. If the toggle is on but mail shows dkim=none, check you enabled the right domain in a tenant that has several. If header.d= names the onmicrosoft.com domain, the custom domain is still unconfigured.

A failing scan with everything apparently correct can also come from a limit in the checker. There is no way to list the DKIM records on a domain, so any checker has to ask for selectors by name and can only ask for the ones it knows to try. Microsoft’s selector1 and selector2 are well known, so this rarely bites Microsoft 365 tenants, but it is why the census figure reads the way it does: of the 76,563,365 domains where the October 2026 census could run the DKIM check, it found a key at a known selector on 38,666,798 (50.5%).

If you are troubleshooting a domain whose sending platform you inherited rather than chose, finding your DKIM selector shows how to read the live selector out of a sent message’s headers. And if DKIM passes while DMARC still fails, the alignment question in the DMARC piece is the next thing to read.

Figures from the defaults.exposed census, data as of 12 October 2026. Census numbers move every month; the current values are on the census data page.