SPF stands for “Sender Policy Framework”. SPF is an email authentication method, and it helps servers authenticate that messages appearing to come from a specific domain are sent from servers authorized by the domain owner. It is implemented using the TXT type records known as SPF records. It helps protect your domain from phishing and spoofing, and it also ensures that your messages are delivered correctly.

In this post, we will discuss how to avoid one of the common SPF issues when setting up multiple SPF records for a single domain.

Avoid Multiple SPF Records

A domain must not have multiple SPF records as both will be declined by the recipient server, making the authentication impossible. As a result, your emails might end up going to your recipient’s spam boxes. Some DNS registrars will not even allow you to have more than one SPF record.

If you need to include more than one SPF record for your domain, you should merge them into a single record.

How to Merge Multiple SPF Records

To merge multiple SPF records into a single record, you need to incorporate all the mechanisms or values in the same record. Let’s assume you have the following SPF record for the Elastic Email.

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

Now, you want to add the second SPF record for the Rackspace mailbox.

v=spf1 include:emailsrvr.com ~all

Before merging, let’s look at the different SPF record mechanisms to understand the merging process better.

Mechanism

Description

v

The first part of an SPF record starts with v=spf1, which identifies this DNS record as the first SPF version.

ip4

It specifies a mail server or servers by IPv4 address or address range, e.g., ip4: 192.168.1.1

a

It indicates a mail server by domain name, e.g., a:mailsrvr.com

mx

It specifies all of the mail servers by referring to a domain MX record, e.g., mail.mailsrvr.com. Please note that the MX mechanism is optional. If you don’t specify a domain name, the default value is used, which is the MX records of the domain where the SPF record is set up.

include

The middle part of an SPF record begins with an “include” mechanism that specifies mail servers of a domain besides your domain. We use this mechanism to allow third-party mail senders.

all

The “all” mechanism is the last part of an SPF record. It specifies how an email should be treated. It should always be placed at the end of the record. This mechanism will include one of the following qualifiers:

  • +all — It is the default prefix when no qualifier is used. It refers to Pass. The server with a matching IP address or domain is allowed to send for the domain.

  • -all — It refers to Fail. The server with a matching IP address or domain is not allowed to send for the domain. The SPF record does not specify the sending IP address of the server or domain.

  • ~all — It refers to Soft fail. The server with matching IP or domain address might be allowed to send for the domain. The recipient server will accept messages and tag them as suspicious.

  • ?all — It refers to Neutral. The SPF record doesn’t explicitly declare that the IP address or domain is allowed to send for the domain.

Getting back to our example, we have the following two records.

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

To merge the SPF values, include all the parts into one single record without repeating any mechanisms.

  • If one of the records (or both) has an “a” mechanism, it should only be included once at the beginning.

  • If one of the records (or both) consists of an “mx” mechanism, it should also be included once.

  • The “include” mechanism is added to specify the mail servers from both SPF records.

  • The last part has to be “?all”, “-all”, or “~all”. It is impossible to have more than one qualifier, so it is your decision to choose which declaration of “all” your domains will use.

The merged SPF record will be:

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

Important

Some recipient servers cannot pass SPF records because the “include” mechanism has a “+” qualifier before it. The default parameter for the mechanism is a pass, and the “+” qualifier also means pass, so it becomes redundant. Therefore, the “+” qualifier can be omitted from the “include” mechanism.

Merging multiple SPF records into one might lead to too many DNS lookups, resulting in domain authentication failure. So how to rectify this issue?

DNS Lookups Limit

An individual SPF record has a ten “include” lookups limit. It means your record cannot generate more than ten references to other domains. It is done to reduce the load on the email receivers’ side. The following mechanisms count as lookups:

  • include

  • a

  • mx

  • ptr

  • exists

  • redirect

Here is an example record that exceeds the SPF record limit.

v=spf1 a mx include:example1.com include:example2.com include:example3.com include:example4.com include:example5.com include:example6.com include:example7.com include:example8.com include:example9.com include:example10.com -all

Here is another example that complies with the SPF record limit.

v=spf1 a mx include:example1.com include:example2.com include:example3.com include:example4.com include:example5.com include:example6.com -all

To avoid such issues, you can remove “includes” and references to all those domains which are no longer in use. Another solution would be to use subdomains as it will allow an additional SPF record.

Once you have added or updated the DNS records, it may take up to 24 hours for your changes to be effective across the internet.

That’s it! We hope this article was helpful. If you need any help, then feel free to search your query on Cloudways Support Center or contact us via chat (Need a Hand > Send us a Message). Alternatively, you can also create a support ticket.

Did this answer your question?