Categories
Other

Get grip on your SPF record

In this post I will tell my best practices to get grip on your SPF record.


Why it is useful to have a good SPF procedure

In an earlier blog post I explained the limitation of SPF and how it works, together with DKIM and DMARC. It is useful to have a good SPF procedure to avoid future problems, because:

  • Your SPF can be overloaded by IP addresses and you should want to know the source of every IP address in your SPF record
  • Your SPF record can easily grow up to a max of 10 DNS look ups
  • Your SPF record can be to long and will be unmanageable

Get the grip back on your SPF record

The cause

Your company have for example a SPF record with 9 of the allowed 10 DNS look ups, and you have been requested to do something about this.

Current SPF record (9 DNS Look ups):

v=spf1 ip4:11.222.33.444 ip4:44.33.222.111 ip4:22.33.444.555 ip4:55.66.777.8 ip4:88.99.999.99 ip4:99.88.777.66 mx include:spf.protection.outlook.com include:_spf.app1.com include:_spf.app2.com include:_spf.app3.com include:_spf.app4.com -all

Calculating the DNS look ups:

Look upCount
include:spf.protection.outlook.com2 DNS look ups
include:_spf.app1.com1 DNS look up
include:_spf.app2.com1 DNS look up
include:_spf.app3.com2 DNS look ups
include:_spf.app4.com2 DNS lookups
mx (your MX record)1 DNS lookup
Total:9 DNS lookups

The above SPF record is 242 characters long, yes, we can extend the length with another 255 characters with a second string. But we have 1 DNS look up left, and from then you can only list IP addresses. In short, STOP RIGHT NOW! Things get messy.

Find your peace, redesign a new way of using your SPF record

In the moment we live, we have so much SaaS applications that need to send email on behalf of our domain. But does those SaaS applications really have to mail on behalf of your main domain? Why we shouldn’t not send over a subdomain with another fresh new SPF (TXT) record? Plus, we can add some extra security to it (later more in this post).

For example, why should a newsletter need to send on behalf of your main domain and why can’t it be send from noreply@news.yourdomain.com instead?

Set the scissor in your SPF record

Okay, grab your scissors and choose with the above in mind, which SaaS application ‘need‘ to send on behalf of your main domain, like Microsoft 365 and which ‘not‘, like your newsletter service or an internal application.

After the scissors have done his magic:

Look upOutcome
include:spf.protection.outlook.comNeed to send over yourdomain.com (2 DNS lookups)
include:_spf.app1.comNeed to send over yourdomain.com (1 DNS lookup)
include:_spf.app2.comNeed to send over yourdomain.com (1 DNS lookup)
include:_spf.app3.com (delete)Can send over app1.yourdomain.com
include:_spf.app4.com (delete)Can send over news.yourdomain.com
mx (your MX record) (delete)Duplicate mechanisms, when using Microsoft 365, the MX endpoint IP is already listed in include:spf.protection.outlook.com

At this moment, we have 4 DNS look ups, so we cleaned 5 DNS look ups, good job! But what about the IP addresses in the SPF record? IP addresses will not cost any DNS look ups, because we don’t talk to the DNS. A downside of using IP addresses in your SPF record is that it will lead into an unmanageable and to long record. Yes, we can add a new include with the cost of 1 DNS look up, for example: include:_spf.yourdomain.com with a new SPF(TXT) record like:

v=spf1 ip4:11.222.33.444 ip4:44.33.222.111 ip4:22.33.444.555 ip4:55.66.777.8 ip4:88.99.999.99 ip4:99.88.777.66 -all

But I guess your CISO would like to know all the sources of the listed IP addresses in the SPF record, yes you can add each IP address in a CMDB. However, why not using the DNS using a SPF macro? This macro will also cost 1 DNS lookup, plus (and the bright side) you can add an unlimited amount of IP addresses without being afraid to need another DNS look up when the include _spf.yourdomain.com has already have two strings of 255 characters.

Using a SPF Macro for your IP addresses

You can use the following steps for each IP address.

1: Add the following DNS look up into the SPF record for yourdomain.com: exists:%{i}._spf.yourdomain.com

2: Now for each IP address we will create an A record, that is not publicly routable (like to 127.0.0.2) and a TXT record. The TXT record is set to list source of the IP address, can have any value and is optional to use.

Host format:

IP.ADDRESS._spf.yourdomain.com
HostTypeValue
11.222.33.444._spf.yourdomain.comA127.0.0.2
11.222.33.444._spf.yourdomain.comTXTInternal

You can repeat this for an unlimited amount of IP addresses.

If you’re are not comfortable with setting a source in public DNS, this option is optional for the above SPF Macro. My opinion, is that it should not have any security concerns, if you use a minimal listed source, like: ‘Vendor Name‘ or ‘Internal’. For the internal value (if you are using an Azure VM), you can check which PIP is bounded on which NIC, for example. Plus, the IP addresses or not directly visible using this SPF Macro, as you can see in the SPF record from step 1. So the direct hostname is not easy to guess and the purpose of these systems is probably already easy to identify in other ways, like with a Nmap scan for open ports.

Getting the subdomains ready for your SaaS applications

When setting up subdomains for outbound email, I assume that DMARC is set-up for protecting the subdomains as listed in my earlier blog post.

You can use the following steps for each SaaS application.

In this example we use the SaaS application called App4, App4 need to send newsletters over the subdomain news.yourdomain.com. App4 use DNS look up: include:_spf.app4.com which need to be included in the SPF record of news.yourdomain.com.

To do so, create a new SPF(TXT) record for news.yourdomain.com

HostTypeValue
news.yourdomain.comTXTv=spf1 include:_spf.app4.com -all

At this point, App4 can send from news.yourdomain.com over any address: *@news.yourdomain.com. But it would be much secure, if we permit that App4 only can send over: noreply@news.yourdomain.com

To archive this we can use a SPF macro to restrict the SaaS application App4 to send only from a specific address.

1: Set the SPF record for news.yourdomain.com as followed

HostTypeValue
news.yourdomain.comTXTv=spf1 include:%{l}._spf.news.yourdomain.com -all

2: Then we add App4’s DNS lookup: include:_spf.app4.com in a new SPF (TXT) record so that the marco in the main SPF (TXT) record can be resolved.

HostTypeValue
noreply._spf.news.yourdomain.comTXTv=spf1 include:_spf.app4.com

You will notice that the above value does not end with -all, this statement is not needed because it will check the statement within the main SPF record.

From now on, only the IP addresses in include:_spf.app4.com are permitted to send over: noreply@news.yourdomain.com
You can choose the same procedure for all other SaaS applications, which can send over a subdomain, like an internal application.

Summarized

1: The main SPF record is cleaned up with 5 DNS look ups, this by choosing which service need to send over your main domain and which not. We also deleted the mx DNS lookup because of a duplicate mechanisms.

2: We have a good and secure method to add an unlimited amount of IP addresses to the SPF record by using a SPF macro.

The cleaned up SPF record have only 5 DNS look ups instead of 9 DNS look ups before the clean up:

v=spf1 exists:%{i}._spf.yourdomain.com include:spf.protection.outlook.com include:_spf.app1.com include:_spf.app2.com -all

3: We permit SaaS applications to send over subdomains using a SPF macro, to only send over a specific address and with an own SPF record.

Finally

For the future of your SPF record, add IP addresses to your main SPF record with the SPF macro we set-up and choose carefully if a SaaS application should be send over a subdomain instead of your main domain.


Share this: