Why a failing DKIM check can signal a man-in-the-middle attack
Email authentication failures are often treated as routine delivery problems. A sender may have published the wrong DNS record, rotated a key without updating its mail service, or forwarded a message through infrastructure that did not preserve its signature. Yet a failed DKIM check can also indicate that a message was altered while traveling between systems.
A man-in-the-middle attack occurs when an attacker intercepts communication and inserts, removes, or changes data before it reaches the recipient. In email, that could mean modifying payment instructions, replacing an attachment, changing a login link, or redirecting a conversation to an attacker-controlled mailbox.
DKIM, or DomainKeys Identified Mail, cannot prove that a message is safe by itself. It does provide valuable evidence about message integrity and sender authorization. When the signature fails unexpectedly, recipients should treat the result as a signal to investigate rather than dismissing it as a technical nuisance.
What DKIM actually verifies
A sending domain uses a private cryptographic key to sign selected parts of an email. The recipient retrieves the matching public key from the domain’s DNS records and uses it to verify the signature. If the signed content remains unchanged and the correct key is available, the check passes.
The signature usually covers important headers and the message body, though the exact fields depend on the sender’s configuration. A modified subject line, recipient header, body, or attachment-related content can invalidate the signature. DKIM also identifies the signing domain, which allows receiving systems to compare it with the visible From domain through DMARC alignment.
How interception can break the signature
An attacker positioned between a mail server and a recipient may alter a signed message after it leaves the legitimate sender. The recipient’s system then calculates a different hash from the received content, causing a DKIM body hash mismatch or signature verification error.
Interception does not always require control of an internet backbone. A compromised mail gateway, malicious proxy, hijacked cloud account, unsafe Wi-Fi environment, or infected endpoint can provide an opportunity to tamper with traffic. Attackers may also relay a message through unauthorized infrastructure that rewrites headers or content.
A failed check is evidence of a change or verification problem, not automatic proof of a man-in-the-middle attack. The same outcome can result from a legitimate mailing list, content-filtering gateway, email forwarding service, expired DNS key, or incorrect selector configuration.
Warning signs beyond a failed check
The surrounding authentication results provide essential context. A DKIM failure combined with SPF failure, DMARC failure, or a suspicious Return-Path deserves more attention than an isolated DKIM error. Differences between the visible From address, signing domain, and reply-to address can reveal impersonation or account takeover.
Review the message headers for unexpected hops, unfamiliar sending IP addresses, unusual timestamps, and authentication results added by multiple systems. A sudden change in the DKIM selector, a new DNS provider, or a signature from a domain unrelated to the organization may indicate configuration abuse or infrastructure compromise.
Before accepting a file or acting on a request, use a domain trust check to examine the sender’s reputation and authentication posture. This is especially important when the email asks for credentials, financial transfers, confidential documents, or urgent changes to account details.
Distinguishing misconfiguration from tampering
Start by comparing the failed message with a known-good message from the same sender. Check whether both use the same selector, signing domain, sending service, and header structure. If only one message fails after passing through a particular gateway, that gateway may be rewriting signed content.
Domain owners should inspect DNS records, key length, selector rotation, signing coverage, and the configuration of every outbound email platform. A stale public key can cause failures even when the private key is functioning correctly. Mailing lists and forwarding services may also need ARC or specialized rewriting controls to preserve authentication context.
For recipients, message-level evidence should be combined with domain-level evidence. Reputation checks, DMARC policies, certificate details, and recent DNS changes can help establish whether the failure is isolated or part of a broader attack pattern.
| Signal | Likely meaning | Recommended response |
|---|---|---|
| DKIM fails, SPF and DMARC pass | Content rewriting or signing mismatch | Verify the sending path and message changes |
| DKIM and DMARC fail | Possible spoofing, outage, or interception | Pause sensitive actions and validate independently |
| Unknown selector or signing domain | Unauthorized or misconfigured infrastructure | Inspect DNS and contact the sender through a trusted channel |
| Authentication passes but links or files look altered | Endpoint or account compromise may be involved | Scan content and confirm the request out of band |
Building stronger protection around email
A robust email defense uses layered controls rather than relying on a single pass or fail result. Publish SPF, DKIM, and DMARC records correctly, enforce alignment, monitor aggregate reports, and use a policy that limits unauthorized messages. Organizations should also protect DNS accounts and mail-platform administrator credentials with multifactor authentication.
Brand protection extends beyond the primary domain. Lookalike domains, forgotten subdomains, abandoned cloud services, and poorly configured third-party senders can all be used in phishing campaigns. A comprehensive domain trust strategy helps security teams identify weak points before attackers exploit them.
Practical steps for investigation
- Preserve the original message, including complete headers and attachments, instead of forwarding it normally.
- Compare the DKIM selector, signing domain, SPF result, DMARC alignment, and delivery hops with a trusted message.
- Confirm payment, credential, and file requests through a separate channel already known to be legitimate.
- Review DNS, mail gateway, identity-provider, and endpoint logs for changes near the delivery time.
- Use domain reputation and authentication tools to check whether the sender’s trust profile has recently changed.
Security teams should document recurring failures by sender, route, selector, and gateway. Patterns can expose a broken integration, a compromised mailbox, or a targeted interception attempt. Automated monitoring through bulk checks, developer tools, or an API can make that analysis practical across many domains.
When a DKIM failure appears alongside unusual routing or a high-impact request, do not approve the message based on its appearance. Check the complete authentication context, validate the sender independently, and use Trusted Sender Score to investigate the domain before trusting its content or acting on it.