Email security is (or should be) a top priority for all organizations. And when you talk about email security, SPF (Sender Policy Framework) is always in the conversation. We've recently worked with a number of organizations that have misconfigured SPF records (not sure if it's something in the water), so we thought it might be helpful to go back to the basics.

Background

One of the inherent problems with email is that historically there has been no universally accepted way to establish the authenticity of a message. There is no way, for instance, to prove that the purported sender of an email is the true sender. The standard for sending/receiving email via the Internet (SMTP) did not anticipate the need for security. Cybercriminals have — perhaps expectedly — leveraged this fundamental vulnerability and quite effectively used email to distribute spam and malware. Cybercriminals can, for example, forge the email "sender" to make a message appear as if it has been sent by a trusted source. This fundamental flaw with email explains in large part why phishing is the most frequently used and effective cyber-attack vector.

In recent years, email security advocates have introduced SPF (as well as DKIM and DMARC) as a way to add a layer of security for email. SPF relies on DNS records to provide a platform for companies to tell the world exactly which servers are authorized to send email on its behalf. Here's how it works.

How SPF Works

To implement SPF, a domain owner must first publish DNS records that state which servers are authorized to send emails on the domain's behalf. Once the DNS records are set up, when an email is sent, the receiving email server can perform a DNS query and compare the IP address of the server that sent the incoming email to the list of "authorized IPs" in the DNS records. If the IP that sent the incoming email is on the list, the SPF test result is a "Pass." If the IP address is not on the authorized list, the SPF test result is a "Fail."

Importantly, and a key limitation, SPF is for informational purposes only. There is no universally accepted requirement on how to handle email that fails a SPF test. Think of it as a suggestion by the domain owner. Receiving email servers can ignore or overide.

Why Implement SPF?

Why implement SPF if the upside is limited? For one, more and more mailhosts are rejecting email if the sending domain does not have any SPF records. Secondly, there's no cost. It's free. So even if the benefits are limited, there's essentially no downside. Lastly, and perhaps most importantly, SPF provides a way for your organization to try to stop incoming email that spoofs its domain. Although your organization can't control how other email servers handle SPF-failed messages, it can control how its own email servers do. If a spammer/hacker sends a spoofed email that appears to be coming from an email address on your domain to a legitimate email address on your domain, it will (likely) fail the SPF test. Your organization could (and, in most circumstances, should) configure your email servers to block messages that fail a SPF test.

Understanding SPF Syntax

Now, what about those misconfigured SPF records that we mentioned. Here's a sample SPF record:

SPF record syntax is made up of three parts:

(Most) SPF records start with the string "v=spf1".
The second part of the record lists the IP addresses that are authorized to send your organization's email (or instructions on how to identify those IPs). In our example above, there are 4 operators: (i) "a", (ii) "mx", (iii) "ptr" and (iv) "include". "a" refers to any IP that matches the host name or domain name. "mx" refers to any IP that matches MX records for the domain. "ptr" instructs to use reverse dns to match IPs to host names. "include" instructs to match against the SPF record for another domain. One would use the "include" operator if there is a third party that is authorized to send email on your behalf. And indeed, "spf.protection.outlook.com" is the domain for Office365.
The third and final part of the SPF syntax is the "all" operator. As the name suggests, the "all" operator refers to any host other than the ones authorized in the second part of the syntax. This is the catchall. The "all" operator is how you tell a receiving email server how your organization recommends that the email server handle any email that is sent from an unauthorized IP. There are two relevant qualifiers: the minus sign ("-") and the tilde ("~"). The minus operator indicates a "Fail". In other words, if an incoming email is sent from an unauthorized IP, then the result will be "Fail." The tilde operator indicates a "Softfail." A Softfail is the equivalent of a shrug. It means that the email can be accepted but should be treated with suspicion. In the above example, the operator is "~all", which is a Softfail. In most circumstances, we recommend changing this to a hard Fail, which simply means changing the last part of the syntax to "-all".

One other note. The above example includes the "ptr" operator, which as noted above, uses reverse DNS to match IPs to host names. Microsoft currently recommends NOT including this operator in SPF record because it can be resource intensive.

Office 365 Note

Now, an additional note if your organization uses Office 365. Check Office 365 to see how it currently handles SPF test fails. Essentially, there are two key settings that you'll want to review: (a) how Office 365 handles High Confidence Spam, and (b) how Office 365 handles incoming email that fails a SPF test. We recommend that you configure Office 365 to quarantine High Confidence Spam and to treat messages that fail the SPF test as High Confidence Spam, which effectively means that they will be quarantined. By quarantining these messages (and not rejecting them), it gives the user an opportunity to recover an email if a legitimate email mistakenly gets included.

To learn more about Tensyl's approach to email security, Contact us.

SPF - All You Ever Wanted To Know And More