Why your Microsoft 365 DKIM record lost its hyphen

We were setting up DKIM for a client on Microsoft 365, and their domain has a hyphen in the middle. Microsoft gave us the two CNAME values and the hyphen was gone. In its place was a little tail of digits and a letter. Every domain we'd done before looked exactly like the docs say, so this one worried us.

Turns out the values were fine. Microsoft 365 (Office 365) strips every hyphen out of the domain and adds a suffix that records where the hyphens used to be. We couldn't find that written down anywhere, so we tested it. Whatever your domain, copy the values exactly as Microsoft gives them.

This is not a definitive guide. It's our understanding of how it works, based on 28 hyphenated domains, and Microsoft can change it whenever they like. Hopefully Microsoft documents this properly one day. Until then, this is the "official guide" /s :-)

Microsoft only documents the dots

Every tenant uses the same two DKIM hostnames, selector1._domainkey and selector2._domainkey1. What changes is where they point. Here's how Microsoft describes the domain part of that target2:

The custom domain or subdomain with periods replaced by dashes. For example, contoso.com becomes contoso-com, or marketing.contoso.com becomes marketing-contoso-com.

That's it. Dots become dashes, and hyphens never come up. The word "hyphen" isn't on the page at all3.

That's the frustrating thing about Microsoft. They document everything, and then something like this just doesn't get documented. It isn't even Googleable. I call it a hyphen, other people call it a dash, so you don't know what to search for. DKIM records should be Googleable. This is one of those things that needs to be cast in stone, and when Microsoft changes it, there needs to be an updated article.

So going by the docs, b-and-q.co.uk should become b-and-q-co-uk. Here's what it really points at, as of 23 October 20264:

$ dig +short CNAME selector1._domainkey.b-and-q.co.uk
selector1-bandq-co-uk0cc._domainkey.KFPLC.onmicrosoft.com.

No hyphens, and an extra 0cc on the end. Your first thought will be a typo, or a value copied from the wrong tenant. It's neither. Don't "fix" it by putting the hyphens back either. That name doesn't exist, so the CNAME would point at nothing and DKIM would fail4:

$ dig +short TXT selector1-bandq-co-uk0cc._domainkey.KFPLC.onmicrosoft.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BA...
$ dig TXT selector1-b-and-q-co-uk._domainkey.KFPLC.onmicrosoft.com | grep status
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN

When you put the hyphens back and it breaks, I'd want whatever you're running, PowerShell or anything else, to tell you so plainly. Microsoft's documentation walks you through the PowerShell commands. It tells you how to rotate weak DKIM keys. So why wouldn't it say anything about a hyphen in your domain name?

Microsoft's own advice is not to build these by hand at all5: "Always use the exact CNAME values from the Defender portal or PowerShell. Don't construct them manually." Fair enough. This page is for the moment the value you copied looks wrong and you want to know if it is.

The partition letter is something else

Domains added since May 2025 get a newer target format6, ending in something like n-v1.dkim.mail.microsoft. That single letter before -v1 is what Microsoft calls the dynamic partition character7:

A dynamically generated character that's used for both selectors (for example, r or n). The value is automatically assigned by Microsoft when you add a new custom domain and enable DKIM.

It has nothing to do with hyphens. We added eight domains to one tenant on the same morning and got r, e, w, y, y, a, k and e8. We couldn't see anything in the names that tells you which letter you'll get. I find those letters quite fascinating, and from a technical point of view it would be nice to have them documented too. The hyphen suffix lives somewhere else, right after the domain:

selector1-rollsroycemotorcars-com01c._domainkey.bmwgroup.y-v1.dkim.mail.microsoft.
                                 ^^^                     ^
                        hyphen suffix           partition letter

That's rolls-roycemotorcars.com, which has both4. The rest of this page is only about the suffix.

Every hyphenated domain we found has the suffix

We ate our own dog food on this one. We didn't want to find eight domains on the internet and say that proves the rule. So we looked at all of our own email: every domain sending to us, and the DKIM records each of those domains has set up. All 104 Microsoft 365 domains without a hyphen looked exactly like the docs. Every one with a hyphen had lost it and picked up a suffix9. You can see the same thing on public domains4:

7-eleven.com              selector1-7Eleven-com0c
av-test.com               selector1-avtest-com0e
bang-olufsen.com          selector1-bangolufsen-com01b
rolls-roycemotorcars.com  selector1-rollsroycemotorcars-com01c
b-and-q.co.uk             selector1-bandq-co-uk0cc
marks-and-spencer.com     selector1-marksandspencer-com01cc
t-mobile.com              selector1-tmobile-com0c

And no, 7Eleven isn't a typo either. The case doesn't always match the domain, so ignore case when you compare.

