Following on from a recent issue with DMARC failures caused by missing SPF, I ran into a slightly different – and increasingly common – problem.
A client reported that emails from a supplier were being quarantined by their email filtering platform. The messages could be manually released, but even after adding the sender to the allowed senders list, the issue continued.
The quarantine reason pointed to DKIM failure.
What the headers showed
Reviewing the message headers revealed the following:
- SPF: pass
- DKIM: fail
- Mail routed through a third-party relay service before delivery
At first glance, this might look like a simple DKIM configuration issue. However, the presence of a DKIM signature tells a different story.
DKIM was present – but invalid
In this case, the sending domain was signing outbound email correctly. The DKIM signature was present in the message headers.
However, by the time the message reached the recipient, the signature no longer validated.
This typically indicates that the message was modified after it was signed.
Why DKIM breaks
DKIM works by generating a cryptographic hash of selected message headers and the message body. That hash is then signed using the sender’s private key.
When the receiving system checks DKIM, it recalculates the hash and compares it to the original.
If anything in the signed portion of the message has changed, the hashes no longer match and DKIM fails.
Common causes of this include:
- Disclaimer injection
- Outbound spam filtering or relays
- Message reformatting
- Link rewriting or tracking additions
In this case, the message passed through multiple systems before delivery, making it highly likely that one of them altered the message after it had been signed.
Why whitelisting didn’t help
A common reaction in situations like this is to add the sender to an allowed list.
However, modern email filtering systems do not simply bypass authentication checks because a sender is trusted.
If DKIM fails, the system has to assume the message may have been altered or tampered with in transit.
As a result, the message is still treated as suspicious, regardless of allow list entries.
In other words, the system is behaving correctly.
The key takeaway
This was not a case of DKIM being missing or incorrectly configured at the source.
Instead, DKIM was broken in transit.
This is an important distinction, because it shifts the responsibility from DNS configuration to mail flow design.
If outbound email is being modified, then one of the following needs to happen:
- The original message must be preserved so the DKIM signature remains valid
- The message must be re-signed with DKIM after modification, using the correct domain alignment
Without this, email authentication will fail, and receiving systems will increasingly reject or quarantine those messages.
Final thought
Email authentication controls do not operate in isolation.
SPF, DKIM and DMARC all interact with each other, and with any systems that touch the message in transit.
Adding security layers without considering how they interact can easily result in legitimate email being blocked.
And as seen here, the problem is not always that authentication was never configured.
Sometimes, it was configured – but something else broke it along the way.
This is a different failure mode to missing SPF or DKIM entirely — here, authentication was present, but invalidated during transit.
