What this check looks at
Checks in Exchange Online that DKIM signing is turned on for every custom domain that receives mail, not just that the keys are published in DNS.
Publishing DKIM keys in DNS is only half of DKIM: Exchange Online signs outgoing mail with a custom domain only once signing is turned on for that domain in its DKIM configuration. Until then it signs with the tenant’s onmicrosoft.com domain, so the signature is valid but does not match the From address, and it counts for nothing in DMARC.
The check reads Exchange Online’s DKIM signing configuration and compares it with the tenant’s custom domains, leaving out parked domains that have no MX record. It fails when signing is not on for any of those domains, listing each with its DKIM status (CnameMissing, for example, or not set up), and passes when every custom domain that receives mail is signed.
Without aligned DKIM, DMARC depends on SPF, which fails when mail is forwarded or relayed through another service. That makes an enforcing DMARC policy risky for genuine mail, so domains stay at p=none and remain easy to spoof.
Why it matters
Published DKIM keys do nothing until Exchange Online signs with them. Without signing, DMARC rests on SPF alone, which breaks when mail is forwarded, and the domain is easier to spoof.
A typical case: an accountancy practice sends year-end packs to clients, several of whom forward everything from the practice to their bookkeeper automatically. Without DKIM the forwarded copies fail SPF, and therefore DMARC, and land in junk or are refused; signed with the practice’s own domain, they pass wherever they are forwarded.
Signing with the organisation’s own domain also builds its sending reputation with Microsoft, Google and Yahoo, which now expect authenticated mail, and is what makes it safe to move DMARC to p=reject and stop criminals sending invoices in the firm’s name.
CIS Microsoft 365 Foundations Benchmark 2.1.9 and CISA SCuBA MS.EXO.3.1 ask for DKIM to be enabled for all Exchange Online domains. ISO 27001 A.5.14 and A.8.24, CIS Controls v8 9.5, NIST CSF 2.0 PR.PS-01 and NCSC CAF B4.b cover the same ground.
How to fix it
Where: Microsoft Defender portal → Email authentication settings → DKIM
Before you start
- Publish the two selector CNAME records Defender shows for each domain at the DNS host, and wait for them to resolve, before turning signing on.
Step by step
- Open the DKIM settings. In the Microsoft Defender portal, go to Email & collaboration > Policies & rules > Threat policies > Email authentication settings and select the DKIM tab. The list shows each domain and its status; the domains in the finding show signing disabled.
- Create keys where none exist. Select a domain from the finding. If the flyout says there are no DKIM keys for it, select Create DKIM keys. The flyout then shows two CNAME records, for selector1._domainkey and selector2._domainkey.
- Publish the CNAMEs if they are missing. If the status is CnameMissing, add both CNAME records at the domain’s DNS host exactly as shown and wait for them to resolve; check with Resolve-DnsName -Name selector1._domainkey.contoso.com -Type CNAME and the same for selector2.
- Turn signing on. In the domain’s flyout, set Sign messages for this domain with DKIM signatures to Enabled. The status should change to Valid; if it still reports the CNAMEs missing, wait a little longer for DNS and try again. Repeat for each domain in the finding.
- Or use Exchange Online PowerShell. Run Get-DkimSigningConfig | Format-Table Domain, Enabled, Status to see every domain. For one with no configuration, run New-DkimSigningConfig -DomainName contoso.com -Enabled $false and read the records with Get-DkimSigningConfig -Identity contoso.com | Format-List Selector1CNAME, Selector2CNAME. After publishing them, run Set-DkimSigningConfig -Identity contoso.com -Enabled $true.
- Confirm signing with a real message. Run Get-DkimSigningConfig again and check Enabled is True and Status is Valid for each custom domain. Send a message from each domain to an external mailbox and check the headers show dkim=pass with header.d set to your domain, not onmicrosoft.com. The next assessment passes.
With PowerShell
Set-DkimSigningConfig -Identity yourdomain.com -Enabled $true
What users will notice
None. Outgoing mail is signed with the organisation’s own domain, which helps it reach inboxes.
How to confirm it worked
Get-DkimSigningConfig shows Enabled True and Status Valid for each custom domain; a test message’s headers show dkim=pass with the domain.
Frameworks and controls
This check maps to controls in 12 frameworks. Passing it is evidence that the setting is in place, not a certification against any of them.
| Framework | Control |
|---|---|
| NCSC CAF | B4.b Secure configuration |
| DSPT | Standard 9: IT protection |
| NIS2 | Art. 21(2)(g) Basic cyber hygiene practices and training |
| Zero Trust | Applications |
| SOC 2 | CC6.6 Protection against threats from outside the system boundaries |
| PCI DSS 4.0.1 | 5.4.1 Personnel are protected against phishing attacks |
| ISO 27001:2022 | A.5.14 Information transferA.8.24 Use of cryptography |
| CISA SCuBA | MS.EXO.3.1v1 DKIM enabled for every domain |
| CIS M365 | 2.1.9 Ensure that DKIM is enabled for all Exchange Online Domains |
| CIS Controls v8.1 | 9.5 Implement DMARC (IG2) |
| NIST CSF 2.0 | PR.PS-01: Configuration management practices are established and applied |
| NCSC 10 Steps | Architecture and configuration |
The framework mappings were last checked against the published standards in October 2026.
Microsoft’s documentation
- Set up DKIM to sign mail from your domain (Microsoft Learn)