Phishing and spam are so common that most people have been affected. Many often do manual checks to verify the trustworthiness of these messages. They will try to identify the sender and if it was sent from a domain they expected the message to come from. For example, if you receive a message about upgrading your Excel software you would expect it to come from a domain that ends with @microsoft.com. Unfortunately, if the owner of the domain doesn't take the right precautions, messages from that domain can be sent by spammers and hackers. Such spam are much harder to identify as fraudulent. This is the exact problem we are looking into in this post.
There are two protocols a domain owner can use to prevent this from happening: SFP and DMARC.
SPF stands for Sender Policy Framework, it is in essence an email authentication protocol, in which you can specify what servers you use to send out email. The recipient email server will check this and, if it doesn't match, it won't deliver the email or send it with a warning message.
DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It works on top of SPF and you can use it to instruct receiving mail systems what to do with messages that fail SPF checks. In a nutshell, SPF works without DMARC (although with limitations), but DMARC doesn't work on its own, it needs SPF.
In our data we can see that these protocols are popular. Of the approximately 276 million websites surveyed for this research 69% have implemented SPF. However, we also identify around 85 million domains that don't leverage this basic protection, leaving ample room for improving security.
What can be done to close this security gap?
Registrars could automatically check if all domains in their portfolio use a SPF and notify the domain owners that don't use one to implement SPF.
Also, we believe governments should play an important role by making the use of SPF mandatory policy.