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

4 answers

Your answer

Answer 1

Nguyễn Thành Nhân 0

Hi i had uploaded the EML again, please check if possible. Thanks team!

Jayden-P 3,795 Reputation points Independent Advisor

2026-10-12T07:27:28.61+00:00

This is the public forum, not Microsoft support team, I am a normal forum user, I do not have access to back end system to check it for you.

This action will require Microsoft support team, please open a support ticket with them to investigate further,

Answer 2

Nguyễn Thành Nhân 0

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?

Jayden-P 3,795 Reputation points Independent Advisor

2026-10-04T22:46:04.5866667+00:00
To achieve DKIM alignment for From: [email protected], the sender's Microsoft 365 tenant must have DKIM configured and enabled for example.com. If DKIM is not enabled for the custom domain, Exchange Online can sign using the tenant's *.onmicrosoft.com domain instead.

Microsoft's documentation confirms that a message can contain multiple DKIM signatures and that hosted services may sign using both the service domain and the customer domain. However, the documentation provided does not specifically explain a scenario where ARC reports header.d=example.com while the visible outbound DKIM signature is only d=example.onmicrosoft.com. Reviewing the complete message headers and verifying the sender's DKIM configuration would be necessary to determine why this occurs.

Microsoft recommends configuring trusted ARC sealers or Enhanced Filtering for Connectors in forwarding scenarios because forwarded messages commonly fail DMARC when forwarding breaks SPF. Microsoft also states that DMARC requires either SPF or DKIM to pass and align with the From domain. Therefore, enabling DKIM for the custom domain (example.com) can help maintain DMARC compliance when SPF alignment is lost during forwarding or SRS rewriting, while ARC can preserve authentication results across forwarding hops.

References:

How to use DKIM for email in your custom domain

Troubleshoot email authentication in Microsoft 365
Jayden-P 3,795 Reputation points Independent Advisor

2026-10-06T14:07:45.39+00:00

Have you checked the provided answer? Any update would be great.
Deleted

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Answer 3

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 4

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.