Understanding SPF Records | Zimbra

SPF is in action for quiet a long time. The very basic function of SPF is to authorize a sender on behalf of a domain. But why did we need it on the first place? We will deep dive in the details of SPF record in this article.

A Glimpse Of The Old Days

During the year of 2000, the concept of SPF was brought into the reality. Though at the earlier time, it was called by several names like, sender ID, MS (mail sender) DNS record, Designated senders protocol etc. But after 2004, tech giants like Microsoft step in and acknowledges it’s use.

In 2007, Hotmail announced that the Sender ID/SPF record needs to be published to deliver email at hotmail user’s inbox. This step made SPF as a part of standard official email setup instructions. After that SPF has become a necessary tool for sender verification.

Now Let’s Get Back To Some Technicality

SPF contains the list of IP addresses of different servers that are authorized to send email on behalf of a particular domain.

Take a look at this scenario.

Usually an email traverses from sender to receiver in a typical way. After receiving the email, the receiver extracts the originating IP address in other word sender IP address. But how does it confirm that the originating IP address it received is the actual/authorized sender and not manipulated during the travel through the internet?

Here comes the catch.

When a receiver receives an email, it extracts the sender IP address/originating IP address from that email. Then it looks up in the sender domains SPF record, if it finds the originating IP listed in sender domains SPF record, it marks the email as PASS. Thus sends it to recipient’s inbox. If the authentication fails to PASS, it may reject or drop the email in recipient’s SPAM/JUNK folder based on various policy.

For now, just take a look a the image just to clarify your thoughts:

So now you know how SPF works.

Let’s see how you can construct a proper SPF record. It can be a bit of long discussion but we will try to keep it simple, so hang tight 🙂

We will try to explain different scenarios and will construct the SPF record accordingly so that you can understand the change properly.

Let’s Take A Look At A Scenario

Just to remind you, SPF record is always set against the domain. Now, the basic structure of a SPF record is as follows:

v=spf1 [authorized_IP] [authorized_IP] -all

Here, v means version and -all means hard fail. By hard fail, you instruct recipient server that if they find mismatch in the originating IP and the authorized IP of SPF record they should discard the mail.

Another basic structure of the SPF record is:

v=spf1 [authorized_IP] [authorized_IP] ~all

As you can see this one is similar to the first one. The only difference is ~all. Here, ~all means soft fail. By soft fail, you instruct the recipient that if they find in the originating IP and the authorized IP of SPF record fails to match, it is your discretion whether to keep the email or discard it.

Now, if you have a domain which is currently not in use, you can set the SPF record of that domain as such that no can misuse the domain. like,

v=spf1 -all

Here, you are not authorizing no one to send email using your domain. Every unused domain should have this policy in their SPF record.

Now Let’s Look At Another Variation Of This Scenario

v=spf1 ip4:111.11.111.111/32 -all

Now what if, you have a slightly complex scenario. Imagine you have another server (i.e web, application etc.) that also sends promotional/news letter emails using the same domain. What approach you could take? Let’s see.

Approach-1

In this case, include the web server’s IP in your SPF record so that they can send email using your domain and recipient can trust them. Therefore, the SPF syntax will be,

v=spf1 ip4:111.11.111.111/32 ip4:222.22.222.222/32 -all

Approach-2

If you don’t want to include other server’s in your SPF record, you can restrict them to send direct email to the recipient server. Hence, you have to relay their email through your email server. In that case, no additional inputs are required in your SPF record. Check the below example:

In this case, the SPF record will be:

v=spf1 ip4:111.11.111.111/32 -all

Service Provider’s Point Of View

Now let’s assume you have a service provider that manages your email service. In this case, most of the time they manage your DNS records but you should have a good concept so that you can understand what they are publishing.

Let me show you a picture and let’s see if it resembles anything to you:

In this scenario, your email server does not send email directly to the remote end. Initially, they relay their email to provider’s email security gateway and if for any reason the email security gateway becomes unreachable, they uses provider’s MX server as a redundant relay. Now in this case when the recipient will receive email, it will get the email security gateway/MX server’s IP as originating/sender IP. Therefore, you need to include them in your SPF record.

Therefore the SPF record will be:

v=spf1 ip4:111.11.111.111/32 ip4:222.22.222.222/32 ip4:333.33.333.333/32 -all

A Complex Scenario

Now take a look at the image and underlying SPF record. If you can understand it correctly, then you can setup SPF record on your own and for any kind of scenario.

SPF Record:
v=spf1 ip4:111.11.111.111/32 ip4:222.22.222.222/32 ip4:333.33.333.333/32 ip4:444.44.444.444/32 -all

A More Complex And Complete Scenario

Now assume you manage a huge organization which has some other of sub institutes. And you do not know all the IP related to your domain. You can take a safe approach. Let’s take a look at below image:

In this case, spf record will be:
v=spf1 a mx a:mail.testdomain.com ip4:222.22.222.222/32 ip4:333.33.333.333/32 ip4:444.44.444.444/32 include:abc.com -all

Always try to use FQDN/hostname instead of IP address. If you use FQDN/hostname, your SPF record will not be dependent on any IP addresses and if IP address of any FQDN changes, your SPF record will be updated without any intervention. i.e v=spf1 a:mail.testdomain.com -all

You are familiar with the most part of this SPF record. Let me tell you the differences.

• Here, we used a to add all A records found under the testdomain.com
• We used mx to add MX records found under the testdomain.com
• Also abc.com has some dynamic IP addresses. As it sends email on-behalf of testdomain.com, we have included the abc.com as well.
• Mind it that it is a safe approach when you are sure about your all active email sending nodes. But if you are sure, then you should go with the more direct/precise approach.

An Unorthodox SPF Record

Now some of you might have some questions in your mind. That okay, when we know our active mail sending nodes we can publish them in our SPF records. But what if I have taken my email service from gmail/microsoft. How would I know their IP? How would I set the SPF record then?

It is true that we can not collect all IP addresses that Gmail/O365 uses to send email. Therefore, they have predefined SPF record which you can publish and Voila, your SPF record is all set.

Let’s look at an example:

Scenario-1
v=spf1 include:_spf.google.com ~all

Scenario-2
v=spf1 ip4:999.99.999.999/32 include:_spf.google.com ~all

*** Keep that in mind that _spf.google.com is defined by google.

Same policy applies to the Microsoft also. You will get a predefined SPF record for your O365 which you will use in your SPF record.

Keep This In Mind

• SPF record setup is not a one time task. If you do not set it properly, I mean in context of DMARC deployment, your SPF record will pass but your DMARC record will fail.
• If a syntax or evaluation error occurs during your SPF record resolution, it will create “PermError” which can impact your email delivery. So double check your SPF record before publishing it.
• Use -all or ~all very carefully. Use ~all unless your sure about everything.
• Do not use multiple SPF record as it invalidates your SPF record. Do not use Multiple SPF Records.
• Last but not least, if you have more interest on SPF record, check out What is SPF?.
• Although you can declare softfail/hardfail in your SPF record, but at the end it is recipients discretion to take preferred action.

It is not possible to cover the whole SPF record topic in a single article. But I tried my best, so that you can understand it’s basic concept and implement it on your own. The article is a bit long but I hope it will help you.

That’s all for today.