SPF (Sender Policy Framework) syntax for DNS records is divided into three parts; mechanisms, modifiers, and qualifiers. We will perform an SPF record breakdown of the following example to help you understand what information each syntax conveys. 

First, let’s know why SPF records are important for domains and mail receivers’ mail servers. 

What is an SPF Record and How Does it Prevent Phishing and Email Spoofing?

An SPF record is a TXT record that is uploaded on your domain’s DNS to help recipients’ servers cross-check if a particular sending source is authorized to send email messages as a representative from your company or not. 

A DNS SPF record includes IP addresses (IPv4 and IPv6) and email servers that are identified as genuine and belong to your employees and specific departments (marketing, finance, HR, etc.). Sending sources not listed in the SPF record are considered fraudulent and unauthorized. 

In case a recipient receives an email message from your domain but the sending email address isn’t part of the SPF TXT record, it will either mark it as spam or disallow it to enter the mailbox. These instructions are laid down using a set of SPF record syntax.

spf record breakdown

Image sourced from techtradeasia.com

SPF Record Example

Here’s a hypothetical example that we’ll use to help you grasp the concept by its SPF record breakdown.

v=spf1 a mx ip4:192.168.1.1 include:_spf.example.com ~all

Now, let’s break down each element:

  • v=spf1 indicates the SPF version used, and currently, there’s no upgrade of the first version.
  • The ‘a’ tag tells the domain’s A record (IPv4 address) is permitted to send emails. It’s considered valid if the source matches.
  • ‘mx’  mechanism is helping in authorizing the domain’s mail server. 
  • ‘Ip4:192.168.1.1’ is the IP address that the domain owner has explicitly allowed to dispatch emails at the company’s behest. 
  • ‘Include:_spf.example.com’  allows the inclusion of another domain’s SPF record. In this case, the SPF record of _spf.example.com is considered as part of the current domain’s SPF policy.
  • The ‘~all’ refers to a softfail according to which recipients’ mailboxes are instructed to mark emails sent from unauthorized senders as spam.

SPF Softfail Vs. Hardfail

An SPF softfail commands recipients’ servers to flag unauthorized senders as spam, while an SPF hardfail directs to reject the entry of them outright. Now, the former sounds like a more forgiving fail-type, but it prevents the repercussions of false positives and hence is recommended. 

This simply means that, at times, messages sent by genuine senders are mistakenly flagged as suspicious. So, in case of a softfail, these emails will still be placed in the spam folder instead of not showing up at all if you enforce the hardfail policy.

spf record 2

SPF Qualifiers  

SPF qualifiers are optional, unlike SPF mechanisms. You can pair mechanisms with one of the following qualifiers.

QualifierResultAction Taken by Receiving Server with a Match
+PassIt directs that the message has passed the SPF authentication check, and the sending server can send messages. This is the default action taken when a record lacks a Qualifier.
–FailThis indicates that the email has failed the SPF verification process, which means the sending server isn’t allowed to send emails from that domain. In this case, the email gets rejected.
~SoftfailThe recipient’s server accepts the email, and it lands in the spam folder.
?NeutralIn this case, the email neither passes nor fails authentication checks since the SPF record doesn’t explicitly state whether the sender is authorized to send messages. It represents that there wasn’t a match when checked against your permitted IP address and domain.

It’s also important to run your SPF TXT records through tools for lookups so that you can fix existing syntax and configuration issues. An invalid and erroneous SPF record also triggers DKIM and DMARC troubles and exposes your organization to cyber menace.