Inbound emails failing DKIM checks on Microsoft Exchange Server 2019 typically stem from missing or invalid signatures in the message headers, rather than a server-side verification failure. Exchange does not natively reject messages based on DKIM status by default; instead, it logs these events for diagnostic purposes. This guide details how to inspect message trace data and header structures to identify why specific domains are failing validation.
Understanding Exchange Behavior with DKIM
It is crucial to clarify that Microsoft Exchange Server 2019 does not actively validate inbound DKIM signatures as a gatekeeping mechanism for mail acceptance. Unlike some third-party gateways, Exchange will accept mail regardless of whether the DKIM signature is present, valid, or tampered with. If you are observing "failed" checks, this usually refers to external monitoring tools, spam filters placed before Exchange, or internal logging mechanisms that flag messages with broken signatures. The confusion often arises because administrators expect Exchange to block spoofed mail automatically. However, without additional configurations like Sender Policy Framework (SPF) or Domain-based Message Authentication, Reporting, and Conformance (DMARC) enforcement at the transport level, Exchange treats all incoming mail as potentially legitimate until further inspection. Therefore, debugging involves looking at *why* the signature is broken, not why Exchange rejected it. For broader context on email authentication protocols, see Preventing Email Spoofing: Implementing SPF, DKIM, and DMARC for Outlook.Inspecting Message Headers Manually
The first step in diagnosing DKIM failures is to examine the raw internet headers of the affected email. You can retrieve these headers directly from the Inbox folder in Outlook or by using the Message Properties dialog. Look for theAuthentication-Results header, which is added by Exchange during transport processing.
This header contains detailed information about the results of various authentication checks. Specifically, look for the dkim= tag. It will display one of the following values:
pass: The signature was found and verified successfully.fail: The signature was found but did not verify correctly, often due to modification of signed headers or an incorrect public key.none: No DKIM signature was detected in the message.
fail, the issue lies within the sending domain's configuration or the message content itself. If the value is none, the sender has not configured DKIM, or their mail server is stripping the signature. To understand how authentication impacts user experience, review Troubleshooting MS Outlook Authentication Issues.
Using Message Trace Data
For a more systematic approach, use the Exchange Management Shell to run a message trace. This allows you to query logs for specific domains or senders over a defined time period. Run the following command to trace messages from a specific domain:Get-MessageTrace -SenderAddress @domain.com -StartDate (Get-Date).AddDays(-7) -EndDate (Get-Date)Enabling Detailed Logging
To capture deeper insights, enable protocol logs on the Receive Connectors. This provides a raw view of the SMTP conversation, including the actual DKIM headers received. Navigate to the Exchange Admin Center, go to Mail Flow > Receive Connectors, and select the connector accepting external mail. Enable Protocol Logging under the General tab. After receiving a test message, analyze the log files located in the%ExchangeInstallPath%TransportRoles\Logs\ProtocolLog\SmtpReceive directory. Search for the session ID associated with the failed message to see the exact headers transmitted by the sender.
Verifying DNS and Public Keys
A common cause of DKIM failures is an inability of the recipient’s system to resolve the public key. Although Exchange doesn’t enforce this, verifying the DNS record helps confirm if the sender’s setup is correct. Use a DNS lookup tool to query the TXT record for the DKIM selector. The format is typicallyselector._domainkey.domain.com.
Ensure that the public key published in DNS matches the private key used by the sending mail server. Mismatches here result in immediate verification failures. Additionally, check that the selector name in the email header matches the DNS record exactly. Case sensitivity and typos in the selector name are frequent sources of error.
Common Causes of Signature Breakage
Even if the initial signature is valid, it can fail verification if the message is modified after signing. Common culprits include:- Line Ending Conversion: Changing CRLF to LF or vice versa can invalidate the signature.
- Header Rewriting: Adding or modifying headers such as
X-PriorityorReply-Toafter signing breaks the cryptographic hash. - Body Modification: Any change to the message body, including whitespace additions, will cause a failure.
Frequently Asked Questions
Does Exchange Server reject mail if DKIM fails?
No, Exchange Server 2019 does not automatically reject inbound mail based on DKIM verification results. It accepts the message regardless of the signature status unless other policies, such as IP allow/block lists or anti-spam filters, intervene.
How can I see if a specific domain is failing DKIM?
You can check the Authentication-Results header in the source of any received email from that domain. Look for the dkim=fail tag to confirm that the verification process detected an issue with the signature.
What should I do if the DKIM signature is missing entirely?
If the dkim=none tag appears, the sending domain likely has not configured DKIM. Contact the administrator of the sending organization to help them set up DKIM keys and update their DNS records.
Can line endings cause DKIM verification to fail?
Yes, changing line endings between carriage return line feed (CRLF) and line feed (LF) after the message has been signed will invalidate the signature. Ensure that the mail transport layer preserves the original formatting.
Is there a way to force Exchange to log DKIM details?
While Exchange does not have a dedicated "DKIM Log," enabling Protocol Logging on Receive Connectors captures the raw SMTP transaction, including all headers sent by the client, allowing you to manually inspect DKIM presence and structure.