SPF/DKIM/DMARC is just plain hostile. I spent hours learning all that. And now it turns out that even if I "include:mail.community.recurse.com" in my SPF record, mail with SMTP FROM mail.community.recurse.com still gets rejected. WTF.
Conversation
Bringing security to existing ecosystems is delicate. All user pain must be:
1) aggressively minimized (by design, tooling or tradeoff)
2) justified by a security gain (more concrete the bigger the pain)
3) effectively communicated (if you do x, you get benefit y)
1
6
28
DMARC is failing one of these, even though I don't know for sure which.
And the consequence is that, being an user after all, I'm just disabling it. Alas.
4
7
Replying to
Ha, if you look through my Twitter feed I discussed this in detail a few months ago… Google, for example, expects you to recurse their include: statements but does not do it to yours, same for others.
SPF & DMARC, which are a good idea, turned into weapons to force you to borg.
2
2
3
DMARC passes based on either aligned SPF or DKIM so you can omit SPF entirely and have working DMARC. Your emails should all be passing based on DKIM alone. DKIM is the proper way to do it since the mails can be forwarded around and can have non-oversigned headers added too.
SPF is a legacy thing which doesn't really work properly. It can be used to pass DMARC but there's never really a case where you should need it to pass.
SPF itself will pass as long as MAIL FROM passes SPF and just won't contribute to passing DMARC if it doesn't pass for FROM.