Tämä on vanha versio dokumentista!
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.
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.
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.
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
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).
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
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.
More information (in Finnish) at