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

3 answers

Your answer

Answer 1

Thanks for the clarification.

I don't have administrative access to the sender's Exchange Online tenant. I operate the email gateway on the forwarding path and am investigating a DMARC alignment issue observed downstream.

From the message headers we captured when the email first reaches our gateway, we see:

From: [email protected]

DKIM-Signature:

d=example.onmicrosoft.com

This DKIM signature authenticates successfully, but it does not align with the visible From domain example.com.

After the message is forwarded through our gateway, we use SRS, so SPF also passes authentication but the envelope sender uses our gateway domain. Therefore, SPF is no longer aligned with the original From domain either.

As a result, downstream receiving servers that enforce DMARC strictly can evaluate the forwarded message as DMARC fail and may quarantine it as spam or reject it.

We understand that signing with the onmicrosoft.com domain may be expected if DKIM for the custom domain is not enabled. However, we would like to understand whether there is a recommended configuration on the Microsoft 365 sender side that would allow the outbound message to carry a DKIM signature aligned with the custom From domain.

Could you please confirm:

Is DKIM for the custom domain required/enabled on the sender's Microsoft 365 tenant to achieve DKIM alignment?
If it is enabled, why would the outbound message still contain d=example.onmicrosoft.com?
Is there any Microsoft-recommended approach for forwarded messages where SPF alignment is lost due to SRS, so that DMARC can still pass through downstream receiving servers?

Answer 2

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 3

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.