alt Hacker NewsMissed opportunity to get rid of SPF. What I want to my DMARC policy to say: if someone is sending you an email that claims to be from my domain and it's not signed by one of the keys I have published under my domain, you should reject it, regardless where it came from.
And on the receiving side, the policy is similarly simple: if I receive any unsigned or unaligned email, I will reject it.
Edit: to clarify, I want there to be an option where I specify my DMARC policy to explicitly tell well-configured receiving servers "ignore whatever I have configured as my SPF record, only look at the signatures". There will no doubt be a long tail of mail servers where I will still need an SPF record for them to accept my mail.
Edit2: Another feature that I feel is lacking is ability to give dkim selectors a scope - e.g. this key is only valid for these particular From addresses.
Replies
And I want mine to say: if it comes from my MX server it's legit, don't worry about the keys.
Because that's easy and keys and signing are hard.
Best way to go about this is just blackhole SPF so it never passes, then set your DMARC alignment to strict. This approach prevents SPF from satisfying DMARC on the vast majority of providers [1].
[1] https://taejoong.github.io/files/publications/hamza-2026-dma...
I suspect SPF is used because it's cheaper than performing cryptographic checks for each email. A (cached) DNS lookup and IP check on a connection is comparatively cheaper.
>Missed opportunity to get rid of SPF.
> you should reject it, regardless where it came from.
Just don't use it yourself then?
"v=spf1 ?all"
Isn’t that already what DMARC does though? For DMARC to pass you need DKIM _or_ SPF alignment, not both. It’s designed that way because there are scenarios where SPF _can’t_ pass (email forwarding, mailing lists). So a well-configured mail server should accept your email regardless of SPF if DKIM is properly configured.
Re: specific keys for specific usernames: I can appreciate that you wish DKIM allowed for this, and I could imagine it being handy, but that was never the problem DKIM set out to solve — DKIM and SPF are all about be domain.
I’m also not sure it’s a great idea — the sender identity should be under the control of the sender. If you control the domain @foo.com, you could use that ability to assert that an email came from Bob, even if Bob never sent it. Contrast that with Bob signing the email using his own private key.