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.
