Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I wish there was some way to evolve the DMARC spec such that only DKIM and not SPF is used for validation. Sadly things like Google Calendar invites still fail DKIM…


The next release of DMARC will likely include an option to exclude SPF from DMARC verification. Google's team is pushing for this on the IETF DMARC mailing list:

https://mailarchive.ietf.org/arch/msg/dmarc/PDktxOYkB28k6ukL...

We think this is a very good idea as it will allow domain owners to use DMARC but specify that they prefer DKIM to be the only mechanism that truly authenticates traffic as their own.

The industry has many workarounds for the weaknesses of SPF and DMARC, such as using SPF macros to dynamically shape authentication based on criteria one only knows at the time of SPF resolution, but none of these workarounds is better than just saying, "DKIM only for my domain, please."


I would love this. Right now I am running a service that sends email. For cost reasons I try to do this directly. It works surprisingly well even from cloud-provider IP addresses. Most providers quickly learn to trust my domain. But there are some big players that have an outright block on public cloud ranges (notably Microsoft and Apple). I end up needing to use a relay for these, but I would prefer not to give the relay a DKIM key or allow it to munge my messages.

This mostly works today, for example SES allows the origin to sign messages (although as of a few months ago I started hitting an SES bug where they modify a header field that they said they wouldn't, breaking the signature) and there are a few other providers that allow this capability as well.

However I basically still need to mark them as trusted in the SPF record otherwise the spam score goes up. This effectively allows them to spoof messages from my domain. I would love to close off this loophole.

It also isn't great with sending from public cloud VM instances either since I have to update the SPF record with the changing IPs and DNS caching can cause false fails (if a new instance sends mail before the cache is refreshed) and false passes (if the old IP gets reused for a different customer before the cache expires).

Yeah, I know. I should just rent a public IP. But that raises costs and would require me to raise my prices. Especially at the current small scale.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: