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. 

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: ip4: ~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: and ip4:
  • The ‘’ 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 ( 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

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

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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. 
  6. 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

  1. 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.
  2. 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 ‘’ It’s recommended for big IT firms as they have multiple IP addresses to add to one SPF record.

You can send emails without using SPF or knowing about SPF format, but that won’t be safe. SPF adds an additional trust indication to recipients’ mailbox providers, and all the authentic emails sent using your domain land in the box inbox instead of being marked as spam.

SPF isn’t a fool-proof method; therefore, you must combine it with other email authentication protocols like DKIM, DMARC, and BIMI to improve email deliverability.

Since these protocols are crucial to the email authentication process and all email-driven businesses must know about them, we’ll focus on the SPF record format in this blog. 

What is SPF?

SPF is short for Sender Policy Framework- one of the most common email authentication protocols. It works using a list of IP addresses authorized to send emails using your domain name. The list typically includes IP addresses of your employees, shareholders, and third parties that directly use your domain to send emails.

If you’ve implemented SPF, any email sent from an IP address outside the list is considered unauthorized by the recipient’s mailbox.

How is Email Authenticated Using SPF?

You need to publish a valid SPF record (in TXT format) on your DNS to implement this protocol. When an email is sent from your domain, the receiver’s mail server cross-checks the sender’s IP address with the SPF records on your DNS. If it’s on the list, validation passes, and the email lands in the inbox. However, if it isn’t on the list, authentication fails, and emails don’t reach their destination.

After implementing it, you must regularly monitor your domain activity using an SPF checker to ensure it isn’t on a hacker’s radar. This can prevent spear phishing, scamming, and ransomware attacks attempted using your company’s name.

SPF Format

SPF record is complicated and has a typical format that’s difficult to understand. Here we’ll be discussing SPF record syntax and SPF record structure- the head and heart of SPF record format.

SPF Record: Basic Syntax

An SPF record is a DNS record enlisting all the IP addresses allowed to send emails using your email domain. This is what an SPF record syntax looks like:

v=spf1 ip4= ip4= -all

Let’s check out the elements included in this.

  • v=spf1- It tells the server that this contains an SPF record. Every SPF record must begin with this string.
  • ip4= ip4= It indicates the IP addresses allowed to send emails using a specific domain.
  • It tells third parties authorized to send emails. The ‘include’ tag directs the recipient servers to verify the included domain’s (here- SPF record. You can add several domains within one SPF record.
  • -all: tells recipient servers to reject emails coming from unauthorized IP addresses, basically the ones not included in the list. 

SPF Record: Advanced Syntax

As per the SPF record format for syntaxes, it always starts with the ‘v=’ element. It tells the SPF version; currently, there’s only one version, so all SPF record formats begin like this. 

SPF record syntax has three primary elements; SPF Mechanism, SPF Qualifiers, and SPF Modifiers. Let’s see what they are.


Here are the eight mechanisms

  1. ALL: This means there’s always a match. You’ll see default results like ‘-all’ for unmatching IPs.
  2. A: Domain name with A or AAAA address record matches as they can be resolved to the sender’s address.
  3. IP4: The match is valid when the sender is linked to the given IPv4 address range.
  4. IP6: The match is valid when the sender is linked to the given IPv6 address range.
  5. MX: Sender’s email address is validated only if their domain name includes an MX record for resolution.
  6. PTR: The match is authorized if the PTR record belongs to a given domain resolving to the client’s address. Experts don’t suggest its use as it might block all emails sent using your domain.
  7. EXISTS: It works if the given domain name is validated. This SPF mechanism functions with all resolved addresses. 
  8. INCLUDE: It references other domain policies. So, if that passes, it passes automatically. However, if the included policy fails, processing continues. 


Modifiers determine an SPF record’s functional framework. It consists of name or value pairs separated by the ‘=’ symbol, pointing out additional information. You’’ see them many times at the end of the SPF record, and all the unrecognized modifiers are ignored in the process.

The ‘redirect’ modifier directs to other SPF records responsible for efficient functioning. Experts use them whenever more than one domain is linked to the same SPF record. This modifier must be used if a single entity controls all the domains; otherwise, the ‘include’ modifier is used.


Each mechanism can be combined with one of four qualifiers.

‘+’  for the PASS result

‘?’  for a NEUTRAL result interpreted like NONE policy.

‘~’ for SOFTFAIL. Usually, messages that return a SOFTFAIL are accepted but tagged. 

‘-’ for FAIL, the email is rejected.


SPF prevents cyberattacks committed using your brand’s name and reputation. You can stop emails sent by hackers using your domain from reaching their target audience. This works by enlisting and allowing only trusted entities to send emails using your domain. 

After understanding the SPF record format’s structure and components, you can use the SPF record generator if you haven’t implemented the protocol yet.

The Sender Policy Framework (SPF) record is an important part of the Domain-based Message Authentication, Reporting and Conformance (DMARC) protocol that specifies a method to prevent sender address forgery.

SPF records are complex to set up and implementation issues can occur if they are not properly configured. Also, SPF Record Syntax uses some specific terms that can be confusing when first encountered. Therefore, in this blog post, we look at SPF record syntax and what you need to consider when you configure them.

What is an SPF Record?

An SPF record is a type of DNS record that identifies which servers are allowed to send an email on behalf of your domain. It does this by listing the servers that have been authorized to send emails for your domain; if any other server tries to send an email on behalf of your domain, it will be rejected as an unauthorized sender.

The purpose of an SPF record is to prevent malicious users from sending forged email messages with your domain in the From field. This can happen if an attacker sends out mass amounts of spam emails from your server by spoofing or forging your domain

How does SPF work?

1. Creating an SPF Record Syntax

You create an SPF record syntax in your DNS server that specifies which IP addresses are permitted to send emails from your domain. This means that if someone were trying to send spoofed emails from your domain, their messages would fail because the IP address of their mail server would not be listed as one of the approved servers.

For example, if you want only Gmail accounts to be able to send mail from your domain name, but not Outlook accounts, then you would add the following line to your SPF record:

 v=spf1 a mx ~all

 This tells servers that any messages sent from any host whose IP address ends with should be considered valid (m), whereas all other messages should be discarded (a). 

You can use our SPF record generator tool to start creating a free record now!

2. DNS Lookup

When an email sender attempts to send a message, the recipient server performs a DNS lookup on the sending domain to see if there is an SPF record—this is called “authentication.”There is a limit of 10 lookups allowed per query, exceeding which leads to SPF permerror

If there is no SPF record, then authentication fails and the message is not delivered. If there is an SPF record, then the SPF server checks for IP addresses in the TXT record at the hostname specified in the SPF record.

 If there are no IP addresses specified, then it will fail authentication. Otherwise, it will perform an A query for each IP address specified in the order of appearance in the TXT record.

The IP address that returns a result code of NXDOMAIN or NOERROR will be considered authorized by the SPF server and its hostname will be added to a list of authorized sending hosts for that domain.

3. Authentication Outcome

The mail server either delivers the message to the recipient or flags it for rejection based on the rules specified in the SPF record.

Authentication outcomes can take three forms: Pass, Neutral, or Fail.

Pass means that the mail server accepts the message as legitimate and allows it to be delivered. Neutral means that there is either no record at all or an invalid one for that domain in DNS, so there is no way of knowing whether or not this is a legitimate message from that domain. Fail means that something about this message was not authentic enough for it to be delivered.

For example, a mail server with IP address ‘’ sends an email from ‘[email protected]’. The inbound server will consult the domain name service (DNS) to determine if this IP address is authorized to send emails on behalf of the ‘’ domain. If so, the message will be delivered; otherwise, it will be discarded or marked as spam i.e sorted according to the mechanism specified in the SPF record.

SPF Record Syntax

The SPF record syntax comprises several elements–Directives, Qualifiers, and Mechanisms.

Directives are the first part of an SPF record syntax. They indicate how to interpret the rest of the record. Three directives can appear in an SPF record: v=spf1, a, and mx. The v directive indicates that this record is an SPFv1 record; the a directive indicates that this record is an SPFv2-style authentication failure report; the mx directive specifies a list of mail exchange servers for a domain.

Qualifiers specify where in your DNS zone you want to place your SPF records: exim4, enduser, or _spf. These qualifiers tell mail receivers where to look for your SPF records when they’re checking them against their DNS records.

Mechanisms are used to indicate how you want to handle email addresses that fail your SPF check. You can choose from several mechanisms: all, none, softfail, neutralize, or reject.

  • all mechanism will accept all emails from senders who have passed your SPF check;
  • none will reject everything from senders who have passed your SPF check;
  • softfail will accept emails from senders who have failed an SPF check, but mark them as suspicious;
  • neutral states that you’re neither rejecting nor accepting messages sent from your domain—it’s essentially a “no opinion” stance on whether the message should be accepted or rejected;
  • reject will reject emails that failed the SPF check.

SPF Record Syntax Qualifiers

 The “qualifiers” in an SPF record syntax help to indicate the scope of the SPF record. These are primarily used to indicate whether or not a specific IP address is authorized to send emails on behalf of your domain. 

Qualifier Result Code Explanation
+ Pass the only qualifier with no negative connotation. It indicates that the domain name’s security record contains no errors or warnings and is considered secure.
Fail indicates that the domain name’s security record contains errors or warnings that prevent it from being considered secure.


~ Softfail indicates that the domain name’s security record contains errors or warnings that do not prevent it from being considered secure, but may indicate problems with DNS resolution or other issues related to DNS trust anchors.
? Neutral Indicates that the domain has no SPF record or its record was syntactically correct but did not match any sending servers when checked against one (or more) sending servers in your list of trusted IP addresses for that domain.

SPF Record Syntax Mechanisms 

Mechanisms are used in the SPF record syntax to tell the receiving server what kind of authentication mechanism should be used. There are two types of mechanisms: 

  •       the sender can specify a specific set of mechanisms;
  •       Or it can specify that all mechanisms are allowed. 
Mechanism Purpose Directive Applies When Implementation
a defines the DNS A record of the domain as authorized. If this directive is unspecified, then the current domain is used.



can be applied when queried for an A or AAAA record in a domain that contains the sender’s IP address. a




all The all directive is always matched, and it defines the policy for all other sources. This mechanism should always be applied, and this mechanism always matches. all
exists Checks whether or not an A record is valid for a given domain. It works by looking at all A records on that domain and seeing if any of them match the criteria set out in your SPF record. Applies when there is any A record on said domain or if other criteria, according to RFC7208, were authorized. exists:<domain>
include The purpose of this mechanism is to specify the domain and search for a match, as well as to return a permanent error if the domain does not have a valid SPF record. The “include” mechanism in SPF records can be used to include other SPF records within a domain’s record. If a domain does not have an SPF record, but another domain does and that other domain has an IP address that matches the IP address of the sender, then the “include” mechanism will cause the domain with the matching IP address to be used for authorization purposes.


ip4 You can specify an IPv4 range with the “ip4” directive, along with a prefix that denotes the length of the range. If no prefix is specified, /32 is assumed. The “ip4” mechanism will apply if any of these conditions are true:


– The specified IPv4 address matches that of an IP address in your SPF record.


– The specified IPv4 subnet contains the sender’s IP address.



ip6 You can specify an IPv6 range with the “ip4” directive, along with a prefix that denotes the length of the range. If no prefix is specified, /128 is assumed. The “ip6” mechanism will apply if any of these conditions are true:


– The specified IPv6 address matches that of an IP address in your SPF record.


– The specified IPv6 subnet contains the sender’s IP address.



mx The “mx” mechanism, as defined in the SPF record, defines the Domain Name System (DNS) Mail Exchanger (MX) record of a domain as authorized. The DNS MX record determines which server is responsible for accepting email messages on behalf of the domain. The DNS MX record contains an IP address and a priority value for each server that can be used to accept messages.


When an MX record of a domain contains an IP address that matches the sender’s IP address, then this indicates that this sender is authorized to send emails on behalf of this domain.





ptr The ptr mechanism uses the reverse hostname or subdomain of the sending IP address to define the target domain name. Only applies if there is at least one MX record for the queried or specified domain and that MX record contains a PTR record with an FQDN for the sender’s IP address. ptr


SPF Record Syntax Modifiers

In the SPF record syntax, modifiers can be used to change the default behavior of an SPF record. Modifiers may be used to specify exceptions to the rules, or they may be used to provide additional information to the receiver.

Modifier Purpose Implementation
exp The “exp” modifier is a value that specifies an explanation for why a message was rejected. It is intended to help senders avoid certain kinds of issues, and can be used to inform them about the specific reason their message was not accepted by the receiving server. exp=<domain>
redirect The redirect modifier is a string that replaces the entire domain name in the SPF record. The purpose of this modifier is to redirect all mail sent to the domain to another server. This may be useful for domains with multiple MX records or for domains that have been re-assigned to another company but are still using the same email addresses. redirect=<domain>

Wrapping Up

The SPF record is an important part of your domain’s DNS records. It tells other mail servers how to authenticate messages that claim to be from you, which means that it’s important for you to have a properly configured SPF record. However, make sure you pair SPF with DMARC for enhanced protection against email compromise and spoofing. 

The SPF Record Lookup Tool can help you do just that. The lookup tool will give you a quick overview of what your current SPF record looks like, including whether or not it’s missing any required fields.The generator will let you create an SPF record syntax from scratch, complete with all required fields so that it can be added to your DNS records right away.