Learning and implementing the concepts of SPF is important for technology-driven businesses. It can protect them against potential risks of phishing, spamming, BEC attacks, etc. SPF or Sender Policy Framework works by using an SPF record which comprises SPF Syntax.

This blog broadly speaks about the SPF syntax table, SPF mechanisms, SPF qualifiers, and SPF modifiers- all of which are necessary to get a strong grip on the concept of email authentication using technical protocols.

Key Takeaways

Understanding SPF is essential for technology-driven businesses to protect against phishing and email spoofing.
An SPF record is a crucial DNS entry that specifies which IP addresses are authorized to send emails on behalf of your domain.
Creating and regularly checking SPF records is vital to defend against unauthorized use of your domain in email attacks.
SPF mechanisms, qualifiers, and modifiers are key components that dictate how receiving servers interpret SPF records.
Maintaining a single, correctly formatted SPF record is necessary to ensure optimal email security and deliverability.

SPF Syntax for Benginners

An SPF record is a DNS record that includes a list of all the IP addresses allowed to send emails using your official domain name. When a server outside the list sends an email using the domain, it’s treated as unauthorized. Thus, its entry is rejected by the receiver’s mailbox. This protects your company’s name from getting involved in malicious activities initiated by hackers.

Companies should create and check SPF records to steer clear of phishing attacks attempted by using their own domain names. Over 255 million phishing attacks have been recorded in just the first half of 2022! Imagine how crucial it has become to implement SPF and learn about SPF syntax.

An SPF record has instructions directing the recipient’s server to check and validate emails received from your domain. It also tells what is to be done with the ones failing authentication. A specific component represents all the instructions.

Let’s break down each element using an SPF record example. This is what an SPF syntax looks like.

v=spf1 ip4:123.1.5.0 ip4:100.5.2.1 include:exampledomain.com ~all

The function of each element is as follows:

v=spf1 specifies to the receiving server about an SPF record. All SPF records must start like this.
The next section of this SPF syntax tells the IP addresses permitted to send emails using your domain. In the above example, we have ip4:123.1.5.0 and ip4:100.5.2.1
The ‘include:exampledomain.com’ section of the above example specifies the third parties allowed to send emails using the domain. The ‘include’ tag indicates recipient servers to verify the included domain’s (exampledomain.com) SPF record for IP addresses that are also authorized. You can add multiple domains within an SPF record; however, they must be valid.
The -all element directs receiving servers to mark emails as NOT PASS for SPF if they are sent from any domain or IP address outside the list specified in the SPF record

Simplify Syntax with PowerDMARC!

Start 15-day trial Book a demo

Advanced SPF Syntax

An SPF syntax table is defined using a DNS TXT record with a single string of text. It always begins with the ‘v=’ element that specifies the SPF version used, and there’s just one version as of now.

All the SPF records have their specific terms enlisted that behave as rules for which hosts are permitted to share messages using the official domain it may also display some extra information.

In advanced SPF syntax we will break down the following three components; SPF Mechanisms, SPF Qualifiers, and SPF Modifiers.

SPF Mechanisms

ALL: It always matches and is the last mechanism added at the end of an SPF record. It displays default results like ‘-all’ for unmatching IPs.
A: It indicates a domain name with an AAAA or A record as a match since it sorts out the sender’s address. The current domain is used if this DNS SPF record syntax is unspecified.
ip4: A match is positive if a sender is connected to the given ipv4 address range in the SPF record. You add this with a prefix specifying a range’s length. /32 is used when there’s no prefix.
ip6: A match is positive when the sender is allied to the specified ipv6 address range. It’s added with the ip4 directive and a prefix indicating range length. /128 is used when there’s no prefix.
MX: It permits senders with an IP address that’s same as the one included in the MX record specified. MX records consist of an IP address and priority value for each server to accept messages.
PTR: It specifies the authorized domain to help resolve IP addresses to subdomains or domains. For all the exactly matching domains or subdomains, a forward lookup is done to get the IP address.

This mechanism is considered time-consuming and unreliable since it needs multiple lookups. It’s not recommended according to the RFC 7208 guidelines.

EXISTS: It conducts a DNS A record search for the domain entered. A match is successful when a valid A record is found, irrespective of the actual lookup result.
INCLUDE: It authorizes third-party email senders by stating their domains. A sender is authorized only if its IP address matches the IP addresses or domains provided in the SPF record of the listed domain.

SPF Qualifiers

When a mechanism doesn’t have a qualifier, and there’s still a successful match, SPF authentication passes. Each of the 8 mechanisms is coupled with one of the four qualifiers mentioned below.

Qualifier	Result	Action Taken by Receiving Server
+	Pass	Email successfully passes SPF authentication, and the server can exchange emails. Emails are marked as genuine. This is the default action applied if there’s no qualifier.
–	Fail	Email fails authentication because the sending server doesn’t belong to the list. The mail may get rejected by the receiver’s mailbox.
~	SoftFail	The receiver’s mailbox accepts the message; however, it is marked as suspicious and lands in the spam folder.
?	Neutral	Email message neither passes nor fails authentication. The action taken is unspecified and the email is accepted by the receiver.

SPF Modifiers

SPD modifiers are responsible for determining the working parameters of an SPF syntax. It includes name or value pairs separated by the ‘=’ symbol, which shares extra details and exceptions to rules, if any.

Modifiers appear just once and only in the last section of an SPF record. All the unidentified modifiers are ignored in the process. The ‘redirect’ modifier is used to direct other SPF records for authentication. It’s used when you want more than one domain to have the same SPF record content.

The ‘include’ mechanism is used for third-party domains permitted to send emails on your behalf or using your business name. The ‘exp’ modifier specifies why the receiving server returned a Fail SPF Qualifier when a mechanism matches.

Guidelines for SPF Records

Keep the following in mind while creating an SPF record using the SPF syntax table.

You can’t align multiple SPF records for one domain.
An SPF record must not have any uppercase letters; otherwise, you would see errors.
There shouldn’t be more than 255 characters. Any string exceeding this number will result in failed authentication.
Delete if there are any SPF mechanisms resolving to the same domain.
Delete any ip4 and ip6 SPF mechanisms not in use. Also, check if you can merge any address ranges.
You can create subdomains to store SPF information. This can be done using ‘_spf.domain.com.’ It’s recommended for big IT firms as they have multiple IP addresses to add to one SPF record.

About
Latest Posts

Yunes Tarada

Domain & Email Security Expert at PowerDMARC

Yunes is an Operations Team Lead at PowerDMARC with expert knowledge in email authentication and security. Yunes is a Microsoft-certified Azure Administrator Associate with certifications in CompTIA A+ and many more.

SPF Syntax: A Complete Guide