The Anti-Spoofing Setup three Million Domains Got Almost Right

You can do everything right and install the best locks there are, but still leave the door open at night. This is the equivalent to what about three million domains in our records are doing. While SPF, DKIM and DMARC are implemented, they are configured to let malicious mail pass regardless. In this blog post we are going to discuss why their implementation alone is far from enough

From the Beginning - Spoofing, Email Headers, DNS

In the last four years, the implementation of SPF, DKIM, and DMARC has been rising rapidly. Our data shows that in August 2024 only about 2 million domains implemented all three, whereas in 2026 this number has increased to about 18 million. Rightfully so, as they are essential tools to prevent a domain from being spoofed.

Spoofing describes an attack in which a malicious party impersonates a legitimate one by falsifying data. In simpler terms, if you own example.com someone may send phishing emails and put mark@example.com as the return address to appear as if they belong to your organisation. This is possible because emails work like regular mail, as a sender you do not have to write yourself as the sender on the envelope, you can write whichever name you want to. Whoever receives this phishing email will now look at the header of the email and believe your organisation sent it, and click the phishing link.

One important distinction between regular mail and email does exist though. Regular mail lists one sender on its envelope, but email lists two. It has the header, which is the visible FROM: header, and the return-path, which is usually not visible to you. Importantly, those two do not need to be the same (but they are when the email is sent by a legitimate party).

Luckily, to prevent hackers from spoofing, SPF, DKIM, and DMARC have been developed. They each take care of one vulnerability:

SPF – Ensures that the sending server is authorised to send email on behalf of the domain listed in the return-path.

DKIM – Ensures that the email's signed contents weren't altered in transit, using a cryptographic signature tied to the sender's domain.

DMARC – Ensures that the domain in the visible From header aligns with the domain that passed SPF and/or DKIM, and defines the policy (none, quarantine, reject) for email that fails this check.

All three rely on DNS, the Domain Name System. The domain name system is how your computer resolves domains, which means translating a domain name like example.com into the corresponding IP address. It is basically google maps for your computer. Your computer asks it “Where can I find example.com” and the DNS will respond with “At this IP address”. It also has DNS Text, which is just a publicly accessible text file that contains information relevant for SPF and DKIM. That concludes all base concepts needed to understand SPF, DKIM, and DMARC.

SPF - Sender Policy Framework

SPF ensures that the sending server is authorised to send email on behalf of the domain listed in the return-path. Domains that are accessed by a lot of people, like amazon.com or nike.com have multiple servers in place to handle their large demand. If an email is sent to you on their behalf, it is sent from one of many servers, each with their own IP address. The DNS text keeps a list of all their IP addresses. For example, when you receive an email from support@amazon.com SPF prompts your computer to check whether the IP that has sent you this email is listed on the DNS text of amazon.com. If it is, your computer knows that the sender is authorised to send emails in the name of amazon. If it isn’t, your computer can safely assume that it was a malicious party that has sent you this email.

But how should your computer proceed? That is defined in the DNS text, too. An SPF policy is indicated by a “flag”, which is either +all, ~all, or -all and takes into effect when an email fails its SPF check, aka its IP address does not appear in the DNS text.

-all (Hardfail): A hardfail policy recommends your computer to not accept this email. Since it has been sent by an unauthorised party, it is probably of malicious nature.

~all (Softfail): A softfail policy recommends your computer to accept the email, but mark it as suspicious. Emails that are marked as suspicious might, for example, end up in your spam folder.

+all: Basically disabled SPF. With the policy set to +all, all mail, regardless of whether its sender is authorised or not, is sent to the recipient without any indication that the sender might be malicious. A +all policy results in all emails passing their SPF check. This is why this policy is most likely a dangerous misconfiguration of SPF, because it appears to protect a domain from spoofing, but it does not.

DKIM - Domain Keys Identified Mail

DKIM ensures that the email's signed contents weren't altered in transit, using a cryptographic signature tied to the sender's domain. This signature is attached to an email and created using a private key. When you receive an email from support@amazon.com, amazon will have signed it using their private key. If the email is altered in any way on its way to you, this signature will be invalid. But how do you verify this signature? Yet again through DNS text. On amazon’s DNS a public key is stored that your computer can use to verify the signature. If the signature is verified, then the email was not altered in transit.

DMARC - Domain-based Message Authentication, Reporting & Conformance

DMARC is the final piece of the puzzle. Since both SPF and DKIM focus on the return-path of an email, not the From header that is visible to you, a hacker could exploit that and set up his own SPF and DKIM checks for the return-path address and write a different address in the visible from header. So, for example, you would see support@amazon.com in the header, but your computer would run the SPF and DKIM checks using the address evil@hacker.com listed in the return-path. DMARC checks whether the address listed in the from header is the same as the one in the return-path. An email passes its DMARC check only if the return-path aligns with the header, and if the email has passed its SPF and DKIM checks.

Similarly to SPF, the DNS text also outlines the defined policy for DMARC. It can be set to reject, none, or quarantine, and is defined under the p flag.

p=reject: The strongest of the three policies. It tells your computer to reject emails that did not pass their DMARC check.

p=quarantine: A middle ground of the policies. It tells your computer to accept the email, but mark it as suspicious.

p=none: A flag that almost eliminates all functionality of DMARC. It tells your computer to accept the email without any indication of it being suspicious. This should only ever be done in the testing phase.

The Common Pitfall of Misconfigured DMARC

But why would anyone set the DMARC policy to none? Primarily, because setting up SPF, DKIM, and DMARC correctly is difficult. Right after setting them up, it is smart to use DMARC only for its monitoring function to verify everything is set up correctly. This should, however, be changed about a month or two afterwards when everything is running smoothly - and that is where the issue arises. Sometimes, domain owners forget to set the DMARC policy to “reject” or “quarantine”, or they do not understand the different policies in the first place. Because this policy is stored publicly, hackers can find out who is not protecting themselves correctly.

Our data at dataprovider.com shows that this is not uncommon at all, over 3 million websites have their DMARC policy set to none, having also implemented SPF and DKIM. Taking a closer look at the age of these websites, it is clear that the majority has long left the testing phase. 83,6% have existed for more than 6 months, and over 70% have existed for more than a year.

Out of those, almost 3000 websites belong to businesses with a high economic footprint (a proprietary metric of Dataprovider.com indicating size based on e.g. website traffic). A misconfigured DMARC is a serious cyber security concern, because it offers no protection against spoofing. While SPF, DKIM, and DMARC are all running, they ultimately do nothing as they hinge on the final DMARC configuration.

Easy Overview with Dataprovider.com

With Dataprovider.com it is now incredibly easy to find out who has misconfigured their DKIM, SPF and/or DMARC. Our new field “Email authentication” gives insight into how and if over 430 million domains have configured their email security.

While this data is not new in our dataset, it is now finally structured. Rather than needing to parse the DNS text record for strings like v=DMARC1; p=none; you can now simply use the “Email authentication” field. It returns clear values that show whether security protocols have been implemented, and how. Find out who of your clients has their email misconfigured and create an outreach list for email security. Or find brands that are not protected properly. Whatever your use case - we support you with clear, structured, and easily accessible data.

Conclusion

SPF, DKIM and DMARC are necessary security protocols that should be enabled to protect a domain against spoofing. Unfortunately, not all domains have them implemented yet, and those that do often have them misconfigured, rendering them almost useless. With dataprovider.com’s new “Email authentication” field it is easy to spot those domains that are not quite up to code. We give insights into over 400 million domains and help in keeping all domain portfolios well managed and secure.