If the Defender portal or PowerShell shows the value without the hyphen, it is not a copy error. Those are the values Microsoft checks for, so publish them exactly as given: putting the hyphen back by hand leaves DKIM unable to switch on. Microsoft documents only part of the pattern, that dots become dashes. In all seven hyphenated Microsoft 365 domains we checked, the DKIM (DomainKeys Identified Mail) is a cryptographic signature attached to each outgoing message, verifiable against a public key published in DNS. It lets receivers confirm the message was not altered in transit and originated from a server the domain authorised to sign on its behalf. Read full reference → CNAME target also dropped the hyphen and ended in a short suffix: bang-olufsen.com comes out as bangolufsen-com01b.
That matters to a WordPress site sending through Microsoft 365, whether through the Outlook connection in WP Mail SMTP, FluentSMTP or Post SMTP, or through plain SMTP AUTH. Until the two CNAMEs resolve to the right targets and DKIM is switched on for the domain, Microsoft doesn’t DKIM-sign mail from it at all (“no DKIM signing occurs for outbound mail from custom domains”, in 
Microsoft’s words), and DMARC (Domain-based Message Authentication, Reporting, and Conformance) is a DNS TXT record that tells receivers what to do with mail from your domain that fails SPF or DKIM, and where to send reports about those failures. Read full reference → has only SPF (Sender Policy Framework) is a DNS TXT record that lists the servers allowed to send mail using your domain. Receivers compare the sending IP to that list and use the result as one input to their accept/reject decision. Read full reference → left to pass on.
What the CNAME values look like
Microsoft requires two selector CNAME records when you configure DKIM for a custom domain, at selector1._domainkey and selector2._domainkey. Both are CNAMEs pointing at a host Microsoft controls, where the public key lives. Microsoft’s documentation gives the label in the middle of that target as the custom domain “with periods replaced by dashes”, so contoso.com becomes contoso-com (Microsoft Learn, How to use DKIM for email in your custom domain). The page says nothing about hyphens.
Public DNS fills the gap. These are the selector1 targets and MX hosts published by domains that sign through Microsoft 365, as of 30 October 2026:
| Domain | selector1 CNAME target | MX host |
|---|---|---|
| bang-olufsen.com | selector1-bangolufsen-com01b._domainkey.beotalk.onmicrosoft.com |
bangolufsen-com01b.mail.protection.outlook.com |
| bosch-home.com | selector1-boschhome-com01c._domainkey.bosch.onmicrosoft.com |
boschhome-com01c.mail.protection.outlook.com |
| eon-uk.com | selector1-eonuk-com0i._domainkey.eonos.onmicrosoft.com |
eonuk-com0i.mail.protection.outlook.com |
| marks-and-spencer.com | selector1-marksandspencer-com01cc._domainkey.mnscorp.onmicrosoft.com |
marksandspencer-com01cc.mail.eo.outlook.com |
| t-mobile.com | selector1-tmobile-com0c._domainkey.tmobileusa.onmicrosoft.com |
(filtering gateway, not Microsoft) |
| b-and-q.co.uk | selector1-bandq-co-uk0cc._domainkey.KFPLC.onmicrosoft.com |
bandq-co-uk0cc.mail.protection.outlook.com |
| rolls-roycemotorcars.com | selector1-rollsroycemotorcars-com01c._domainkey.bmwgroup.y-v1.dkim.mail.microsoft |
rollsroycemotorcars-com01c.mail.protection.outlook.com |
| microsoft.com | selector1-microsoft-com._domainkey.microsoft.onmicrosoft.com |
microsoft-com.mail.protection.outlook.com |
| ucl.ac.uk | selector1-ucl-ac-uk._domainkey.liveuclac.onmicrosoft.com |
ucl-ac-uk.mail.protection.outlook.com |
Read across a row and the CNAME target has three parts:
selector1-is the selector name. selector2 uses the same target withselector2-in front.bangolufsen-com01bis the domain label. Dots become dashes as documented. In the seven hyphenated domains the hyphens are gone, both of them inb-and-q.co.uk, and a suffix (0c,0i,0cc,01b,01c,01cc) follows. The unhyphenated domains in the table have no suffix.beotalk.onmicrosoft.comis the tenant’s initial domain, theonmicrosoft.comname the organisation signed up with. It is independent of the custom domain, which is why the B&O target saysbeotalkand the T-Mobile one saystmobileusa. (The rolls-roycemotorcars.com target ends indkim.mail.microsoftinstead. It is on the newer format, covered in the next section.)
In the sample, the suffix belongs to the domain rather than the record. Where the domain’s MX points at Microsoft, the MX host carries the same label, suffix included, in every row above. Two more hyphenated domains have the suffixed label without DKIM: when we queried them, harper-adams.ac.uk received mail at harperadams-ac-uk01e.mail.protection.outlook.com and john-lewis.co.uk at johnlewis-co-uk01b.mail.protection.outlook.com, and neither published a public selector CNAME. The matching labels suggest Microsoft uses one label per domain across these records. The sample doesn’t show when that label is assigned.
Microsoft doesn’t say why the hyphen goes; what follows is our inference from the pattern. Dashes already stand in for dots, so a hyphen left in place would be ambiguous: bang-olufsen.com and bang.olufsen.com would both become bang-olufsen-com. Stripping hyphens removes that ambiguity but creates a new one, since bang-olufsen.com and bangolufsen.com would then share bangolufsen-com. A suffix would keep those two apart, which may be why it’s there. What the sample does show is narrower: none of the 23 unhyphenated domains we checked carried a suffix, and all seven hyphenated ones did.
Domains added since May 2025 get a different target
Microsoft changed the DKIM format for new custom domains in May 2025. A domain added since then gets a target under dkim.mail.microsoft instead of onmicrosoft.com (Microsoft Learn, Syntax for DKIM CNAME records):
selector1-<CustomDomainWithDashes>._domainkey.<InitialDomainPrefix>.<DynamicPartitionCharacter>-v1.dkim.mail.microsoftMicrosoft assigns the partition character, and both selectors share it. A live example: manchester.ac.uk publishes selector1-manchester-ac-uk._domainkey.livemanchesterac.p-v1.dkim.mail.microsoft. Existing domains keep the old format, and Microsoft says the old and new formats can’t coexist for the same selector.
Microsoft’s description of <CustomDomainWithDashes> doesn’t mention hyphens for the new format either. One domain gives a partial answer: rolls-roycemotorcars.com, the only hyphenated domain we found on the new format, publishes selector1-rollsroycemotorcars-com01c._domainkey.bmwgroup.y-v1.dkim.mail.microsoft, with the hyphen stripped and a suffix added as in the old-format sample. One domain is a thin base for a rule, and nothing in the sample lets the suffix be predicted from the domain name in either format. That is why the value has to come from the portal or PowerShell rather than be built by hand from the pattern.
How to check your own domain
Three reads settle whether the published records match what Microsoft expects.
What Microsoft expects, from Exchange Online PowerShell:
Get-DkimSigningConfig -Identity example-domain.com | Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAMESelector1CNAME and Selector2CNAME are the values to publish. The same values appear in the Defender portal under Email & collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM, in the domain’s details flyout.
What DNS currently publishes:
dig +short CNAME selector1._domainkey.example-domain.com
dig +short CNAME selector2._domainkey.example-domain.comEach should return the matching PowerShell value character for character, apart from letter case, which DNS ignores (
RFC 4343); dig also adds a trailing dot. An empty answer means this resolver returned no CNAME value: check the record in the DNS host’s zone editor, and allow time for propagation after a change. A value with the hyphen restored was edited by hand; replace it with the PowerShell value.
The domain’s own label, as a cross-check:
dig +short MX example-domain.comMicrosoft 365 MX hosts come in two shapes: the long-standing <label>.mail.protection.outlook.com (some tenants get a regional variant such as .mail.eo.outlook.com), and the newer <label>.<letter>-v1.mx.microsoft, as on ikea-com.i-v1.mx.microsoft. In either shape, the label at the front is the one to compare with the DKIM target. In our sample, every Microsoft MX carried the same label as the DKIM target, so a mismatch is a reason to compare the published CNAME with the PowerShell value again. An MX that points elsewhere, such as the filtering gateway in front of Microsoft at t-mobile.com, gives nothing to compare.
Once the records match, switch DKIM on for the domain in the same portal page, or with Set-DkimSigningConfig -Identity example-domain.com -Enabled $true. If Microsoft can’t find the CNAMEs, that command returns an error containing the values it expected. Microsoft’s own instructions for this step (Use Exchange Online PowerShell to configure DKIM signing) say to check “for typos in the values at the domain registrar (easy to do with the dashes, periods, and underlines!)”.
What a wrong value does to WordPress mail
A target that does not match Microsoft’s expected CNAME value can stop custom-domain DKIM from switching on. Microsoft looks for the CNAMEs before it enables signing; if it can’t find them, the domain stays unsigned and its status reads CnameMissing. Mail from the site goes out with no DKIM signature for its domain, the same as before DKIM was set up.
The message header shows which state the domain is in. Send a test from the site to a mailbox outside the organisation (Microsoft omits the signature when sender and recipient are in domains the same organisation controls) and read the DKIM-Signature line. Microsoft’s example from Verify DKIM signing of outbound mail:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=contoso.com;
s=selector1;d= is the domain that signed, and it should be the site’s domain. s= names the selector, and the receiver fetches the key from <s>._domainkey.<d>, which is where the CNAME hands the lookup on to Microsoft’s host. If no DKIM-Signature line carries d= with the site’s domain, the domain isn’t signing yet. The header auth visualizer reads the verdicts and domain details recorded in a pasted message header.
Whether DMARC fails depends on whether either SPF or any valid DKIM signature passes and aligns with the From domain. DMARC can pass on SPF when two things hold: SPF passes, and the domain it authenticated (normally the envelope sender, or MAIL FROM) aligns with the domain in the visible From address. Under relaxed alignment, the default, a subdomain of the same organisational domain counts; under strict alignment the two must be identical (RFC 9989, sections 3.2.10 and 4.4). A site sending as a mailbox on its own domain, with include:spf.protection.outlook.com in that domain’s SPF record (Microsoft Learn, Set up SPF), can meet both, provided the envelope sender is on that domain too. The header’s smtp.mailfrom= and spf= results show whether it does; the Microsoft 365 setup guide walks through the rest of the domain’s DNS.
The exposure is mail where SPF stops holding: a WooCommerce order email to a customer whose address forwards to another mailbox, a mailing list that relays the message, or an SPF record that lost its Microsoft include in a DNS change. Any of those can leave SPF failing or unaligned. A DKIM signature is the part that usually survives plain forwarding, because it travels inside the message and a forwarder that doesn’t alter the message leaves it valid (RFC 7960, section 3.2.1); a mailing list that changes the body or a signed header can invalidate it. If SPF neither passes nor aligns with the From domain, and no other valid DKIM signature aligns with it, DMARC has no mechanism left to pass on. Under a p=quarantine or p=reject policy, the receiving server may then quarantine or reject the message.
The DKIM reference and the DMARC reference explain how signing and alignment work. Some domains also send through more than Microsoft 365. The DKIM inventory checks known selector names, which can help find an old provider’s selector if it is on the list; random per-account selectors may not appear.
How we checked
On 30 October 2026 we queried selector1._domainkey, selector2._domainkey and the MX record of each domain with dig +short (BIND 9.18.39). We queried 23 hyphenated domains of large brands, retailers and universities. Seven publish Microsoft 365 DKIM selectors and appear in the table; harper-adams.ac.uk and john-lewis.co.uk have a Microsoft MX and no selectors; the other 14 showed no sign of Microsoft 365. The controls are 23 unhyphenated domains that publish Microsoft 365 selectors: microsoft.com, ucl.ac.uk, accenture.com, ikea.com, siemens.com, tesco.com, lego.com, manchester.ac.uk, ox.ac.uk, kcl.ac.uk, imperial.ac.uk, ed.ac.uk, bristol.ac.uk, leeds.ac.uk, nottingham.ac.uk, warwick.ac.uk, unilever.com, heineken.com, philips.com, bp.com, vodafone.com, nestle.com and shell.com. In this sample, every hyphenated domain on Microsoft 365 carried a suffix and no unhyphenated one did. selector2 used the same label as selector1 everywhere except leeds.ac.uk, whose selector2 points at a different label (geography-leeds-ac-uk). Where the MX pointed at Microsoft, its label matched the DKIM label in every case. That is enough to show the pattern and the shared MX label, but not to say how Microsoft picks the suffix characters, and the May 2025 format rests on a single hyphenated example. All the domains belong to large organisations; none is a small-business tenant. The documented formats are from Microsoft Learn’s DKIM configuration page as it stood on the same date.