If the domain's MX points at its own Microsoft 365 host, the same suffix shows up there too, like 7eleven-com0c.mail.protection.outlook.com4. People have been running into this for years. Someone asked on Microsoft's own forum in 2018 about DKIM for "a company with a dash in the name"10. In 2022 someone posted about a hosting panel refusing the MX domain24-com01c11. Nobody we found had worked out what the suffix meant.

I honestly thought I was just being silly. Surely there was a Microsoft page I could point at and say, look, it says this. There wasn't. I assume other people will have the same question at some point, and hopefully this is where you land.

It's not about avoiding a clash

Our first guess was clashes. tok-ab and tokab both strip down to tokab, so maybe Microsoft only adds a suffix when the stripped name is already taken?

Nope. We added test domains under osh.co.za to our own tenant and read back what Microsoft 365 generated8. tok-a got 0i with no toka anywhere in the tenant. tokcd went in after tok-cd and got no suffix at all. In our test, every name with a hyphen got a suffix, and no name without one did. A leading digit, as in 1tok, made no difference.

In the eight test domains where we read both, the DKIM token matched the MX token exactly. Microsoft's older documentation used to say that about DKIM and the MX record12, before the line was dropped from the current page.

The suffix is a map of where the hyphens were

From there it came down to logic, and what we know about character maps. Having the hyphen removed and a suffix added made the whole thing much more interesting. Being able to put down 0c or 0e, map it out and predict what would come out was quite exciting. It blew my mind a little. And somebody at Microsoft planned this. They didn't get any credit for it, because it was never written down.

It's also one of the reasons this article exists. If someone wants to use the same kind of encoding for something other than DKIM records, for a domain with a hyphen in it say, there should be a defined way to do it. So here it is.

Here's the rule that fits every token we've seen. It's a bitmap of the hyphen positions, written as letters. Count the characters from 0 at the start of the domain, then:

1. Split the domain into blocks of four characters.
2. In each block, add 1, 2, 4 or 8 for a hyphen in the first, second, third or fourth slot.
3. Write each block that has a hyphen as a letter: a is 0, b is 1, c is 2, and so on up to p for 15.
4. Write a run of blocks with no hyphen as a number: how many there were.
5. Put a 0 in front.

Blocks after the last hyphen are simply left off, so the suffix always ends on a letter.

Here's b-and-q.co.uk worked through:

position  0 1 2 3 | 4 5 6 7 | 8 9 ...
          b - a n | d - q . | c o . u k
value       2     |   2     |
letter      c     |   c     |
suffix    0 c c   ->  0cc

One hyphen in the first four characters gives you one letter: position 1 is 0c (7-eleven, t-mobile), position 2 is 0e (av-test), position 3 is 0i. A hyphen at position 4 lands in the second block, so the first block is empty and counts as 1. That's why bang-olufsen.com gets 01b.

This is also what stops different names colliding. tok-a, tok---a and tok with twenty hyphens before the a all strip down to toka. They came back as 0i, 0id and 0ipppph8. Yes, we really did add a domain with twenty hyphens in a row. Someone had to.

We wrote our guesses down first

We'd built the rule from tokens we already had, so of course it fit them. The first five hyphenated test domains, the ones that killed the clash idea, went in before we had a rule at all. For the next 16 we did it the other way round. Before each batch went in, we wrote down the suffix the rule predicted. Then we added them and read back what Microsoft generated8. They're all subdomains of osh.co.za, so the positions count from the start of the label.

Label	Hyphens at	We predicted	Microsoft 365 gave
a-tok	1	0c	0c
ab-tok	2	0e	0e
tok-aaaaaaaaaaaa	3	0i	0i
tokk-a	4	01b	01b
tokkk-a	5	01c	01c
tokkkk-a	6	01e	01e
tokkkkk-a	7	01i	01i
tokkkkkkk-a	9	02c	02c
tok-a-b	3, 5	0ic	0ic
tok-a-b-c-d	3, 5, 7, 9	0ikc	0ikc
tok---a	3 to 5	0id	0id
tok----a	3 to 6	0ih	0ih
tok + 20 hyphens + a	3 to 22	0ipppph	0ipppph
21 characters, then a hyphen	21	05c	05c
xn--toka-786a	2, 3, 8	0m1b	0m1b
xn--tok-3fd	2, 3, 7	0mi	0mi

Sixteen guesses, sixteen right. Those 16, the first five and the seven public domains make 28 hyphenated domains without an exception13. Our checker runs the same rule now, and it reproduces 30 of the tokens we have on record, test and public, with hyphens and without14. The public domains sit in other people's tenants and still match, so the suffix doesn't depend on the tenant.

