When our own DMARC filter rejected a customer's invoices

A customer of mine raised a concern that they weren't receiving mails from a specific sender. I immediately checked whether the sender's mail had been quarantined, but no, it looked like the mail had never arrived.

So I started looking into the logs via the Kibana dashboard, and found that the mail had been rejected. Postfix applied a milter reject from OpenDMARC,5.7.1 rejected by DMARC policy.

The root cause was partly on our side. OpenDMARC was configured with the wrong parameters,SPFIgnoreResults=yes andSPFSelfValidate=no, so DMARC was judged on DKIM alone.

I looked up the sender's DNS entries and saw that they had a valid, aligned SPF record, but their DKIM was broken, the signing selector's DNS record was missing, and their domain publishesp=reject. With our DKIM-only evaluation, that broken DKIM was enough to reject every one of their mails, even though their SPF was fine.

"Don't forget the(ISC)² Code of Ethics," I thought, so I also wrote a short mail to the postmaster address of the sender's provider, a friendly heads-up about the broken DKIM I had found on their side.

So I fixed OpenDMARC on our side and setSPFSelfValidate=yes, so that incoming mail can pass DMARC on SPF alignment (RFC 7489). Spoofers still don't get through, they can't produce an SPF or DKIM pass that is aligned to a domain they don't control, so they still fail DMARC.

I got a little nervous, because I thought this might have hit other senders too. But after checking the last 36 days of logs, only 2 wrongly rejected mails for that sender came up, while about 9,300 mails were correctly rejected because they genuinely failed DMARC.

So, the fix did not weaken the filter.

Author:René Zingerle,CISSP,SSCP
Last Update: 10.07.2026