DMARC enforcement revisited

This is a follow-on from DMARC Fail but mail ends up in Inbox

As far as I can see, all the major email providers (in particular gmail and yahoo) do enforce when p=reject, as I would expect them to, and it’s annoying when receivers don’t bounce fake messages that claim to be from my domains when I’ve gone to all the effort of DKIM signing and using DMARC. I can’t think of any reason why a domain that’s gone to the effort of configuring p=reject would ever want forged messages not to be rejected. It’s not as if it would affect anyone else. It’s as bad as allowing TLS certs validation failures.

For now I’ve manually enabled DMARC rejections in /etc/opendmarc.conf, as @ravenstar68 suggested, so I’ll see how it goes – and I’d encourage others to do the same so that we can get more empirical data about this.

While looking into this behaviour I went looking for a test suite, like badssl.com does for TLS, and found http://emailspooftest.com (forwarded from baddkim.com) which has a DKIM/SPF/DMARC delivery test system. Aside from their unforgiveable lack of https, this is actually quite cool. They send 5 pairs of emails, each with a specific contravention of either DKIM, SPF, or DMARC, so that you can test how a receiving server deals with them. With my MIAB, 6 messages made it through, all to the inbox, none in spam. It’s a shame it’s not open source, though given that it is very slow and appears to be hosted on a Windows 2000 server, I’m not sure I want to see what’s in there!

1 Like

I also updated opendmarc for RejectFailures true, and adjusted the TXT record to reject spoofs. This took my 4/10 emails to 1.

I’m still getting “Email 3”, which says that the server isn’t rejecting mail that fails SPF checking. Not entirely sure how to mitigate that - it seems that SpamAssassin is supposed to consider SPF records (loadplugin Mail::SpamAssassin::Plugin::SPF is active), but it doesn’t seem to be executing.

This topic was automatically closed after 61 days. New replies are no longer allowed.