Sender Policy Framework (SPF)

One of the mechanisms that checks authenticity is the Sender Policy Framework. Let's take a look at the SPF record and what it is.

Why email needs an authenticity check

Historically speaking, when it comes to email, there hasn't really been any authenticity checks. What happens is that this machine right here, which is part of the domain.com domain, is sending through the mail transfer agent, sending a message over to this MTA with example.com. It goes through the same processes of accepting that email and sending it to the client as it would coming from any server. So there has, once again historically, not really been authenticity checks on where the mail is coming from.

But there is a mechanism to have authenticity. We have a domain here, and this user, if it's Sally, is coming from [email protected]. So how do we check the domain? Well, we have DNS servers, and really DNS servers should be locked down — whoever owns this domain should really safeguard their DNS records and their DNS server. So we can use the DNS server to do this check.

How SPF works

We do it with the Sender Policy Framework, or SPF. There's an SPF record that goes onto the DNS server. This SPF record can be used to check to see if it's coming from the proper source. When this MTA is sending messages to this MTA right here, it's coming from an IP address, and so what this MTA right here can do is check DNS for the SPF record and take a look to see if the IP address that it's being sent from is legitimate for that domain. If this is legitimate for, in this case, the domain.com domain, then it will say okay, yes, I'll accept that, and then send it along its way to Bob over here. So the SPF record allows this extra check to check for authenticity.

Mechanisms in an SPF record

Within the SPF record, there are different mechanisms that we could use. The mechanisms are just different callouts that we can do. We can call out an IP version 4 address and specify it, or an IP version 6 address, or if it's part of another domain we could use the include, or if we want to specify everything we can use the all. So there are different mechanisms here that we can use in order to call out what the server is that's allowed to send mail on that domain's behalf.

It is important that we can specify multiple IP version 4 or IP version 6 addresses, or includes, because we quite often within a domain have much more than just one server that's sending out this mail. We might have a backup server, or we might have other systems. Maybe we're using some cloud services and we want those cloud services to send mail. So it's important that we can include many different addresses in this SPF record.

Here would be an example of an SPF record. First of all, we specify the version, so this is SPF version one here — that's what the one stands for. We've specified a couple of IP addresses, version four at least. We specified another IP version 6 address here. And then we've got the include marketing.example.com. Maybe we're using them to send out marketing material, and since they're sending mail on behalf of us, we also need to include them. Well, they could also have multiple servers, they could have multiple IP version 4, IP version 6 servers. So we include the marketing.example.com, or the mx.marketingample.com, or whatever they have given us, so that way we could include all of their mail sending servers.

Soft fail and hard fail

Right here at the end is an all. This essentially lets the record say, if it doesn't match any of these, what are you going to do with this mail? If we include a tilde all at the end, we call that a soft fail. The soft fail essentially just says, well, consider it highly likely that it's spam, but still let it through if you don't see any other signs that it's spam.

The reason for this is because, as I mentioned, there are lots of different agencies that might be sending mail on behalf of us. If we did the dash all, which is what we call a hard fail, it would just say okay, I'm not going to accept this message, and then what would happen is that if we ended up sending mail from any other system, it would automatically just fail and we'd have to go through and troubleshoot this. So the hard fail is a more secure method of doing it, and this is a less secure method of doing it, but it gives a little bit of wiggle room with whether it's going to fail or not.

Realize that whether it's a hard fail or a soft fail, it's really not up to us. What we would do is, within our domain and within our SPF record, we would specify whether it's going to be a hard fail or soft fail. Then that mail gets sent over to example.com, and it's really example.com that gets to choose whether they listen to this hard fail or soft fail. You may say that it's a soft fail, but they might say, well, we're not going to accept it anyways, and we're not going to forward that on to Bob. Or you might say that this is a hard fail, but this example.com is going to say, we're still going to allow it. So they don't have to listen to what you tell them to do. This is just a recommendation — you're recommending to people who are receiving mail from you what they should do with the mail.

If you were to pull up the SPF record, then it all looks like one line, so it all runs together. We can see the different parts to this, but essentially it's going to be all on one line when you see it within the record.

Looking up an SPF record

I thought we could take a look at a program that allows us to view things like the SPF record. What I'm going to do is open up a browser and navigate to MX Toolbox, mxtoolbox.com, which is a great tool for looking up things like MX records.

If I wanted to see what the MX record is like, I'm going to look up ietf.org — IETF is the one that comes up with some of these standards, like the SPF record. So I'm going to hit enter, and it's going to pull up what their different records are, their MX records. If I wanted to send mail, these are the IP addresses that I would send mail to for that domain. And look, they have an IP version 4 address and an IP version 6 address, so these are where I can send the mail off to.

Now let's take a look at their SPF records. What I'm going to do is click this down arrow, choose SPF record lookup, and hit enter on that one. Then you can see that even though it's one line — this is what the record actually looks like — it breaks it apart for us. So we can see what version it is: they're running SPF version one. They have a couple of IP addresses that it's sending from. They have an IP version 6. And then include: it looks like they have got some stuff going on in Google and hostedrt.com. And then at the end there's a soft fail here at the end, so a soft fail is recommended.

So this is the SPF record, and it allows you to see what exactly is going to be acceptable sources of mail coming from this domain.