Email authentication only works when your SPF record is written correctly. Even if you’ve authorized the right mail servers, a small syntax mistake can cause SPF validation to fail, affecting email deliverability and leaving your domain vulnerable to spoofing attacks. That’s why understanding SPF record syntax is essential for anyone managing DNS records or email infrastructure.
An SPF record follows a specific format that receiving mail servers use to verify whether an email is coming from an authorized sender. Every mechanism, qualifier, and modifier has a defined purpose, and even a misplaced character can change how the record is interpreted.
In this guide, you’ll learn the SPF record format specification, understand each component in simple terms, explore real SPF record examples, and discover best practices to create a valid, reliable SPF record
What is SPF Record Syntax
An SPF record is a DNS TXT record that tells receiving mail servers which servers are allowed to send emails on behalf of your domain. SPF record syntax refers to the set of rules used to write this record correctly. Every part of the record has a specific purpose, such as identifying the SPF version, listing authorized mail servers, including trusted third-party services, and defining what should happen if an email fails the SPF check.
If the syntax is incorrect, receiving mail servers may ignore the record completely, causing legitimate emails to fail authentication or making your domain more vulnerable to spoofing. That’s why understanding the syntax for an SPF record is just as important as creating one.
SPF records can be simple for small businesses or more advanced for organizations that use multiple email providers and cloud services. Let’s first understand the basic structure before looking at the advanced format.
Basic SPF Record Syntax
A simple SPF record contains a version identifier, one or more rules that define authorized senders, and a policy that tells receiving servers how to treat emails that don’t match those rules.
For example:
v=spf1 ip4:192.0.2.10 include:spf.example.com -all
In this SPF record example, v=spf1 identifies the record as an SPF record, ip4 authorizes a specific IPv4 address, include trusts another domain’s SPF policy, and -all tells receiving mail servers to reject emails sent from any source that is not explicitly authorized. Even though the record is short, every element follows a defined SPF record format specification.
Advanced SPF Record Syntax
As email environments become more complex, SPF records often include additional mechanisms, qualifiers, and modifiers to support multiple mail servers, cloud platforms, and third-party services. These components allow organizations to build more flexible SPF policies while still following the same SPF syntax rules.
We’ll break down each of these components in the following sections so you can understand exactly what they do and when to use them.
SPF Record Components Explained
An SPF record is built using three main components: mechanisms, qualifiers, and modifiers. Together, they tell receiving mail servers who is allowed to send emails for your domain and how to handle messages that pass or fail SPF authentication.
SPF Mechanisms
SPF mechanisms define which mail servers or IP addresses are authorized to send emails on behalf of your domain. They are evaluated from left to right until one of them matches.
| Mechanism | Purpose |
| all | Matches every sender. It is always placed at the end of the SPF record and acts as the default rule for any sender that didn’t match an earlier mechanism. |
| ip4 | Authorizes a specific IPv4 address or network range. For example, ip4:192.0.2.10 allows a single IPv4 address, while ip4:192.0.2.0/24 authorizes an entire subnet. |
| ip6 | Works the same way as ip4 but for IPv6 addresses and networks. |
| a | Authorizes the IP address returned by the domain’s A or AAAA DNS record. This is useful when your mail server uses the same IP address as your website or hostname. |
| mx | Authorizes the servers listed in the domain’s MX records. If an email is sent from one of those mail servers, it passes this mechanism. |
| include | References another domain’s SPF record. This is commonly used to authorize third-party email services such as Google Workspace, Microsoft 365, Mailchimp, or SendGrid without manually adding all of their IP addresses. |
| exists | Checks whether a DNS A record exists for a specified domain. It is mainly used in advanced SPF configurations with macros and is uncommon in most deployments. |
| ptr | Uses reverse DNS lookups to verify the sending server. Because it requires multiple DNS lookups, is slow, and can produce unreliable results, RFC 7208 discourages its use, and many receiving mail servers ignore it altogether. |
SPF Qualifiers
A qualifier tells the receiving mail server what action to take when a mechanism matches. If you don’t specify one, the default qualifier is + (Pass).
| Qualifier | Result | What it means |
| + | Pass | The sender is authorized. This qualifier is optional because it is the default behavior. |
| – | Fail | The sender is not authorized. Receiving servers are instructed to reject the message. This is commonly seen as -all. |
| ~ | SoftFail | The sender is probably not authorized. The email is usually accepted but may be placed in the spam folder or treated as suspicious. |
| ? | Neutral | SPF does not make a decision about the sender. The receiving server neither treats the email as authenticated nor unauthenticated based on SPF alone. |
During SPF evaluation, you may also encounter these authentication results:
- None: No SPF record exists for the domain.
- TempError: A temporary DNS or lookup issue prevented SPF validation.
- PermError: A permanent problem, such as an invalid SPF record syntax or an incorrectly formatted record, prevented SPF evaluation.
SPF Modifiers
Modifiers provide additional instructions that change how an SPF record is evaluated. Unlike mechanisms, they do not directly authorize sending servers. They are optional, appear only once, and are placed at the end of the SPF record.
The two standard SPF modifiers are:
- redirect: Redirects SPF evaluation to another domain’s SPF record. It is useful when multiple domains share the same email infrastructure. Unlike the include mechanism, redirect completely hands over SPF evaluation to the referenced domain. It is generally recommended only when you control both domains.
- exp: Specifies a domain that contains a human-readable explanation for SPF failures. Although it is part of the SPF specification, it is rarely used in modern email deployments because most receiving mail servers ignore the explanation.
SPF Record Syntax Examples
Now that you know the different components of an SPF record, let’s see how they work together. The following SPF record examples show how the correct syntax is used in real-world situations.
Example 1: SPF Record for a Single Mail Server
v=spf1 ip4:198.51.100.25 -all
Here’s what each part means:
- v=spf1 identifies the record as an SPF version 1 record.
- ip4:198.51.100.25 authorizes this specific IPv4 address to send emails for the domain.
- -all tells receiving mail servers to reject emails sent from any server that isn’t explicitly listed in the record.
Why this SPF record is valid:
- It starts with the required version tag.
- The authorized sending IP is defined using the correct ip4 mechanism.
- The all mechanism is placed at the end of the record, as required by the SPF record format specification.
- The syntax is complete and follows SPF rules.
This type of SPF record is commonly used by small businesses or organizations that send emails from a single mail server.
Example 2: SPF Record for Multiple Email Services
v=spf1 ip4:198.51.100.0/24 include:spf.protection.outlook.com include:mail.zendesk.com ~all
Here’s what each part means:
- v=spf1 identifies the TXT record as an SPF record.
- ip4:198.51.100.0/24 authorizes every IPv4 address within the specified subnet.
- include:spf.protection.outlook.com allows Microsoft 365 mail servers to send emails for the domain.
- include:mail.zendesk.com authorizes Zendesk’s email infrastructure as an additional sender.
- ~all applies a SoftFail policy, meaning emails from unapproved servers may still be accepted but are more likely to be treated as suspicious.
Why this SPF record is valid:
- The SPF syntax begins with the mandatory version identifier.
- Each mechanism is written in the correct format.
- Third-party email providers are authorized using the include mechanism instead of manually listing their IP addresses.
- The all mechanism appears last, making the syntax compliant with SPF evaluation rules.
This syntax for an SPF record is commonly used by organizations that send emails through Microsoft 365, customer support platforms, marketing tools, or other cloud-based email services.
SPF Record Syntax Best Practices
Writing a valid SPF record is only the first step. To keep email authentication working as expected, your SPF record should also be easy to maintain and comply with SPF limitations. Following these best practices helps reduce authentication failures and improves long-term reliability.
- Always start the record with v=spf1: Every valid SPF record must begin with this version identifier. If it is missing or placed elsewhere in the record, receiving mail servers won’t recognize it as a valid SPF record.
- Stay within the 10 DNS lookup limit: Mechanisms such as include, a, mx, exists, and redirect can trigger DNS lookups. Exceeding the SPF limit of 10 lookups results in a PermError, causing SPF validation to fail.
- Use the include mechanism only when necessary: Every include adds complexity and consumes DNS lookups. Only include trusted third-party email providers that actually send emails on behalf of your domain, and remove unused services over time.
- Keep your SPF record as simple as possible: A shorter SPF record is easier to understand, troubleshoot, and update. Avoid adding unnecessary mechanisms or outdated entries that no longer serve a purpose.
- Review your SPF record regularly: Whenever you migrate to a new email platform, add a marketing tool, or stop using an email service, update your SPF record accordingly. An outdated SPF record can cause legitimate emails to fail authentication.
Common SPF Record Syntax Mistakes
Even a small formatting mistake can make an otherwise correct SPF record invalid. Since receiving mail servers evaluate the record exactly as written, it’s important to avoid these common SPF syntax errors.
- Forgetting the v=spf1 version tag: Every SPF record format specification requires the version tag at the beginning of the record. Without it, the record is ignored.
- Publishing multiple SPF records: A domain should have only one SPF TXT record. If multiple SPF records exist, many receiving servers return a PermError instead of evaluating them.
- Exceeding the DNS lookup limit: Adding too many include, mx, a, or exists mechanisms can push the record beyond the allowed lookup limit, causing SPF validation to fail.
- Making formatting mistakes: Missing spaces between mechanisms, typing unsupported characters, or misspelling mechanism names can make the syntax for an SPF record invalid.
- Using deprecated mechanisms: The ptr mechanism is no longer recommended because it is slow and unreliable. Modern SPF deployments should avoid using it.
- Leaving outdated entries in the record: Email providers that are no longer used should be removed from the SPF record. Unnecessary entries increase complexity and make future maintenance more difficult.
A correctly configured SPF record is only effective if the syntax is valid. Even minor formatting errors can prevent receiving mail servers from evaluating the record properly, leading to authentication failures for legitimate emails.
Tip: After making changes to your SPF record, run it through Mail-Tester’s SPF Checker to quickly identify syntax errors and configuration issues before they affect email authentication.
Final Thoughts on SPF Record Syntax
A well-written SPF record helps receiving mail servers recognize emails that are genuinely sent from your domain and identify unauthorized senders. But creating an SPF record isn’t just about adding IP addresses. You also need to follow the correct SPF syntax, use the right mechanisms, stay within the DNS lookup limit, and avoid formatting mistakes. When your SPF record is set up correctly, it strengthens email authentication, helps protect your domain from spoofing, and improves email deliverability.
Before sending important emails, test your email deliverability with Mail-Tester. It helps you verify that your SPF record is working correctly, checks your authentication results, and identifies issues that could prevent your emails from reaching the inbox.
