SEMblog

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.

At the end of last month I dealt with a mail delivery issue that is becoming increasingly common as organisations enable DMARC enforcement.

A user at a client reported that an important email was being quarantined by their spam filter. The messages could be manually released and the sender was even added to the allowed senders list, but it made no difference — the messages continued to be blocked.

The quarantine reason reported DMARC failure.

As organisations increasingly deploy DMARC to improve email security, configuration mistakes are becoming more visible. One of the most common is enabling a DMARC policy without properly configuring SPF or DKIM authentication. When that happens, legitimate email can be quarantined or rejected by receiving mail systems that are simply following the sender’s published policy.

Understanding What Happened

The sending organisation had enabled a DMARC policy of quarantine. This instructs receiving mail systems to treat messages as suspicious if they cannot be authenticated as coming from an authorised sending source.

In principle this is good practice. DMARC helps prevent spoofing and improves the overall trustworthiness of email.

However, the sender had not completed the configuration required to support the policy they had enabled.

They were using Google Workspace for email, but their domain did not have an SPF record published at all.

This meant that when a receiving mail system checked authentication it saw:

• No SPF record
• No validated sending source
• DMARC policy instructing quarantine

From the receiving system’s perspective the message could not be authenticated, so the policy published by the sender’s own domain was applied.

The spam filter was simply following instructions.

Why Whitelisting Didn’t Help

A common response when email is blocked is to ask the recipient to whitelist the sender.

However, when DMARC enforcement is being honoured, authentication failure takes precedence. If a domain’s policy instructs receivers to quarantine unauthenticated mail, most modern mail security systems will comply with that policy.

In other words, this was not a spam filtering problem.

It was an authentication configuration problem.

The Fix

The technical fix was straightforward: publish the correct SPF record as recommended by the mail provider (in this case Google).

Once the SPF record was created, the sending source could be authenticated correctly. With authentication passing, the DMARC policy was satisfied and the messages were delivered normally.

How DMARC, SPF and DKIM Work Together

DMARC does not authenticate email on its own. Instead, it relies on SPF and DKIM to verify the sending source. If neither mechanism passes and aligns with the sending domain, the DMARC policy determines how the receiving system should handle the message.

Why These Issues Often Go Unnoticed

It is quite possible that the sending organisation had been experiencing similar delivery problems with other recipients without realising it.

Unless someone reports the issue, problems like this can persist quietly for months, causing friction between suppliers and customers.

In this case, because of the close relationship with my client and someone on the sender’s side keen to resolve the issue, the correct fix was implemented rather than relying on a temporary workaround.

A Reminder About DMARC Configuration

Major mail providers such as Google, Yahoo and Microsoft have tightened sender requirements in recent years. Proper authentication is increasingly expected for reliable email delivery.

If DMARC is enabled, the underlying authentication mechanisms must also be correctly configured. At a minimum this usually means:

• A valid SPF record
• DKIM signing enabled
• Alignment between authentication and the sending domain

Enabling a DMARC quarantine or reject policy before those pieces are in place can easily lead to legitimate mail being blocked.

Sometimes the spam filter isn’t broken — it is simply doing exactly what the sender’s domain asked it to do.