Sender Policy Framework cannot help prevent spam and phishing if you allow billions of IP addresses to send as your domain
Twenty years ago, Paul Vixie published a request for comments regarding Rejects MAIL FROM which helped spur the Internet community to develop a new way to combat spam with Sender Policy Framework (SPF). The question then as now was that Simple Mail Transfer Protocol (SMTP), which is used to send e-mail on the Internet, provides no way to detect spoofed sender domains.
However, when you use SPF, domain owners can publish Domain Name System (DNS) records that define the IP addresses that are authorized to use their domain name to send email. At the receiving end, an email server can query the SPF records for apparently sender domain to check if the sender IP address is authorized to send email on behalf of that domain.
SMTP email and SPF summary
Readers familiar with SMTP message sending mechanisms and how SPF interacts with them may prefer to skip this section, although it is reasonably short.
Imagine that Alice at example.com want to send an email to Bob at example.org. Without SPF, Alice and Bob’s email servers would participate in an SMTP conversation something like the following, which is simplified by using HELO rather than EHLO, but not in ways that significantly change the basic constructs:
This is how sending and receiving Internet e-mail (SMTP) happened since the early 1980s, but it has – at least by the standards of today’s internet – a big problem. In the chart above, Chad at example.net could just as easily connect to example.org SMTP server, participate in the exact same SMTP conversation and receive an email message apparently from Alice at example.com delivered to Bob at example.org. Worse, there would be nothing to indicate the deception to Bob, except perhaps IP addresses recorded along with hostnames in diagnostic message headers (not shown here), but these are not easy to check for non-experts, and depending of your email client application, are often difficult to access yourself.
Although not abused in the very early days of email spam, when bulk spam became an established, if deservedly despised, business model, such email spoofing techniques were widely used to improve the chances of spam messages being read and even traded.
Back to the hypothetical Chad at example.net to send that message “from” Alice… That would involve two levels of impersonation (or spoofing), as many people now feel that automated, technical checks can or should be made to detect and block such fake emails. The first is at the SMTP envelope level and the second at the message header level. SPF provides SMTP envelope level controls and later anti-spoofing and message authentication protocols DKIM and DMARC provide check at message header level.
Does SPF work?
According to one examination published in 2022, about 32% of the 1.5 billion domains surveyed had SPF registrations. Of these, 7.7% had invalid syntax and 1% used the outdated PTR record, which points IP addresses to domain names. The adoption of SPF has actually been slow and lackluster, which may lead to another question: how many domains have overly permissive SPF registrations?
Recent research found that 264 organizations in Australia alone had exploitable IP addresses in their SPF records and could therefore unwittingly set the stage for large-scale spam and phishing campaigns. Although unrelated to what this research found, I recently had my own brush with potentially dangerous emails that exploited misconfigured SPF records.
Spoofed email in my inbox
Recently I received an email claiming to be from the French insurance company Prudence Croneole, but had all characteristics of spam and spoofing:
While I know it’s trivial to spoof the From: header in an email, my curiosity was piqued when I inspected the full email headers and found that the domain in the SMTP envelope MAIL FROM: -address [email protected] had passed the SPF check:
So I looked up the SPF registration for the domain prudencecreole.com:
That’s a huge block of IPv4 addresses! 22.214.171.124/2 contains 25% of the IPv4 address space ranging from 126.96.36.199 to 188.8.131.52. Over a billion IP addresses are approved senders for Prudence Creole’s domain name – a spammer’s paradise.
Just to make sure I wasn’t kidding myself, I set up an email server at home, was assigned a random, but qualified, IP address by my ISP and sent myself a spoof email prudencecreole.com:
To top it all off, I checked the SPF record for a domain from another spam email in my inbox that was spoofing wildvoyager.com:
Lo and behold, it 0.0.0.0/0 block allows the entire IPv4 address space, consisting of over four billion addresses, to pass the SPF check while masquerading as Wild Voyager.
After this experiment I informed Prudence Croneole and Wild Voyager about their misconfigured SPF records. Caution Croneole updated their SPF records prior to the publication of this article.
Reflections and experiences
Creating an SPF record for your domain is no death knell to spammers’ spoofing efforts. However, if securely configured, using SPF can frustrate many attempts like those arriving in my inbox. Perhaps the most important obstacle standing in the way of immediate, wider use and stricter application of SPF is email delivery. It takes two to play the SPF game because both senders and recipients must harmonize their email security policies if emails are not being delivered due to overly strict rules applied by both sides.
However, given the potential risks and damage from spammers spoofing your domain, the following advice can be applied as needed:
- Create an SPF record for all your HELO/EHLO identities if any SPF verifiers follow recommendation in RFC 7208 to check these
- It is better to use all mechanism with “–“ or “~“ qualifications rather than “?“ qualification, as the latter effectively giving anyone the ability to spoof your domain
- Set up a “drop everything” rule (v=spf1 -all) for each domain and subdomain you own that must never generate (Internet-directed) email or appear in the domain name portion of the HELO/EHLO or MAIL FROM commands:
- As a guideline, keep your SPF records small, preferably up to 512 bytes, to prevent them from being silently ignored by some SPF verifiers
- Make sure you only approve a limited and trusted set of IP addresses in your SPF records
The widespread use of SMTP to send e-mail has created an IT culture that focuses on transmitting e-mail reliably and efficiently rather than securely and with privacy. Adapting to a security-focused culture can be a slow process, but one that should be undertaken in order to make clear gains against one of the internet’s banes – spam.