SPF isn’t just for sunscreen. In the world of email, Sender Policy Framework or SPF is a method to validate that an email came from an authorized domain. In other words, it is a way to say that Postmark is allowed to send email for your domain.Learn more about using SPF to protect your domain from email spoofing.
How SPF protects you #
The SMTP protocol, the literal definition of email, has no protections on the From field in an email. As long as it’s a valid email address, there is no further validation. A malevolent actor can impersonate your bank, your employer or anyone at all. This problem led to the creation of SPF.
SPF is a relatively recent solution. Different variations of the idea were proposed in the early 2000s and these coalesced into the SPF specification as RFC 4408 in April 2006. SPF describes a DNS record in a special format to list all the domains allowed to send mail from the domain. This allows spam filters to easily check if the origin of an email is from an authorized domain.
Personally, I think it’s a rather elegant solution in that it uses existing architecture pieces, but it’s definitely not perfect. Using a special format for the TXT DNS record (which I’ll describe below) is non-standard but certainly is an easy way to gain adoption for a specification. The use of DNS for authentication isn’t without issues either. Despite the flaws of SPF, at Postmark we highly recommend users set up SPF in addition to DKIM. To paraphrase, we use the spam fighting tools we have, not the spam fighting tools we wish we had. From the Google Online Security Blog in December 2013, 89.1% of the non-spam email that Gmail received was authenticated by SPF and 74.7% was authenticated by both SPF and DKIM.
How SPF works #
At a high level, here is the workflow of how a mail server checks SPF:
- the Postmark server with IP address of 22.214.171.124 sends a message FROM firstname.lastname@example.org TO email@example.com
- the bar.com mail server gets the DNS records of type TXT for foo.com, looking for the SPF record
- the bar.com mail server compares the 126.96.36.199 IP address against the parts of the foo.com SPF record (described below)
- the message is accepted or rejected based on which part of the SPF record it matches
What the SPF record means #
When you set up a sender signature in Postmark, we recommend you use the following SPF record:
v=spf1 a mx include:spf.mtasv.net ~all
Let’s break down what that means.
First thing to note is the syntax of the SPF record. It’s broken down into the version prefix and one or more mechanisms.
The version prefix is pretty simple. Since there can be multiple TXT records for a domain, this is the way to let parsers know that this is the record to be used for SPF checking. The mechanisms that follow are checked left to right and these specify different rules on how SPF is checked for the domain. The record that Postmark gives you has four mechanisms: “a”, “mx”, “include:spf.mtasv.net” and “~all”. Before we go deeper into mechanisms, I need to explain qualifiers.
The mechanisms can also be prefixed with a qualifier which describes the action to take when a sending IP matches the qualifier. The default qualifier is “+”. So the Postmark SPF record is the same as:
Let’s go over what qualifiers are available.
+Pass, an IP that matches a mechanism with this qualifier will pass SPF.
-Fail, an IP that matches a mechanism with this qualifier will fail SPF.
~SoftFail, an IP that matches a mechanism with this qualifier will soft fail SPF, which means that the host should accept the mail, but mark it as an SPF failure.
?Neutral, an IP that matches a mechanism with this qualifier will neither pass or fail SPF.
The “a” mechanism
Let’s say that I send mail from IP 188.8.131.52 for the domain “example.com”. If “example.com” has an A record that returns 184.108.40.206 then this mechanism will pass.
The “mx” mechanism
Any domain that hosts email has one or more MX records. These records define which email servers should be used when relaying email. For instance, when using Google Apps you insert several MX records into DNS. By including the “mx” mechanism, it automatically approves these servers and avoids you having to list them individually. This also avoids maintaining the list if they change later.
The “include” mechanism
Let’s say that I send mail from IP 220.127.116.11 for the domain “example.com”. If the SPF record for “example.com” includes spf.mtasv.net and 18.104.22.168 passes against the SPF record for spf.mtasv.net then this mechanism will pass.
The “all” mechanism
The all mechanism will match against everything and in this case the result will be a SoftFail for everything that gets to this point.
Further reading #
There are other mechanisms as well, but hopefully this post is enough to teach you the basics about SPF. The SPF project is a great resource and the section on record syntax goes into much more detail about the different parts of the SPF record.
Keep an eye on the blog for more topics like this. I’ll have posts about DKIM and DMARC coming up. DMARC in particular has become much greater in relevance lately and SPF and DKIM are the building blocks that DMARC uses.