SpamChannel: Spoofing emails from 2M domains and virtually becoming Satan [pdf]
SPF is broken in many more ways than described in this presentation. I work as an email hardening &#x2F; deliverability support engineer and our advice is always to focus on DKIM + DMARC, rather than SPF. You still need SPF for legacy reasons, but it should never be relied on for deliverability or anti-impersonation.<p>Slide 54 says that DKIM + DMARC does not help against this attack, but that is not completely true.<p>If (and only if) you have set up DKIM for all your delegated senders, then (and only then) can you safely enable a DMARC p=reject policy. Once you have reached that level, you can start opting out of SPF for third party senders, by using the &#x27;?&#x27; (neutral) modifier in SPF.<p>So this:<p><pre><code>    v=spf1 include:relay.mailchannels.net ~all
</code></pre>
Becomes this:<p><pre><code>    v=spf1 ?include:relay.mailchannels.net ~all
</code></pre>
This gives emails from MailChannels a neutral SPF stance with DMARC capable receivers, causing them to use DKIM instead. Old legacy email services should still accept neutral results as well.<p>Granted, it is not a perfect solution, but email will never be 100% reliable, or secure anyway.