The mysteries of the internet : SPF edition
First of all, SPF stands for “Sender Policy framework”.
Now you know.
Period.
Just kidding.
An SPF record is used as a “sort of ” security/anti-spam measure in order to protect your outgoing mail from being sent FROM a certain list of sender locations.
You read it right : “from” (not “to“).
It’s in no way a fail-safe antispam solution, but it will decrease the amount of mails sent in your name significantly.
Office 365 even requires this specific record on first setup (although you can skip this step eventually).
Who didn’t configure his Outlook Express in the old days to send mail from as his boss to fake a “you’re fired” mail to your new colleague ? Right ? Right ? N-Nobody ?
Oops. Sorry, Bjorn.
Comment ça marche ?
In order to understand how things work, wel’ll start out with a little example from our fake (?) company Shortstraw LLC and their Office 365.
After setting up your O365 subscription, your SPF records looks a bit like this :
I deliberately used the expression “text record” as SPF is nothing more than a TXT record with a specific markup. Most hosting companies have a separate entry box for SPF nowadays, but in the background it’s still a TXT.
Let’s split up everyting in this text record, so we can understand completely what exactly it is that Microsoft wants us to do.
v=spf1 :
All this does is stating the obvious.
This record is “version SPF1”.
To make things confusing, there’s an unrelated spf2.0 record, which stands for “Sender ID”
include:spf.protection.outlook.com :
The include value *drumrolls* includes the values of another SPF record, in this case a large list of IP addresses of Microsoft servers.
The very same website I’ve used in the example above (MX Toolbox) easily provided me with this information. You can see that in itself this record loops through to more SPF values in spfa.protection.outlook.com.
This has to do with the maximum accepted length for a TXT record, which is limited to 255 characters, as explained on this RFC page.
-all
The final entry in the record is also the most conclusive one.
The “-all” stands for “disallow all other entries”
Other entries
The above example was just a textbook sample provided by Microsoft to get you started. It should be sufficient for the average O365 setup.
Reality however will often slap you in the face with a more complex situation where you’ll be needing to configure all-in-one printers, old software packages with support for mail over port 25 only, websites sending from something@your_domain_name, …
They all have a couple of specific things to keep in mind when configuring your SPF record.
A handy tool for helping you configuring your SPF record is https://www.spfwizard.net/, which does exactly what the name implies.
Other possible entries you might use in your record :
A:
It’s usually followed by an actual DNS A-record
An example will make things clear.
v=spf1 include:spf.protection.outlook.com a:mail.suamae.br -all
The classic O365 SPF record was added a:mail.suamae.br, which will allow the IP resolving to this Brazilian mail server name to be able to send mails from shortstraw.be’s domain name as well.
Just adding “A” and not defining anything behind it, will result in all A-records in shortstraw.be being able to send mail from this domain name.
MX:
Works similar to the A-entry.
v=spf1 include:spf.protection.outlook.com MX:uwmoeder.com -all
The example above will allow all the mailservers in the domain uwmoeder.com to be able to send mail from shortstraw.be
Double checking on this, it will resolve to redirect.ovh.net in this case.
Just adding “MX” without a domain name, will allow all MX entries in the shortstraw.be domain to send mail.
IP4:
You may enter one specific IPv4 address or a group of IP addresses in the typical “slash” notation (it’s called “CIDR format” in big-boy-language).
Note the omission of the letter “v” in ip4. Pay attention to this common typo.
v=spf1 include:spf.protection.outlook.com ip4:194.78.56.8 ip4:37.230.164.0/22 -all
This will allow the single host “194.78.56.8” and the group of IP addresses “37.230.164.0 to 37.230.167.255” to send mail from your domain name.
IP6:
See above.
v=spf1 include:spf.protection.outlook.com ip6:2a01:4f8:d16:1355::2 -all
Completely the same, but for IPv6 addresses.
~all
Replacing the “-all” entry with this “~all”, results in the mails from the “not-allowed” list to be marked as so-called “Soft Fail”. You can see the result of this in the headers of a received mail as something like …
Received-SPF: softfail (google.com: domain of transitioning mail@example.com does not designate 203.0.113.2 as permitted sender) client-ip=203.0.113.2;
+all
Stating the “+all” addendum, ignores everything you just added in the previous part of the SPF record.
Your mails might (or might not, depending on the server) be tagged with an extra header that says something in the likes of “this mail is probably not OK, but it doesn’t matter anyway”.
?all
Almost the same as “+all”, with the exception that your mails will not be flagged.
?all stands for “No policy statement” and simply does not hold the SPF record in account.
Often used when trying to delete an SPF record without actually deleting it.
Now how does this REALLY work ?
Every self-respectable and up-to-date mail server will do an SPF checkup, when receiving mail.
That’s right, even Exchange Server 2003 can do this, updated to Service Pack 2. (not sure how it’s implemented in an Exchange 2000, though – I’ve seen software by GFI that used to be able to do this, but if you’ve come to this page looking for an antispam solution for your Exchange 2000, you can probably guess what I’m thinking right now…)
In a side-note, this function is usually referred to as “Sender ID” in an Exchange environment.
It’s usually a hard-coded feature with nothing much to tweak, except for turning it on or off.
One simple image explains how it works.
Mail server A sends mail from a certain domain.
Mail server B receives mail from this domain and does a quick DNS lookup looking for any TXT records containing “v=spf1” after which he interprets the information like I’ve explained about one page up.
That’s it !
You now know how an SPF record works !
More information
I’ve taken the liberty of compiling a small list of handy websites should you want to read more on the subject.
- Pretty hardcore and a tough cookie to read ; the official RFC for SPF records :
https://tools.ietf.org/html/rfc7208#section-6.1 - SPFWizard, for creating your own custom SPF records on the fly :
https://www.spfwizard.net - DKIM, a next-level form of protection your domain.
It’s not covered on this page, but it’s just a friendly reminder to let you know that there’s more than one way to perform mail protection :
https://blog.returnpath.com/how-to-explain-dkim-in-plain-english-2/ - Mxtoolbox.
Your trustworthy website on troubleshooting DNS and mail related stuff.
https://www.mxtoolbox.com - Microsoft Message Header Analyzer.
Not mentioned in this page yet, but a great tool nevertheless.
If reading a wall of text is too hard, copy your mail headers in this website and it will provide you with readable text. Huzzah !
https://testconnectivity.microsoft.com/?tabid=mha