SPF Record Syntax
by
Last Updated: 5 min read
Key Takeaways
- SPF records use mechanisms, qualifiers, and modifiers to define which sources can send email for your domain.
- Mechanisms such as include, a, mx, ptr, and exists can trigger DNS lookups, while ip4, ip6, and all do not count toward the limit.
- SPF qualifiers determine how receiving servers handle matched senders, with -all indicating Fail and ~all indicating SoftFail.
- An SPF record can trigger a PermError if it exceeds the 10-DNS-lookup limit, potentially causing legitimate emails to fail SPF authentication.
- A domain should have only one SPF record, and syntax errors such as a missing v=spf1, incorrect formatting, or the use of deprecated ptr can cause authentication problems.
An SPF record is a single string of text published as a DNS TXT record. It acts as a set of rules defining exactly which IP addresses are permitted to send emails on behalf of your domain. A properly formatted record always begins with a version tag, followed by one or more mechanisms, and concludes with an enforcement rule.
Here is a standard SPF record broken down into its parts:
v=spf1 ip4:192.0.2.0/24 include:_spf.google.com ~all
- v=spf1: The version tag that initiates the record.
- ip4:192.0.2.0/24: A mechanism authorizing a specific IPv4 range.
- include:_spf.google.com: A mechanism with a domain, pointing to a third-party sender’s approved IP list.
- ~all: The qualifier (~) and mechanism (all) dictating the fallback policy for unauthorized senders.
If you need to create a new entry for your domain, use an SPF record generator to build the exact string automatically.
SPF Mechanisms
Mechanisms are the building blocks of your SPF record. They tell the receiving mail server how to identify authorized sending sources.
| Mechanism | What it matches | Example | Counts toward 10-lookup limit |
|---|---|---|---|
| all | Always matches. Used at the very end of a record as a catch-all rule for any IP address not matched by preceding mechanisms. | ~all | No |
| include | Matches if the sender's IP is authorized by the SPF policy of the specified domain. | include:_spf.google.com | Yes |
| a | Matches if the sender's IP matches the IP address resolving from the domain's A or AAAA DNS record. | a:example.com | Yes |
| mx | Matches if the sender's IP matches any of the IP addresses listed in the domain's MX records. | mx:example.com | Yes |
| ip4 | Matches if the sender's IP falls exactly within the defined IPv4 network or subnet range. | ip4:192.0.2.0/24 | No |
| ip6 | Matches if the sender's IP falls exactly within the defined IPv6 network or subnet range. | ip6:2001:db8::/32 | No |
| ptr | Matches if the reverse DNS for the IP resolves to the specified domain. (Deprecated and highly discouraged due to performance strain). | ptr:example.com | Yes |
| exists | Matches if a DNS A record resolves successfully for the specified domain name. | exists:example.com | Yes |
The include Mechanism
The include mechanism is one of the most heavily utilized components in modern email authentication. It instructs receiving servers to look up and evaluate the SPF rules of a third-party service, such as Google Workspace, Microsoft 365, or a marketing platform. If that third-party vendor updates their own server IP addresses, your record remains valid without requiring manual updates.
The all Mechanism
Always placed at the very end of the string, the all mechanism acts as the ultimate default rule. It catches any sender IP address that failed to match the earlier mechanisms in the record. To be effective, it must be paired with a qualifier (like – or ~) that tells the receiving server whether to reject or accept the unauthorized mail.
The a Mechanism
The a mechanism authorizes the IP address associated with a domain’s A or AAAA record. It is especially useful when the web server hosting your primary website is also utilized to dispatch outgoing emails, such as website contact form notifications or system alerts.
The mx Mechanism
If the servers designated to receive your inbound mail (as listed in your MX records) also handle sending your outbound messages, the mx mechanism is the correct choice. It authorizes those specific incoming mail server IPs to dispatch outgoing mail on the domain’s behalf.
SPF Qualifiers
Qualifiers act as prefixes attached to mechanisms (most commonly the all mechanism). They dictate exactly how the receiving server should treat an email when the sender’s IP address matches the mechanism.
| Qualifier | Result | Meaning | Exmaple |
|---|---|---|---|
| + | Pass | The IP address is fully authorized to send emails. The + symbol is optional and assumed by default. | +all |
| - | Fail | The IP address is strictly unauthorized. The email should be rejected entirely. | -all |
| ~ | Softfail | The IP address is unauthorized, but the email is accepted and typically marked as spam or quarantined. | ~all |
| ? | Neutral | No explicit policy is stated. The email is treated as if there is no SPF rule applied at all. | ?all |
SPF Modifiers
Modifiers provide additional instructions or contextual details to the SPF record. They are optional and should only appear once, typically placed at the very end of the string.
| Modifier | What it does | Example | Notes |
|---|---|---|---|
| redirect | Instructs the receiving server to ignore the current rules and use the SPF record of another domain instead. | v=spf1 redirect=example.com | The redirect is completely ignored if an all mechanism is also present in the record. |
| exp | Specifies a custom domain hosting a TXT record that provides an explanation when an SPF check fails. | exp=explain.example.com | Rarely utilized in modern email authentication setups and often ignored by major receiving servers. |
SPF Evaluation Results
When a receiving mail server processes an incoming message against your SPF record, it will return one of seven standardized evaluation results based on your syntax.
| Result | What it means | What the receiver typically does |
|---|---|---|
| Pass | The sender's IP address successfully matched an authorized mechanism in your record. | Accepts the email, pending further DMARC, DKIM, and general spam checks. |
| Fail | The sender's IP address matched a mechanism carrying a - qualifier. | Drops or rejects the email at the server level before it reaches the inbox. |
| SoftFail | The sender's IP address matched a mechanism carrying a ~ qualifier. | Accepts the email but flags it suspiciously, often sending it to the spam folder. |
| Neutral | The sender's IP address matched a ? qualifier, or the record did not yield a firm conclusion. | Processes the email strictly based on the server's own spam filter criteria. |
| None | No valid SPF record was found for the domain in question. | Treats the email as unauthenticated, severely harming deliverability. |
| PermError | The record contains a permanent syntax error or exceeds the 10-lookup limit. | Immediately fails the SPF check, treating the email as unauthenticated and likely rejecting it. |
| TempError | A temporary DNS timeout or network outage prevented the check from completing. | Defers the email delivery momentarily and attempts the check again later. |
The 10 DNS Lookup Limit
To prevent malicious actors from using SPF to launch denial-of-service attacks on DNS servers, the SPF specification enforces a strict limit. A receiving server will perform a maximum of 10 DNS lookups to evaluate a single SPF record.
Mechanisms that require a backend DNS query include include, a, mx, ptr, exists, and the redirect modifier. Crucially, mechanisms like ip4, ip6, and all operate instantly without requiring DNS lookups, meaning they do not count against your limit.
If your configuration exceeds 10 lookups, receiving servers will immediately return an SPF PermError. This completely invalidates your policy and causes legitimate emails to fail authentication. Organizations relying on multiple third-party email vendors (such as a CRM, support desk, and marketing automation platform) can hit this threshold very easily.
To resolve this limitation, you can implement PowerDMARC’s Hosted SPF solution. This compresses your third-party domain mechanisms into flat IP addresses, instantly reducing your lookup count. You should also run your domain through an SPF record checker to measure your current lookup total and spot vulnerabilities before they impact deliverability.
Common SPF Syntax Mistakes
Creating a compliant SPF record requires precise adherence to formatting rules. A single stray character can break your authentication. These are the most frequent syntax mistakes:
- More than one SPF record on a domain: A domain must publish exactly one TXT record beginning with v=spf1. Publishing multiple records causes an immediate PermError.
- Missing v=spf1: If the string does not start with this exact version tag, receiving servers will simply ignore the TXT record.
- Using +all: This combination announces that literally every IP address on the internet is authorized to send emails on your behalf, effectively rendering the record useless.
- Trailing ptr: The ptr mechanism places an immense load on receiving servers. It is officially deprecated and will cause performance issues if included.
- Exceeding 10 lookups: Nesting too many include statements breaks the DNS lookup limit and automatically invalidates the record.
- Spaces or missing colons in mechanisms: Formatting mistakes, like typing include _spf.google.com instead of the correct include:_spf.google.com, will break the syntax reading.
[KEEP SAME: Existing CTA blocks]
Frequently Asked Questions
What is the correct SPF record syntax?
An SPF record must be published as a DNS TXT record starting with the v=spf1 version tag, followed by your authorized IP addresses or mechanisms separated by spaces, and concluding with a strict fallback mechanism such as ~all or -all.
What does ~all mean in an SPF record?
The ~all mechanism indicates a SoftFail fallback policy. It tells receiving servers that any sender IP address not explicitly listed in your record is unauthorized, but the email should still be accepted and routed to the recipient’s spam folder.
What’s the difference between include and redirect?
The include mechanism evaluates another domain’s SPF rules alongside your own, allowing you to combine multiple sending sources. The redirect modifier instructs the receiving server to ignore your record entirely and use the specified domain’s SPF record instead.
How do I check my SPF record syntax?
You can verify your formatting and calculate your active lookup count by entering your domain into a free SPF record checker. It will instantly flag syntactical errors, deprecated mechanisms, and limit violations.
Can I have two SPF records?
No, publishing multiple SPF records for a single domain violates the core protocol. If a receiving server discovers more than one record starting with v=spf1, it will immediately return a PermError and fail authentication.
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.
Latest posts by Yunes Tarada (see all)
- SPF Record Syntax - September 14, 2026
- Oracle Email Delivery DKIM, DMARC, and SPF Setup Guide - September 14, 2026
- DKIM=none: What It Means and How to Fix ‘Message Not Signed’ - September 13, 2026
