FAQ: How can SPF records for every single sub-domain help to prevent phishing?

Autor: Oliver Schranz | CTO

Phishing as an attack vector is keeping security teams on their toes. While it has been identified as a major thread to modern businesses over and over again, the security community is still not in a place where we can consider this topic remotely solved. One part of the equation is that, as tech people, we often assume that complex problems can be solved (entirely?) using technology. Phishing, however, typically exploits social norms, curiosity and other deeply human perks in an effort to use humans, not machines, as their first point of entry. 

Despite lots of advertisements for email security-related products, there is no silver bullet to protect against phishing attacks. While technology cannot solve this problem in its entirety, there is an increasing amount of mechanisms that help to at least reduce the risk step-by-step. One of these is the Sender Policy Framework, SPF in short. 

What is SPF and how does it help against Phishing?

In its core, SPF allows the owner of a domain to tell the world from which IP addresses legitimate emails originate from. In technical terms, we can create rules in the SPF format that whitelist a set of IP addresses from which our emails originate from (i.e., the email server of my company or the service provider I outsourced this to). These rules are published by means of a DNS TXT record for the whole world to see. 

So how does this protect us against phishing? The following figure describes the typical workflow of a receiving email server validating whether an email is in violation of SPF rules:

Assuming an attacker wants to attack the company behind victim.com and hence sends emails to victim's employees from a fake email, such as ceo@victim.com (classic CEO fraud). At the receiving side, the email server used by the victim will use the domain part of the (faked) sender, victim.com, request the SPF DNS TXT record, and look up the allowed IPs. Despite the faked sender address, the attacker used their own email server to transmit the message, so the receiver sees the IP address of the attacker's email server. This IP is not the original email server that is used by the victim to send emails normally. In this case, the SPF check fails and the server can use this as an indication that the received message should be considered phishing, spam, or other unwanted behavior. 

Cool, but why do I need it for all my sub-domains?

In general, you should create such a record for all sub-domains you own, not just the ones that are actually used to send emails. In our example, this would imply that our victim organization should setup SPF records not just for victim.com but also for mail.victim.com, ftp.victim.com, blog.victim.com and whatever other sub-domains are present. The same goes without saying for other TLDs, even if they just redirect (e.g., victim.rocks -> victim.com). But why is that?

I am sure your admin team knows from which domains your company is sending emails, but do your employees, too? What about your customers? Since we are talking about sender address spoofing, it does not matter if the domain is actually used by you, it matters if it is believable that the domain could be used.

So let's assume you setup an SPF record for victim.com but the attacker spoofs a sender ceo@mail.victim.com. The receiving mail server will search for an SPF entry for mail.victim.com, find nothing, and the SPF check is passed. The receiver does not know where to look other than the domain provided as the sender email, and as far as I know, walking up from sub-domains to domains is not a common practice or at least not widely deployed.

Of course, not all sub-domains are credible targets for this. The chance that the victim spots the spoofing if the attacker uses 50yearscelebration.victim.com or vpn.victim.com is substantially higher than for mail.victim.com or victim.com. Still, reducing the phishing risk by a certain extent is still worth it.

Conclusion

Security is all about raising the bar, so if you ask me, it makes sense to use such a simple mechanism like SPF. For example, a default rule can expresses that no emails are sent from from domains and sub-domains by default. Depending on the tool-support, this could be literally a default setting. For those few that area actually used to send emails, we can overwrite that rule. This does not solve phishing in its entirety, but it's a first step.

Bonus FAQ:

Why are you writing about this? 

Our SaaS solution Findalyze actually recommends to create an SPF record for every single sub-domain we identify. Many people are not familiar with this mechanism and ask exactly the question above: do we really need it for all sub-domains? Going forward, we can use this post as a long-form explanation of why it makes sense.

What if the attacker uses inventedsubdomain.victim.com? It will not have a DNS entry because it does not exist...

Good news: you can use wildcards in SPF entries: https://www.spf-record.com/faq/whats-about-subdomains

How does this play along DKIM and DMARC?

Similarly to SPF, DKIM also aims to authenticate the origin of an email. But instead of declaring allowed sender IPs, it introduces cryptographic signatures on emails that are verified via a public key available via DNS. So when an email arrives with a valid signature, we know it was sent from a legit source. But what about emails without signatures? Enter DMARC, a mechanism to declare email security policies. With DMARC, you can publicly state whether SPF and DKIM should be verified for emails that originate from your domain, as well as dictate what happens to emails that fail validation and whether you will even get reports from receivers about "failed" mails that claim to originate from your domain.

Long story short: the more the merrier. Best case, setup SPF and DKIM, and additionally enforce them via DMARC.