DMARC and SPF considered harmful

DMARC and SPF break many long-time common email usage patterns like forwarding and mailing lists.

Email is valuable because the user is in control, and these methods try to restrict what the user can do and lock-in the user to their ISP email account.

The value of DMARC and SPF in fighting spam and domain misuse is also very limited and short lived, as the spammers very quickly adapt, so the end result is just to break email for many users without getting much in return.

Many internet users forward their emails

temporarily forward emails to their mobile address while traveling, or

use an email forwarding service as their permanent personal address (e.g. university alumni addresses such as alumni.mit.edu, professional organisations such as acm.org or ieee.org, iki.fi, and many others).

Using the power of email like this is more common for experienced users, thought leaders and high value contacts and customers making it important that you consider the reliability of your email reaching the recipients.

"Fixes" that break things

There have been many projects that claim to fix email which do not take into account the many and varying ways people use email in the real world. The flexibility of the non-centralized email infrastructure is a major reason why email has been and is so successful, and many of these proposed schemes only work for those users who are locked into a single email provider with no flexibility.

Spammers quickly adapt their behaviour to work around any new limitations or filtering methods, so you may end up breaking lots of legitimate email for very little benefit in the end.

Unfortunately the non-centralized email infrastructure does also leave room for spam and other problems. These are pretty well under control using modern filtering tools which use multiple matching criteria to evaluate messages.

Using DMARC with "reject" will prevent many people from receiving your emails

If you set up DMARC with ”reject” you're in effect saying you don't want email from you to be delivered reliably. Same is true for dropping incoming messages based on DMARC or SPF alone, you're saying you don't want your users to receive some of their real emails.

Using -all SPF causes many people to not receive your emails

For domain administrators (sending side)

Usually the instructions for SPF say you should use the ”-all” setting. This is misguided.

Please keep in mind that SPF is not compatible with many traditional ways people use email, e.g. forwarding emails or mailing lists.

Especially if you use the strict -all setting, you will experience your own real emails not being delivered to many recipients, as the email arrives via the forwarding email server(s) instead of the original server and thus may not pass a SPF -all check at the final recipient mailbox.

The SPF people have a clunky proposed workaround (envelope address rewriting) for some of these issues, but expecting everyone else on the internet to change to accommodate me will not happen, so you should use at most the ~all setting with SPF for your own domain (SPF ~all means SoftFail, i.e. accept but mark instead of reject).

For email administrators (receiving side)

If you run an email server, you should similarly not block incoming email only based on any single reason, including the ”SPF -all” check, but use SPF as one of multiple scoring methods. Otherwise your users will lose real email sent by organisations who have mistakenly configured their SPF with -all.

For users receiving emails

If you can not receive emails you need because of too tight filtering at your email provider, one solution is to use a email provider who works better, e.g. gmail.com

If you are an iki.fi member, you can configure iki.fi to forward your email to multiple addresses, and add e.g. gmail.com backup email address, where you can look for messages dropped by the misbehaving email provider.

Automated emails and SPF

SPF could be used in cases where you have automated systems sending emails and where users have easy ways of changing those addresses [i.e. not using the email they registered with], as then users can make the address go to some place which do work with SPF.

You should never force normal users normal emails to have SPF records, instead make sure your automated emails are sent from different subdomain and that subdomain have proper SPF records. This means that everybody sending from that special subdomain agrees on their emails being blocked when going through email forwarding service.