How To Securely Create An SPF TXT Record In 5 Steps

Learning how to create and configure an SPF TXT record is an essential component for any business looking to securely communicate over email.

SPF not only helps protect your domain from malicious spoofing but also increases the deliverability of legitimate emails you send, helping them land in the inboxes of your intended recipients.

In this blog, we'll start by demonstrating how to create an SPF TXT record. We'll then deep-dive into the SPF protocol and why it was created, wrapping up with several frequently asked questions.

Step 1. Identify Who Your Email Senders Are

Depending on whether you're a small business or a large enterprise, identifying who your email senders are can be a simple or complex task. With this in mind, there are two approaches you can take.

Option 1: Fast & Simple Approach

Simply put together a catalog of the different technologies that are in use by your organization and mark off whether any of these technologies are sending emails from your domain. These emails may be for marketing, internal notifications, customer notifications, etc., so it may be best to circulate the list with different teams to ensure the complete list of technologies is captured.

For example, here at CanIPhish, we use Microsoft 365 for collaboration, Stripe as our payment gateway and Klaviyo for customer marketing. Each of these providers sends emails on behalf of our domain, and accordingly, we need to ensure they're captured in the catalog we put together.

To help showcase what this catalog may look like, we've included an example below:

Option 2: Advanced & Thorough Approach

Configure the DMARC email compliance protocol in tandem with DMARC monitoring software to monitor all emails being sent on your domain's behalf. This approach is much more advanced but also much more thorough. If your organization is a large enterprise with a complex email environment, then using this approach may be necessary.

Once DMARC monitoring is in place, you can pull together a third-party verified list of all email senders and determine if those senders need to be included in your SPF record. Typically, this monitoring must take place over 4-8 weeks to be as thorough and accurate as possible.

Step 2. Collect All Email Sender Domains & IPs

Once your full list of email senders has been collected, it's time to narrow down and determine the exact list of SPF domains and sending IP addresses that need to be included in your SPF record.

To do this, simply work through the list of email senders and go to the technical guidance provided by the corresponding technology vendor to determine what domains or IP addresses need to be included in your SPF record.

For example, with Microsoft 365, you can find the required SPF configuration within your Microsoft 365 Admin Portal, but there's also a Microsoft Support Article that provides this same information (displayed below):

With the Microsoft 365 example, we'll want to extract the "include:spf[.]protection[.]outlook[.]com" portion of the specified SPF record and store it in our list of required SPF domains and IP addresses. You'll then need to progress through your list and do the same analysis for each email sender.

For demonstration purposes, we've expanded on the CanIPhish example from earlier.

Note: Some providers may use a subdomain or a different email authentication protocol, such as DKIM, to deliver emails. For example, with CanIPhish, Microsoft 365 is sending emails from caniphish[.]com using SPF, but Stripe is sending emails from caniphish[.]com using DKIM; therefore, Stripe doesn't need to be considered when configuring the CanIPhish SPF record.

Step 3. Create The SPF Record

With the full list of SPF domains and IP addresses collected, it's time to put together the actual SPF record.

To do this, open your favorite text editor and perform the following:

1. Start the SPF record with the version:
   v=spf1
2. Go through each SPF domain and IP address that's been collected and manually append each domain or IP to your SPF record, separating each with a space:
   include:insert-domain[.]com ip4:XXX.XXX.XXX.XXX
3. Set the SPF determination in a hard-fail configuration by appending the following text:
   -all

With all three portions concatenated, the SPF record should look similar to the below:

By following these steps, you're ensuring your SPF record is configured with the least permissions necessary to perform its function while also using the most secure SPF determination (i.e., the hard-fail configuration).

Step 4. Upload The SPF Record To Your DNS Zone File

This step will vary depending on the provider you use to host and publish your public DNS. Once identified and your DNS is accessible, you'll need to ensure SPF is added as a TXT record at the root of your domain. The following record values may need to be set:

• Record Type: TXT
• Host: @
• TXT Value: v=spf1 <INSERT-SPF-DOMAINS-AND-IPS> -all
• TTL: 3600 (or your provider default)

Note: The value @ on the Host field indicates your root domain. If you need the SPF record set up on a subdomain, then this value must be changed to include the subdomain.

