Exchange Online: DKIM uses onmicrosoft.com instead of custom domain

Question

Exchange Online: DKIM uses onmicrosoft.com instead of custom domain

Nguyễn Thành Nhân 0

We have an Exchange Online tenant using example.com as a custom domain.

An outbound email has the following headers when it first reaches our email gateway:

From: [email protected]

DKIM-Signature: d=example.onmicrosoft.com; s=selector1-example-onmicrosoft-com;

However, Microsoft's ARC-Authentication-Results in the same message shows:

dkim=pass header.d=example.com; dmarc=pass header.from=example.com;

The email is captured at our gateway immediately after being sent from Microsoft 365, and the DKIM signature is already d=example.onmicrosoft.com.

This causes a potential DMARC alignment issue for downstream mail servers. If a receiving server enforces a strict DMARC policy, the onmicrosoft.com DKIM signature does not align with the visible example.com From domain. As a result, DMARC may fail and the message can be classified as spam or rejected, depending on the receiving domain's policy.

Why does Exchange Online report DKIM authentication for example.com in the ARC results, while the actual outbound DKIM signature uses example.onmicrosoft.com?

Is this expected behavior, or should DKIM for the custom domain example.com be enabled/configured differently?

0 comments

2 answers

Your answer

Answer 1

Hi @Nguyễn Thành Nhân

The AI-generated answer provides helpful information and correctly explains that Microsoft 365 may sign mail with the *.onmicrosoft.com domain if DKIM is not enabled for the custom domain. It also provides appropriate guidance to verify the DKIM configuration using Get-DkimSigningConfig.

However, I would suggest a minor adjustment: while a DKIM-Signature of d=example.onmicrosoft.com can be expected when custom-domain DKIM is not enabled, the documentation does not specifically explain why ARC-Authentication-Results shows dkim=pass header.d=example.com while the visible DKIM signature uses example.onmicrosoft.com. Therefore, reviewing the complete message headers and confirming the DKIM configuration for example.com would be recommended before drawing a final conclusion.

Please try running the PowerShell to verify the status:

Get-DkimSigningConfig | Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME

Answer 2

Yes, this is expected if DKIM signing for the custom domain is not enabled and Microsoft 365 is signing with the tenant’s *.onmicrosoft.com domain instead.

Key points:

*.onmicrosoft.com is signed by default
- Microsoft 365 signs outbound mail for the initial *.onmicrosoft.com domain by default.
- No public DNS DKIM CNAME records are required for that Microsoft-managed domain.
Custom domains require separate DKIM configuration
- For a custom domain such as example.com, DKIM signing needs to be enabled for that domain.
- This requires publishing the two DKIM CNAME records for the custom domain and then enabling DKIM signing.
- To verify the current state, run:
```
     Get-DkimSigningConfig | Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME
```
- If the custom domain shows Enabled: False and Status: NoDKIMKeys or CnameMissing, create the required CNAME records and then enable DKIM:
```
     Set-DkimSigningConfig -Identity example.com -Enabled $true
```
DMARC alignment requires DKIM for the From domain
- Microsoft’s guidance for combined authentication failures is to enable DKIM signing for the From address domain because DKIM alignment provides the aligned pass that DMARC needs.
- If mail is signed only with example.onmicrosoft.com, that DKIM domain does not align with From: [email protected].
Why ARC can show dkim=pass header.d=example.com
- ARC preserves authentication results.
- The provided context supports ARC as a mechanism that preserves authentication results through message modification, but it does not document a case where ARC reports header.d=example.com while the visible outbound DKIM-Signature is d=example.onmicrosoft.com.
- The supported conclusion is that the actual DKIM signature used for downstream DMARC evaluation is the one in the message headers. If that signature is d=example.onmicrosoft.com, then custom-domain DKIM for example.com should be checked and enabled if the goal is aligned DKIM for example.com.
What to do next
1. In Exchange Online PowerShell, check whether example.com appears in Get-DkimSigningConfig.
2. If needed, retrieve the exact Selector1CNAME and Selector2CNAME values for example.com.
3. Publish those two CNAME records in DNS for example.com.
4. After DNS propagation, enable DKIM for example.com:
```
      Set-DkimSigningConfig -Identity example.com -Enabled $true
```
5. Send a test message to an external mailbox and inspect headers:
  - Confirm a DKIM-Signature header exists.
  - Confirm d=example.com.
  - Confirm Authentication-Results includes DKIM=pass or DKIM=OK.

If sender and recipient are in the same domain, or in different domains controlled by the same organization, Microsoft 365 can omit the DKIM signature entirely, so testing should be done by sending to an external mailbox in another email system.