4 Common Mistakes to Avoid While Creating an SPF Record

Sender Policy Framework (SPF) is an email authentication system that allows you to control which IP addresses are authorized to send emails from your domain. The receiving email servers check the SPF record of all the incoming messages. An email sent from your domain is only authenticated if its IP address is listed in your SPF record.

This simple and straightforward standard significantly helps in improving email authentication and reducing spam and phishing attacks. However, SPF also has some limitations that can make it a little difficult to implement correctly. So, here are the 4 common mistakes people make while implementing SPF that you should avoid at all costs. 

#1 Exceeding the SPF 10-Lookup Limit

For checking whether or not an email passes SPF authentication, the receiving mail servers may have to make multiple DNS lookups. However, to protect the receiving mail servers against denial of service attacks, these servers are not permitted to make more than 10 domain lookups while evaluating the SPF record for an incoming email. 

Once you go over your DNS lookup limit, the domain validation or authentication may break, allowing threat actors to spoof or misuse your domain. This means that once the limit has been exceeded, every email that requires a DNS lookup won’t achieve the complete result. You may even have many emails that fail to deliver without giving you any warning.

Exceeding the SPF 10-lookup limit is one of the most serious mistakes you can make while creating an SPF record, affecting your domain’s reputation and deliverability. SPF flattening offers the most effective solution to the problems caused by the SPF lookup limit. Flattening refers to the replacement of all the domains in your SPF record with their respective IP addresses. This eliminates the need for DNS lookups.

TDMARC is an expertly designed email domain security tool that comes with an Automatic Flattening feature that automatically flattens your SPF record, eliminating any effort on your part. 

#2 Multiple SPF Record

In case you are wondering how many SPF records you can have on a single domain, the only correct answer is ‘ONE’. If your domain has more than one SPF record, no one can tell which one will be used by the receiving mail servers to check for SPF authentication. It can also keep some of your legitimate emails from being delivered, adversely affecting your domain’s email deliverability rate. 

Make sure that a DNS query of type TXT results in just one TXT record that begins with v=spf1. In case you have to add more services to your SPF record, make sure you add them to the existing record instead of creating a new one. 

#3 Syntax Errors

In order to ensure that your SPF record works properly, it is essential to make sure that it is constructed correctly. There are several common syntax errors that can cause your emails to fail SPF authentication, preventing them from being delivered.

Here is an example of proper SPF syntax:

v=spf1 a mx ip4:192.168.0.1/16 include:returnpath.com include:tdmarc.com ~all

Here is a list of some of the most common syntax errors to keep in mind:

• There should be no extra spaces before the beginning of the string (v=spf1)
• There should be no extra spaces after the string’s end (~all)
• Make sure there are no misspellings in any of the record’s mechanisms like include, ip4, etc.
• Make sure there are no misspellings in any of the referenced domains
• Remove any uppercase characters from the ip6 or ip4 mechanisms
• Eliminate any extra special characters like dashes before the hard fail mechanism. For instance, replace –all with –all.
• Make sure there is only one space and no commas in between each mechanism
• Make sure your string starts with v=spf1 instead of any other mechanisms such as ip4

#4 Overlooking Domains That Do Not Send Emails 

Most people simply protect their active mail sending domains with SPF and don’t bother putting all that effort into creating an SPF record for non-mail sending domains. Cybercriminals often spoof non-mail sending domains to get around an organization’s defenses. If you have one or more domains that do not send any emails, the best thing you can do is publish null SPF records for them. 

Publishing a null SPF record (“v=spf1 -all”) for any domain clearly declares that this domain does not send any emails. For example, if your domain example.com is not used to send any emails, you can publish the following SPF record for it:

“v=spf1 a:mail.example.com -all”

Keep these common SPF errors in mind while creating an SPF record for your domain to ensure proper email security. 

Are there any other SPF mistakes you would like to add to the list? Leave a comment!