As an example, you can see the SPF record used by caniphish[.]com, which is hosted and published by AWS, using their Route53 service:

Step 5. Confirm SPF Is Functioning For All Email Senders

Once your SPF TXT record is deployed on your public DNS, it's time to validate that everything is set up correctly and functioning as expected.

Step 5.1. Use An SPF Validator Tool

As an initial step, use an SPF validator tool to ensure the SPF record is correctly formatted and configured.

Notably, as part of this scan, we'll be validating that:

• The SPF record has been detected.
• The SPF determination has been set.
• The SPF determination has been set in a hard-fail configuration (i.e., "-all").
• The SPF record has less than ten third-party DNS lookups as part of its validation chain.

Step 5.2. Perform Practical SPF Tests

After your SPF record has been validated, you need to perform practical tests to ensure that email delivery is functioning as expected. To do this, we recommend testing each email sender you use - specifically monitoring email headers to ensure an SPF Pass result is obtained.

How To Check For SPF Pass Results In Outlook:

1. Find and open the test email within Outlook.
2. Click the "..." ribbon item on the top-right side of the email popup.

   

3. Hover over the "View" menu item and then click "View message details".

   

4. Copy the message details and then paste them into your favorite text editor.
5. Search for the string "Received-SPF:" which should then have a "Pass" or "Fail" result.

   

How To Check For SPF Pass Results In Gmail:

1. Find and open the test email within Gmail.
2. Click the "..." ribbon item on the top-right side of the email popup.

   

3. Click the "Show original" menu item.

   

4. Look for the SPF summary item, which should then have a "PASS" or "FAIL" result.

   

If SPF has passed, you've configured this sender correctly. If SPF failed, this sender may have been missed during the SPF setup.

Congratulations on successfully configuring your SPF TXT record!

Best Practice: Set A Catch-All SPF Sub-Domain Policy

The SPF TXT Record that's been set up as part of steps 1-5 will apply to your root domain (e.g., for CanIPhish, this is caniphish[.]com), but what about sub-domains?

By default, subdomains won't have your root SPF record applied to them. An order of precedence occurs if someone receives an email from one of your sub-domains:

1. The receiver checks to see if the subdomain has an explicit SPF record set for it.
2. If an explicit SPF record isn't set for the subdomain, the receiver will check your catch-all SPF subdomain policy and apply that.
3. If neither an explicit nor catch-all sub-domain policy exists, then the no SPF policy is applied, and an SPF "PermError" is returned.

In-line with this order of precedence, a catch-all SPF subdomain policy is typically used to broadcast to email receivers that if an explicit SPF record hasn't been set, then the subdomain isn't to be used for the delivery of emails.

To get a hardened catch-all SPF subdomain policy setup, simply deploy the configuration outlined below on your public DNS:

• Record Type: TXT
• Host: *
• TXT Value: v=spf1 -all
• TTL: 3600 (or your provider default)

Now that we know how to create an SPF record let's take a step back and go through some SPF fundamentals.

SPF TXT Record Fundamentals

What Is An SPF TXT Record?

SPF, short for Senders Policy Framework, is an email authentication protocol that allows email receivers to authenticate whether the sender of an email is who they say they are.

This authentication protocol works by mapping a list of authorized sending IP addresses to a domain name and then publishing this list as an SPF TXT Record within a public DNS server, making it accessible by the entire Internet. Whenever someone receives an email purporting to come from a domain, they can compare the list of IP addresses against the sender's IP address and determine whether the sender is who they say they are or if it's potentially a maliciously spoofed email.

What Are The Different Components Of An SPF Record?

An SPF Record comprises three distinct components. For the purpose of analyzing each component, we'll use the caniphish[.]com SPF record as an example:

Note: IP addresses have been redacted in the above SPF record.

Component 1: The SPF Version

This is the "v=spf1" portion of the caniphish.com SPF record. While it may seem like there are multiple versions that can be placed here, there is only one version, and it's version 1. Therefore, the SPF version will always be "v=spf1"

This component exists more as a relic of an old past. Back when the SPF protocol was still in its experimental phase in 2006, another authentication protocol, Sender ID (RFC 4406), was being experimented with. This protocol attempted to uplift the SPF protocol to include additional protections. Before Sender ID was deprecated, you could also list "spf2.0" as the SPF version.

