Käyttäjän työkalut

Sivuston työkalut


Tämä on vanha versio dokumentista!

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.

Please look at DKIM and better multi-factor email filtering solutions instead.

SPF does not protect against spam

  • SPF does not protect against SPAM
  • SPF does not even try to do anything against SPAM
  • SPF might accidently block some SPAM, but that is not its purpose
  • SPF is trying to protect your service against spoofing attacks, i.e., someone claiming to be you and sending emails on your name.

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.

Most people would probably be surprised how many internet users for example forward their emails, either to

  • permanently to read in a single mailbox, or
  • temporarily to their mobile address while traveling, or
  • use an email forwarding service as their permanent main address.

The SPF people have a clunky 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 adminisrators (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.

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.

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.

More information

faq/dmarc_spf_considered_harmful.1513687588.txt · Viimeksi muutettu: 2017-12-19 12:46 / haa