Combining SPF Records for Domain Authentication

When it comes to email authentication, setting up an SPF (Sender Policy Framework) record is an essential step. This DNS record helps to verify which IP addresses or hostnames are authorised to send emails on behalf of your domain. However, complications can arise if you utilise multiple email services, leading to the need for multiple SPF records. In these circumstances combining SPF records is a necessary step and here’s how to tackle these challenges effectively.

Understanding the Need for a Single SPF Record

Before diving into the how-tos, it’s important to note that a domain should only have one SPF record in its DNS settings. Multiple SPF records can render email authentication ineffective. In fact, some hosting providers won’t even allow more than one SPF record. For an illustrative example of what error is shown when more than one SPF record is found, refer below:

Additionally, for a depiction of the “fail” status that occurs with multiple SPF records, here’s what that could look like:

To validate your SPF records and investigate issues, the MX Toolbox SPF tool is an excellent resource.

The Building Blocks of an SPF Record

To better understand combining SPF Records, let’s break down its mechanisms using an example. Suppose you’ve authenticated your domain through Outlook, and your SPF record reads as follows:

v=spf1 a include:spf.protection.outlook.com -all

You now wish to also authenticate through Elastic Email, requiring this SPF record:

v=spf1 a mx include:_spf.elasticemail.com ~all

Mechanisms Explained:

• v=spf1: Specifies that the record uses version 1 of SPF.
• a: Indicates that the sending IP must match the A record of the From domain.
• mx: Specifies which email servers should be used when emails are relayed.
• include: Instructs the DNS to include the specified domain in your SPF setup.
• all: The final part, which defines how emails should be treated based on qualifiers like +all, ?all, -all, and ~all.

How we look at Combining SPF Records into One

Combining SPF records involves merging different mechanisms from each record into a single entry. Avoid repeating mechanisms that appear in both original records. For example, since both records have an a mechanism, include it only once in the new, combined record.

The ending qualifier (all) must also be chosen carefully, as it can only appear once. You’ll need to decide between ?all, -all, or ~all based on your email authentication needs.

Example of a Combined SPF Record

Here’s what a combined SPF record, including both Outlook and Elastic Email mechanisms, would look like:

Original SPF Records:

• For Outlook: v=spf1 a include:spf.protection.outlook.com -all
• For Elastic Email: v=spf1 a mx include:_spf.elasticemail.com ~all

Steps to Combine:

1. Start with v=spf1 as this is common to all SPF records.
2. Include the a mechanism, which is common to both records, only once.
3. The mx mechanism is unique to the Elastic Email record, so include it.
4. Include the include: mechanisms from both records: include:spf.protection.outlook.com and include:_spf.elasticemail.com.
5. Finally, you must decide on a single qualifier for all to end the record. You can choose -all, ~all, or ?all.

How to Merge Multiple SPF Records:

Here’s how the combined SPF record would look:

v=spf1 a mx include:spf.protection.outlook.com include:_spf.elasticemail.com -all

Or, if you prefer the SOFTFAIL (~all) qualifier:

v=spf1 a mx include:spf.protection.outlook.com include:_spf.elasticemail.com ~all

Remember, you can only have one SPF record in your domain’s DNS settings, so merge multiple spf records with this combined version. After the change, you can validate your new SPF record using tools like the MX Toolbox SPF tool to make sure everything is set up correctly.

What is the difference between ~all and -all?

The ~all and -all mechanisms are qualifiers in an SPF (Sender Policy Framework) record that define how email from IPs not explicitly authorised should be handled. Here’s how they differ:

~all (SOFTFAIL)

The tilde (~) in front of all indicates a SOFTFAIL. If an email is sent from an IP address not listed in your SPF record but still claims to be from your domain, receiving servers are advised to accept the email but to tag it for further scrutiny. This could mean marking it as suspicious or routing it to a spam or junk folder, although the exact behaviour depends on the receiving server’s configuration.

The ~all is generally used when you’re testing or in the process of implementing SPF, as it allows for more flexibility. Emails won’t be outright rejected based on the SPF check, giving you some leeway to correct any issues that might arise.

-all (FAIL)

The dash (-) in front of all indicates a FAIL, or “hard fail.” If an email is sent from an IP not listed in your SPF record and claims to be from your domain, the receiving servers are advised to reject the email outright. This setting is stricter and provides a stronger assertion that only the IPs listed in your SPF record are permitted to send emails from your domain.

The -all is used when you’re confident that your SPF record is correctly set up and want to enforce strict rules for email authentication. This reduces the chances of unauthorised or spoofed emails being accepted.

Summary

• ~all: SOFTFAIL, more lenient, emails from unauthorised IPs are accepted but tagged.
• -all: FAIL, strict, emails from unauthorised IPs are generally rejected.

Both of these options have their uses, and which one to use will depend on your specific needs and the level of confidence you have in your SPF setup. After you’ve decided, you can validate the SPF record using external tools like the MX Toolbox SPF tool.

You may also find the following article of interest: What are DKIM Records and why you should use them?