Component 2: The SPF Mechanisms

This is the middle portion of the SPF record, which contains the "include" and "ip4" text.

These are called SPF mechanisms and indicate to email receivers what action should take place to determine whether the sending IP address is authorized.

The Include mechanism tells email receivers to lookup the SPF Record of the listed domain and then authorize all IP addresses listed within it, whereas the ip4 mechanism tells receivers the direct IP address to authorize.

While these two mechanisms are the most popular, there are a variety of others that can be listed in an SPF record. To get a full breakdown, please see the SPF RFC Standard (Section 5).

Component 3: The SPF Determination

This is the final portion of the SPF record, as depicted by the "-all" at the end of the caniphish.com example.

The SPF determination is a crucial aspect of an SPF record because it indicates to email receivers what action should take place if the sending IP address can't be matched to any SPF mechanism. In support of this, SPF records need to end with one of the following determinations:

• "-all": Referred to as SPF Hard Fail. When this determination is set, and SPF validation fails, it explicitly tells email receivers that the sender is not authorized to use the domain. If SPF validation fails, emails will typically be outright blocked by receivers.
• "~all": Referred to as SPF Soft Fail. When this determination is set and SPF validation fails, it tells email receivers that the sender is probably not authorized to use the domain. If SPF validation fails, emails will typically be filtered to recipients' Spam or Junk folders.
• "?all": Referred to as SPF Nuetral. When this determination is set, and SPF validation fails, it tells email receivers that no evaluation can be made as the domain does not assert whether the sender is or isn't allowed to send on their behalf. These emails will typically not be filtered based on SPF.
• "+all": Referred to as SPF Pass. When this determination is set, SPF cannot fail and will always pass. These emails will not be filtered based on SPF.

Note: Under no circumstances should the "+all" SPF determination be set. Cybercriminals will almost certainly begin abusing the domain for the delivery of maliciously spoofed emails.

Why Was The SPF Protocol Created?

Between the summer of 2003 and the spring of 2004, the SPF protocol began to take shape due to the growing need to verify and authenticate email sender identities to combat the growing amount of email spam circulating the Internet.

In April 2006, SPF was officially published with the release of RFC 4408 announcing it as an experimental protocol. This RFC outlined how SPF would allow domains to explicitly authorize which hosts (i.e., IP addresses) could send emails on their behalf. Over the years, SPF has evolved, such with the release of RFC 7208, and the release of DKIM and DMARC as supplementary email authentication protocols.

What Are Common SPF Misconfigurations?

There are a variety of ways that an SPF record can be misconfigured, and these misconfigurations fall into two categories: Configurational and Overpermissive.

Configurational Issues

There are seven distinct configurational issues that can occur when using SPF to prevent email spoofing. These issues, along with their severity, are outlined below:

1. No SPF record exists - Medium Severity Issue
2. No SPF "all" mechanism set or set to "?all" - High Severity Issue
3. SPF "+all" (Pass) mechanism set - Critical Severity Issue
4. SPF "~all" (SoftFail) mechanism set - Low Severity Issue
5. SPF has too many lookups for receiver validation - Medium Severity Issue
6. No SPF sub-domain record exists - Low Severity Issue
7. Trivial SPF lookup - Low Severity Issue

Notably, in 2023, the team at CanIPhish published research focusing on use of the "+all" SPF determination. This research involved the automated scanning of the 3 million most popular domains and found that over 1,000 domains were mistakingly configured using this highly vulnerable configuration.

Overpermissive IP Issues

Overpermissive IP issues are the result of SPF records, including IP address blocks that aren't wholly leased or owned by the relevant email senders.

For example, imagine your organization uses 256 IP addresses to deliver emails. You might consider referencing these IPs using a /24 CIDR notation if they're all in the same address space. When entering this CIDR notation, imagine you accidentally mistyped it as a /2. It sounds unlikely, but this exact issue occurs surprisingly often and results in 1,073,741,824 IP addresses being authorized to deliver emails instead of 256.

Throughout 2021 and 2022, the team at CanIPhish published research into overpermissive IP address ranges being used in SPF records and found that hundreds of organizations in Australia alone were vulnerable to SPF IP address takeover attacks.