Internationalised names use the xn-- form

Normally we're talking about "normal", in inverted commas, letters in domain names. But what about Cyrillic letters, or other alphabets? How does Microsoft deal with those? I'm sure they asked the same questions when they built this, so we tested two.

The last two rows of the table are those. xn--tok-3fd is tok followed by the Cyrillic letter щ. Microsoft worked from the xn-- form, counted its hyphens, then dropped them. The token came back as xntok3fd-osh-co-za0mi8.

xn--toka-786a is tok, an em dash, then a, encoded the older IDNA2003 way. Under the current rules an em dash isn't allowed in a domain at all, because it's punctuation, not a letter or digit15. So we can tell you what Microsoft did with that xn-- label. We can't tell you what it does with "a domain with an em dash", because there's no such thing.

Check it yourself

You don't have to take our word for the table. We put six of the test names back into our tenant and left them there. Microsoft built an MX host for each domain we added (they resolved about 15 minutes after the add), so you can look each one up from anywhere16.

Domain in our tenant	Token Microsoft built
tok-a.osh.co.za	toka-osh-co-za0i
tok-b-c.osh.co.za	tokbc-osh-co-za0ic
tokk-a.osh.co.za	tokka-osh-co-za01b
tok---a.osh.co.za	toka-osh-co-za0id
xn--tok-3fd.osh.co.za	xntok3fd-osh-co-za0mi
tokab.osh.co.za (no hyphen)	tokab-osh-co-za

Add .mail.protection.outlook.com to a token and ask for its A record. This is what tok---a gave us on 23 October 2026:

$ dig @1.1.1.1 +short A toka-osh-co-za0id.mail.protection.outlook.com
52.101.91.153
52.101.68.29
52.101.73.123
52.101.181.153

You'll probably get different addresses, because Microsoft rotates them. Any answer at all means Microsoft created the name. Now leave the hyphens in, the way the docs would have you build it:

$ dig @1.1.1.1 A tok-a-osh-co-za.mail.protection.outlook.com
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 38463

Drop the suffix instead (toka-osh-co-za) and that's NXDOMAIN too. The suffix is part of the name.

You can check the MX hosts but not the DKIM keys. Our DKIM configs for these names are switched off, and their selector targets return NXDOMAIN.

If you have a Microsoft 365 tenant of your own, the two PowerShell scripts we used are on GitHub, with a README that walks through the run: TamingDNS-Scripts/m365-dkim-hyphen-token. They add domains to your tenant, so read them first.

What we couldn't test

• Length. Our tenant took labels up to 38 characters under osh.co.za, 48 for the whole domain, and refused every longer one we tried (39, 40, 42, 45, 50 and 60) with 400 BadRequest8. We couldn't tell which of the two limits applies, or whether every tenant has the same cap. A hyphen at position 40 should give 010b, but we couldn't add a domain long enough to try it.
• A hyphen after a dot. Every hyphen we saw sat in the first label. So we don't know whether a hyphen in a later label, as in mail.north-wind.example, counts from the start of the domain the way the rule says.
• Why. I don't know why Microsoft does this. The encoding is lossless, so two names that strip to the same letters never end up with the same token. Maybe that's the reason. It's a guess.
• Tomorrow. Everything here is what we saw in October 2026. Microsoft already changed the DKIM target format in May 2025, and can do it again.

Our take

Copy whatever Microsoft gives you, every time. No hyphens and an odd tail on the end is exactly how it's meant to look.

Use this page to check a value, not to build one. If you work out the suffix by hand and it doesn't match what Microsoft shows you, go with Microsoft. Theirs is the one that signs your mail.

What to do

Pull both values straight from Exchange Online PowerShell5:

Get-DkimSigningConfig -Identity contoso.com | Format-List Name, Selector1CNAME, Selector2CNAME

Check that Name is your domain. If you mistype it, or the domain has no DKIM config yet, the command returns every config in the tenant17, and that's how a value from another domain gets copied. Publish them exactly as given. Then check what the rest of the internet sees, for both selectors:

dig +short CNAME selector1._domainkey.<your-domain>
dig +short CNAME selector2._domainkey.<your-domain>

The DKIM checker works out the token Microsoft 365 builds for your domain, suffix and all, and flags a selector1 or selector2 CNAME that carries a different one. That's the mistake to look for: a value copied from another domain, or one retyped with the hyphens put back.

If your domain's token doesn't fit, send me the domain and the CNAME Microsoft gave you at [email protected] and I'll show you where it breaks the rule.

Sources checked

