Hacker News Reader

Comment by peanut-walrus | Hacker News Reader

Missed 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.

View on HN

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...

In theory, yes, in practice this will currently result in deliverability issues, both for servers which don't speak dmarc and for spam signals. I have tried this :)

If this mode of operation was an explicit choice, this would give me the option to have a fallback SPF record for legacy mail systems, but most up-to-date servers will use the more secure and (for my use case) operationally simpler verification.

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.

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.

> Isn’t that already what DMARC does though? For DMARC to pass you need DKIM _or_ SPF alignment, not both.

But now if SPF passes and is aligned, DMARC passes (it doesn't matter what DKIM's status is). OP here wants to complete skip the SPF check entirely.

> Isn’t that already what DMARC does though? For DMARC to pass you need DKIM _or_ SPF alignment, not both.

GP wants require DKIM, so SPF alone is insufficient to send mail from their domains.

If everyone did dmarc, you could set SPF to -all. But there are servers that check SPF but not DMARC. You need to pass SPF for those, so you need a passable SPF... but then DMARC will pass with only SPF.

>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"

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.

Reply on news.ycombinator.com