This guide covers Exchange Online mail sent from a domain or subdomain you own. A personal Outlook.com account, the initial onmicrosoft.com domain and an additional newsletter service are different cases.
Check the domain, sending route and permissions
Your domain must already have been successfully added to Microsoft 365. Check whether messages actually pass through Exchange Online and whether a gateway changes them afterwards. Each of your sending domains or subdomains used there needs the appropriate DKIM configuration. Adding a domain to the tenant does not configure every other sending service.
You need access to the active DNS zone and the necessary administrative permissions in your Microsoft 365 organisation. The PowerShell commands below require an already configured, authorised Exchange Online PowerShell session. For each cmdlet, Microsoft refers to assigned roles and parameter permissions. This does not mean that any sign-in suffices or that Global Administrator is always required. Check the cmdlet permissions actually needed before making a change.
Read the existing configuration first. Do not create or replace keys simply because you are following a new guide. example.com is an example domain in every command below; replace it with your own verified domain. These commands have not been run here.
1. Obtain and publish the current CNAME values
Read the existing configuration or deliberately create a new one
In an authorised Exchange Online session, read the values for one specific domain:
Get-DkimSigningConfig -Identity "example.com" | Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAMECheck that Name in the response identifies exactly the intended domain. Microsoft warns that a missing or invalid Identity value can sometimes return all objects. Do not use CNAMEs belonging to a different domain in the results.
If a domain already added to the service genuinely has no DKIM configuration, Microsoft describes creating one with signing initially disabled. The following command changes the configuration and is intended only for this confirmed new configuration case; a read error does not prove that the configuration is absent:
New-DkimSigningConfig -DomainName "example.com" -Enabled $false -KeySize 2048
Get-DkimSigningConfig -Identity "example.com" | Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAMEAlternatively, find the domain in the Defender portal under Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM. Open the domain details and the Publish CNAMEs section. For a new configuration showing NoDKIMKeys, Microsoft first describes generating the keys; the first attempt to enable signing can return the required CNAMEs in an error message and move the status to CnameMissing. Signing has not yet been successfully enabled. Follow the current portal procedure for this starting state, instead of repeatedly switching it on without checking DNS.
Two record names, two supplied targets
On narrow screens, scroll the table sideways.
| Name in your DNS zone | Type | Target |
|---|---|---|
selector1._domainkey | CNAME | Exactly the value from Selector1CNAME or the portal |
selector2._domainkey | CNAME | Exactly the value from Selector2CNAME or the portal |
For example.com, the full names are selector1._domainkey.example.com and selector2._domainkey.example.com. Check whether your DNS interface appends the domain suffix automatically. Microsoft publishes the public DKIM key at the CNAME target. The private key remains with the service; it does not belong in DNS.
Do not construct targets from the tenant name. Since May 2025, Microsoft has documented a format under dkim.mail.microsoft with a dynamic component for new custom domains. Existing configurations can retain the older target under onmicrosoft.com. An older working format does not become incorrect simply because of its age. Use the values currently supplied for your domain. Do not publish both old and new target variants under the same selector.
The two CNAMEs prepare the domain for Microsoft's key management. Their mere presence does not identify the selector currently used, prove that a rotation has completed or imply two active signatures per message.
2. Check DNS and enable signing
Read both CNAMEs. These short queries require dig to be installed:
dig CNAME selector1._domainkey.example.com +short
dig CNAME selector2._domainkey.example.com +shortOn Windows, with the DnsClient module:
Resolve-DnsName -Name selector1._domainkey.example.com -Type CNAME -DnsOnly
Resolve-DnsName -Name selector2._domainkey.example.com -Type CNAME -DnsOnlyCompare each response with the corresponding supplied target. If the short response is empty or unclear, read the full DNS output, for example without +short. An incorrect query name, the wrong zone, DNS errors and cached results are different possible causes. A matching CNAME is initially DNS evidence; the public key at its target and actual signing also need to match the sending route.
After publishing the correct records, enable signing for the same domain in the DKIM section of the Defender portal. Its status should indicate signing. Alternatively, in an authorised session:
Set-DkimSigningConfig -Identity "example.com" -Enabled $true
Get-DkimSigningConfig -Identity "example.com" | Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAMESet-DkimSigningConfig makes a change. Afterwards, check Enabled and Status; Microsoft describes True and Valid for a successful configuration. CnameMissing calls for comparing the DNS values and Microsoft's detection of them. A fixed waiting period cannot replace this check. Administrative status is not yet evidence from a received message.
3. Check a message received externally
Send your own message through the Exchange Online route under investigation to a recipient you are authorised to use outside the same Microsoft 365 organisation. Microsoft notes that messages within the same organisation can remain unsigned even between different domains. Such an internal test is not suitable evidence against external signing.
Open the original headers at the recipient. Identify the expected DKIM-Signature using d= and s=, then read the corresponding DKIM result from the trusted receiving system in Authentication-Results. The selector in the message, the DNS name beneath the signing domain and the Microsoft CNAME target serve different purposes. Do not infer the actual s= value from a copied target example belonging to someone else.
On narrow screens, scroll the table sideways.
| Evidence | What it establishes | Remaining limit |
|---|---|---|
| Both matching CNAMEs | DNS points to the targets intended for this domain. | Does not prove active signing. |
| Enabled administrative status | The service reports the configuration as active. | Does not prove that every sending route works. |
Signature and trusted dkim=pass | The specific signature was successfully verified for this received message. | No inbox guarantee; does not prove that the content is harmless or that every sending route in the tenant has been checked. |
| DMARC result | Successful authentication is also checked for alignment with the visible From domain. | A DKIM pass alone is not automatically a DMARC pass. |
The guide to interpreting header results helps identify the relevant evidence. For the next authentication step, see understanding DMARC alignment. DMARC can pass through aligned SPF or DKIM; publishing a policy does not guarantee actual rejection, delivery or complete protection against phishing.
Check key rotation and key length separately
Microsoft documents RSA keys of 1024 or 2048 bits. Existing keys are not necessarily already 2048 bits. RFC 8301 requires RSA signing keys to be at least 1024 bits and recommends at least 2048 bits; the standard and the actual tenant state are separate evidence. The documented Exchange Online cmdlets offer RSA for this signing configuration, with no Ed25519 option. This says nothing about which incoming signatures a recipient can verify.
Before a planned rotation, read the state of both selectors and the scheduled change:
Get-DkimSigningConfig -Identity "example.com" | Format-List Name,Enabled,Status,Selector1CNAME,Selector1KeySize,Selector2CNAME,Selector2KeySize,KeyCreationTime,RotateOnDate,SelectorBeforeRotateOnDate,SelectorAfterRotateOnDateFor a prepared change that you are authorised to make, Microsoft gives this example:
Rotate-DkimSigningConfig -Identity "example.com" -KeySize 2048This is a change, not a checking command. For the documented procedure, Microsoft specifies four days, or 96 hours, before the new key is used for signing. The previous key remains active until then; another rotation cannot start while one is in progress. Read the state again and check a new external message after the indicated change. The 96 hours describe Microsoft's procedure; they are not a general DNS or DKIM waiting period or a completion time measured here.
When moving from 1024 to 2048 bits, the first rotation updates only the selector that becomes active next. Microsoft describes a further rotation after completion to update the other one as well. Therefore, check both Selector…KeySize values. Do not prematurely delete a required CNAME or manually replace a key managed by Microsoft. This guide does not establish a universal deletion deadline for older messages that still matter or for DNS caches. A suspected key incident requires a separate response.
Match the observation to the next check
On narrow screens, scroll the table sideways.
| Observation | Next check |
|---|---|
CnameMissing | Compare both names and target values, the active DNS zone and Microsoft's detection status. Do not invent a target or blindly repeat activation. |
Older onmicrosoft.com target | Compare it with the current values for the existing domain; do not replace it solely because a new format is documented. |
| Only one CNAME is present | Publish the second required record as well; two DNS names still do not prove that a rotation has completed. |
dkim=none on an internal message | Check a suitable external sending route before classifying the domain as misconfigured. |
Signature present, but fail | Compare the key, selector and recipient diagnostics; changes by a gateway or changes to content are possible causes, not an established diagnosis for this case. |
| Exchange Online message passes, another service does not | Configure the additional sending service separately and check its own message. |
| A 1024-bit key remains after rotation | Check rotation status and both key lengths; plan a further rotation only after the first has completed. |
An error can have several causes. This table offers reasoned checks, not a ranking based on measured frequency. Disabling signing is not a general repair step for an unclear signature result.
Choose DNS, a message or a documented finding
The Email Security Check examines the public domain configuration and a limited set of discoverable or supplied DKIM selectors. Finding none does not prove that DKIM is absent. Finding a key does not prove active Exchange Online signing. The DNS check does not read messages or automatically monitor later changes.
The free German test email beta with its limited initial eligibility and scope is available through the email check for a new message of your own. Check the conditions stated there. Private test email findings and the public domain assessment remain separate. A complete English functional flow is not currently enabled.
If you need a document after a change, the report overview explains the respective documented scope. Keep the DNS observation time, domain/selector, administrative status and observed message separate. Such a finding is not a complete audit, delivery or compliance assessment. This guide does not offer a purchase flow.
Frequently asked questions
Do I have to calculate new CNAME targets myself?
No. Use the values supplied for your specific domain by the portal or Get-DkimSigningConfig. The new format includes a dynamic component assigned by Microsoft. A copied target from another tenant is not a substitute.
Are both selectors active at the same time?
Microsoft describes one active selector and one intended for a change. Two visible CNAMEs do not tell you which key signed a particular message. Read the message findings and administrative status to establish that.
Does Microsoft 365 also cover my newsletter service?
Using the same visible From domain is not enough. The actual signer at the additional service needs that service's own configuration. Check the service and its sending route separately.
Further guides
DKIM fundamentals, general setup, SPF and DMARC explain the individual pieces of evidence.
Another DKIM guide: Google Workspace
Sources and verification limits
Microsoft: DKIM for custom domains, New-DkimSigningConfig, Rotate-DkimSigningConfig, RFC 6376, RFC 8301, Resolve-DnsName.
Also checked for the distinction between reading and changing: Get-DkimSigningConfig and Set-DkimSigningConfig.
Primary sources checked on 29 September 2026. Microsoft's main guide gives 3 July 2026 as its update date. No tenant was opened, no DNS or signing configuration was changed, and no message or rotation was tested in practice at Microsoft. The local signature tests in the general DKIM guide do not prove Exchange Online activation or delivery. The provider commands have not been run here; the interface, permissions and state must match the specific environment.