Controversy around SPF

When E-Mail was documented in 1982, E-Mail was meant to be decentralised. The uprise of ISPs, such as Yahoo, Hotmail and Gmail, a few decades later, has defeated this purpose.

Big ISPs tend to store all their IPs in a single SPF record. Customers who use their own domain for sending are instructed to add an include to this SPF record to their own domain. This way, all domains sending via - for example - Gmail have all Gmail IPs included in their SPF record. Impersonating a Gmail customer's domain on a Gmail SMTP connection would principally result in SPF pass. Most ISPs - also Gmail - have security measures in place to prevent their users from sending with any domain the are not authorised to send with, but security researchers have recently been able to circumvent those measures.

Because DMARC requires SPF or DKIM alignment to pass, this discovery also compromises the security of the DMARC protocol. And because BIMI depends on DMARC, also BIMI can't be trusted anymore on big ISPs plattforms as long as this issue hasn't been solved.

Mailchannels

One extreme example of an ESP that doesn't limit users to sending with their own domains is Mailchannels. Mailchannels is one of the larger senders. Yet - as of September 2023 - they facilitate impersonation of unauthenticated domains as if it were a feature and, according to their CEO, they have no intention to stop doing so. After the company was exposed on DEFCON 31 (2023), Mailchannels developed a feature named "Domain Lockdown". Mailchannels customers now actively have to set an additional DNS TXT record in order to limit abuse of their own domain.

Mailchannels customers are usually instructed to set an SPF include that includes all Mailchannels IPs. Combined with the allowance of domain spoofing, this renders all SPF-verifications in mail from those IPs useless. This shows again how severely the weakness in SPF can compromise DMARC and BIMI.

ARC

The exposure video from DEFCON also showed another interesting fact: ARC headers may be trusted over inhouse authentication results and so the usage of ARC poses more of a security threat, than a remedy against bad mailing practices. Wikipedia states:

Validating an ARC chain only makes sense if the receiver trusts the ARC signers. In fact, an ARC chain can be counterfeited, so ARC processing applies when receivers trust the good faith of ARC signers, but not so much their filtering practices.

Conclusion

As long as this situation remains as it is, DKIM is the authentication method that's least compromised. ARC headers should explicitly be entirely ignored.

Useful links

• ARC
• How to enable Domain Lockdown
• DEFCON 31 presentation "Spoofing Emails From 2M+ Domains & Virtually Becoming Satan"