1. The DKIM hostnames are the same for every tenant. Microsoft Learn, How to use DKIM for email in your custom domain: "The values are the same for all Microsoft 365 organizations: selector1._domainkey and selector2._domainkey." ↩
2. Microsoft documents the domain part as dots replaced by dashes. Same Microsoft Learn page, the <CustomDomainWithDashes> definition, quoted above. ↩
3. The page never mentions a hyphen in the domain. Same page, tags stripped, a case-insensitive count of "hyphen": 0. Page metadata ms.date 2026-07-03, updated 2026-08-24, read 23 October 2026. ↩
4. The seven public domains' DKIM targets and MX hosts. dig @1.1.1.1 +short CNAME selector1._domainkey.<domain> and dig @1.1.1.1 +short MX <domain>, run 23 October 2026. selector2 has the same shape for all seven. t-mobile.com's MX is not Microsoft's, so it has a DKIM token only. The hand-built name for b-and-q.co.uk, dig TXT selector1-b-and-q-co-uk._domainkey.KFPLC.onmicrosoft.com, returned NXDOMAIN the same day, and the real one returned a DKIM key. ↩
5. Microsoft says to copy the values, not build them, and gives the command. Same Microsoft Learn page: "Always use the exact CNAME values from the Defender portal or PowerShell. Don't construct them manually", followed by the Get-DkimSigningConfig line. We add Name, as the same page's own Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME example does. ↩
6. The newer target format dates from May 2025. Same page: "This value is part of the updated DKIM record format for new custom domains in Microsoft 365 introduced in May 2025. Existing custom domains and initial domains continue to use the old DKIM format". ↩
7. The partition character is one letter assigned by Microsoft. Same page, the <DynamicPartitionCharacter> definition, quoted above. ↩
8. Our tenant test. Test subdomains of osh.co.za added to our own Microsoft 365 tenant on 20 October 2026 with Microsoft Graph, their MX and DKIM values read back with Graph and Exchange Online PowerShell, then deleted the same day. The predictions were written down before each batch was added. Six of the names were added back on 23 October 2026 and kept, so you can check those from outside (source 16). ↩
9. 104 of 104 unhyphenated Microsoft 365 domains, and every hyphenated one. The sending domains in our own mailboxes on 20 October 2026, each looked up with dig. The list names client domains, so we publish the counts only. ↩
10. A 2018 question about DKIM for a hyphenated domain. Microsoft Q&A, Office365 and DKIM setup with - (dash/hyphen) in domain name, 5 October 2018: "I am trying to set up DKIM for a company with a dash in the name." ↩
11. A 2022 report of the suffix in an MX record. DirectAdmin forum, Microsoft365 MX record at domain hyphen, 20 December 2022: "When there is a hyphen in the domain, i.e. domain-24.com ... Microsoft365 wants this MX-record: 0 domain24-com01c.mail.protection.outlook.com". ↩
12. Microsoft's older text tied the DKIM value to the MX record. Quoted in Liktorius, Office 365, DKIM, and a naughty domain name, 19 February 2019: "domainGUID is the same as the domainGUID in the customized MX record for your custom domain that appears before mail.protection.outlook.com." Liktorius links that text to Microsoft's old use-dkim-to-validate-outbound-email page, which now redirects to the current Learn page (source 1), and that page contains "domainGUID" zero times. ↩
13. 28 hyphenated domains, no exception. Twenty-one hyphenated test domains in our tenant (source 8) and the seven public domains (source 4). ↩
14. The rule reproduces 30 recorded tokens. m365DkimToken() in dkim-core.js, run over 23 tenant tokens and the 7 public tokens: "30/30 reproduced", 23 October 2026. The 21-character test name is not in the run, because its full label is not in our notes; the rule gives 05c for any 21 characters followed by a hyphen. ↩
15. An em dash is not a valid character in a current domain name. RFC 5892 §2.1 allows letters, digits and combining marks (General_Category Ll, Lu, Lo, Nd, Lm, Mn, Mc); the em dash, U+2014, is Pd (dash punctuation). RFC 5892. ↩
16. The six live names. Added to our tenant on 23 October 2026 at 17:30 SAST and kept. dig @1.1.1.1 +short A <token>.mail.protection.outlook.com returned four addresses for each of the six at 17:57 SAST the same day. tok-a-osh-co-za and toka-osh-co-za returned NXDOMAIN, and so did dig TXT on the selector1 targets of tok-a and tok---a. Scripts and README: PaulOgier/TamingDNS-Scripts at commit 1bc1eda. ↩
17. A wrong or missing domain returns every config. Microsoft Learn, Get-DkimSigningConfig, the -Identity parameter: "The value $null or a non-existent value for the Identity parameter returns all objects as if you ran the Get- command without the Identity parameter." Read 23 October 2026. ↩