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.