Demystifying SPF Record Limitations

Communication is the hallmark of processes between governments, organizations, and individuals; there is a potent need to know what goes around; email is one of the cheapest means of communicating globally today. Cybercriminals know that many people utilize email platforms for communication and leverage this knowledge for email phishing attacks.

An unnerving report in 2019 says that 99% of cyberattacks use some form of social engineering, such as phishing emails, to access sensitive information. Usually, an email passes through the sender host’s server to the recipient server; there should be a measure to determine if the email is from an authorized IP address sender or a phishing campaign. 

If the email is from a phishing campaign, there must be dedicated efforts to block such phishing emails. As organizations send and receive millions of emails daily, you will need an app such as the sender policy framework (SPF) record to check your emails automatically.

What Is an SPF Record?

An SPF record is an app you can add to Domain Name Service (DNS) servers to enable your servers to determine whether the emails you receive are from a mean authorized sender IP address or could emanate from a phishing campaign. It’s a vital tool for email security and enables you to block phishing emails from reaching your organization or an individual.

Why Do You Need an SPF Record?

As the DNS entry that contains the IP addresses of domains and your organization’s official email servers that can send emails for your organization, an SPF record disables cybercriminals from spoofing your domain; when it is clean, spam filters will not block it. Your reputation and email deliverability are improved. 

However, your SPF limit of 10 DNS lookups can impact your reputation and deliverability; this can happen when your SPF record exceeds the 10 DNS lookup limitation; you will receive an SPF permanent error (PermError) report, which means the email receiver has considered your SPF invalid and blocks it automatically.

A PermError report can be detrimental; sometimes, you may be unaware that you have email deliverability issues. In SPF email authentication, every time your domain sends an email to your recipient’s domain, your recipient’s email server conducts DNS query requests, also known as DNS lookups, checking the presence of authorized IP addresses in your DNS and matching them to the ones in the received email’s return-path header. 

The standard SPF protocol specifications limit the number of DNS lookups to 10. That is the origin of the 10 DNS lookup limit. It’s easy to exceed the SPF 10 lookup limit from your cloud-based email exchange service provider and third-party vendors who add to the number of DNS lookups, returning the SPF PermError result.

To counter problems arising from PermError, you need SPF flattening.

What Is SPF Flattening?

SPF Flattening is taking an existing SPF record with multiple nested hostnames and converting them to a flat list of IP addresses or IP Address ranges, which will not count in the 10 DNS lookup tally. It is the standard process to ensure an SPF record doesn’t exceed the 10 DNS lookup limitation (SPF mechanism limit) and avoid too many lookup errors that will cause the rejection of all emails.

Limitations to SPF flattening can arise from third-party senders who regularly add new IPs and the high overhead you need to manage SPF flattening manually. It’s also possible for your email service providers to change or add to their IP addresses without notifying you; this will render your SPF inaccurate and leads to the same email deliverability problems you have tried to overcome.

If you must do manual SPF flattening correctly, you must monitor your email service providers constantly to observe any change. Organizations such as PowerDMARC have developed tools that enable automatic SPF flattening.

SPF flattening isn’t a one-time deal; hence, you need an automated process; you must change your SPF records every time your email service provider changes their infrastructure.

Organizations regularly invest large sums of money in email fraud training for employees. Notwithstanding the intensity of the fraud training, cybercriminals still find a way of deceiving people with business email compromise (BEC) attacks; they use highly-targeted and low-volume attacks to trick individuals by spoofing corporate identities and credential phishing scams. 

Unfortunately, they often succeed. Statistics from reputable sources such as Deloitte show that several targeted victims open phishing messages and click on malicious attachments.

The focus in fighting email phishing and the first line of defense should be email validation, not the people. 

Email validation removes the burden of guessing if the email is from an authentic source from the people; SPF records identify and block phishing messages before they get into your inbox. Incidentally, SPF has shortcomings and may not sufficiently block phishing emails targeting organizations and individuals.

Two of the challenges include: 

Accuracy: Third parties who send emails on your organization’s behalf may change or increase in number; if you don’t have real-time visibility into these changes, especially where you manually monitor, your SPF records will become outdated.

Tolerance: SPF is not the only signal email providers use to arrive at their delivery decisions. An SPF may fail, and the message still reaches your inbox.

Conclusion

App developers are contributing to making the world a safe place for everybody; cybercriminals are constantly upping their game; they seek flaws in any innovation they can exploit for their nefarious activities. The SPF record is one tool that helps to tackle email phishing by identifying and blocking them, and like a lot of tools in the market has its challenges; app developers need to work extra hard to ensure cybercriminals can’t exploit any flaw in the SPF record tool to defraud innocent users.