SPF Record Syntax Guide: Components, Rules, Examples, and Validation
by
Last Updated: 10 min read
Key Takeaways
- SPF helps verify whether a sending server is authorized to send email for your domain, but it works best alongside DKIM and DMARC.
- SPF records use mechanisms, qualifiers, and modifiers to define authorized senders and control how receiving servers handle non-matching mail.
- The recipient’s server checks the SPF record via DNS lookup to verify the sender’s authorization.
- SPF checks can return Pass, Fail, SoftFail, Neutral, None, TempError, or PermError, depending on the record and receiving server evaluation.
- SPF modifiers like exp and redirect offer additional customization for email validation and handling.
If you’ve ever wondered why some of your legitimate emails end up in spam folders or get blocked altogether, the issue might come down to how your domain’s email authentication is set up. One key factor here is the SPF record syntax, which plays a crucial role in verifying that your emails are sent from authorized servers. While SPF helps prevent your messages from being flagged as suspicious, its syntax can be tricky to understand and even harder to configure correctly.
In this post, we’ll break down how SPF record syntax works and what you should keep in mind when setting it up for your domain.
What Is SPF Record Syntax?
An SPF record syntax is the set of rules that define how an SPF (Sender Policy Framework) record is written in a domain’s DNS. In simple terms, it’s the “language” your domain uses to tell receiving mail servers which sources are authorized to send emails on its behalf.
SPF record syntax typically includes mechanisms (such as ip4, ip6, or include), qualifiers (like +, -, ~, or ?), and modifiers that work together to determine whether an incoming email passes or fails the SPF check.
Understanding this syntax is crucial because even a minor error, such as an extra space, an incorrect qualifier, or a missing mechanism, can cause your emails to fail authentication and land in spam or be rejected.
DMARC alignment note: SPF validates the envelope sender domain, not always the visible From address users see in their inbox. For DMARC to pass via SPF, the domain in the Return-Path must align with the visible From domain. This is why SPF should be paired with DKIM and DMARC.
SPF Record Syntax Structure and Components
An SPF record is made up of four main parts: the version tag, mechanisms, qualifiers, and modifiers. Each part plays a unique role, and together they determine how receiving mail servers handle emails claiming to come from your domain.
| SPF Component | Purpose | Example |
|---|---|---|
| Version tag | Identifies the record as SPF | v=spf1 |
| Mechanism | Defines authorized senders | ip4:203.0.113.5 |
| Qualifier | Defines the result when a mechanism matches | -all, ~all |
| Modifier | Adds optional processing instructions | redirect=, exp= |
Version Tag
The version tag is the starting point of an SPF record. It identifies the record as using SPF syntax and ensures that mail servers interpret the following text correctly. Without it, the record will not work. Only one version tag is allowed, and it must appear at the very beginning of the record. Current valid format: v=spf1.
SPF Qualifiers: +, -, ~, and ?
Qualifiers are symbols placed in front of mechanisms. They instruct the receiving mail server on what to do if the mechanism matches. If a qualifier is not specified, the default action is Pass.
| Qualifier | Result | Meaning | Typical Use Case | Risk Level |
|---|---|---|---|---|
| + | Pass | Sender authorized; mail accepted | Default — rarely written explicitly | Low |
| - | Fail | Sender not authorized; mail rejected | Strict enforcement after full rollout | Low if complete |
| ~ | SoftFail | Probably not authorized; flagged | Testing or transitional deployment | Medium |
| ? | Neutral | No policy decision; server decides | Rarely used in production | High — no protection |
SPF Mechanisms: all, ip4, ip6, a, mx, exists, and include
Mechanisms are the main rules in an SPF record. They define which servers, IP addresses, or domains are authorized to send mail on behalf of the domain. Each mechanism is checked in order from left to right, and if a match is found, the associated qualifier is applied.
| Mechanism | Syntax Example | What It Authorizes | DNS Lookups | Recommended Use |
|---|---|---|---|---|
| all | -all | Matches all senders — catch-all at end | 0 | Always end with -all or ~all |
| ip4 | ip4:203.0.113.5 | A specific IPv4 address or CIDR range | 0 | Dedicated outbound servers |
| ip6 | ip6:2001:db8::1 | A specific IPv6 address or prefix | 0 | Outbound mail over IPv6 |
| a | a or a:example.com | IPs matching the domain’s A/AAAA records | 1 | When web server also sends mail |
| mx | mx | IPs of the domain’s MX servers | 1 per MX | When MX servers send outbound |
| ptr | ptr:example.com | Reverse DNS check (deprecated per RFC 7208) | Multiple | Avoid — deprecated |
| exists | exists:example.com | Passes if the domain resolves in DNS | 1 | Advanced use with macros |
| include | include:_spf.google.com | Senders authorized by the referenced domain | 1 + nested | Third-party senders |
The all Mechanism: -all vs ~all vs ?all
-all (Hard Fail): Any unlisted sender is explicitly rejected. Use this once your SPF record is fully tested and all legitimate senders are included. This is the recommended setting for strict enforcement.
~all (SoftFail): Unlisted senders are accepted but flagged. Use this during testing or transitional rollout when you are not yet confident all legitimate senders are listed.
?all (Neutral): No policy is applied to unlisted senders. This offers no real protection and is not recommended for production use.
+all (Pass all): Allows any server to send on your behalf. This is dangerous and should never be used.
SPF Modifiers: redirect and exp
redirect= (Modifier): Delegates the entire SPF policy evaluation to another domain. Unlike include, redirect replaces the current record entirely and cannot be combined with an all mechanism. The SPF include mechanism works differently. It adds authorized senders from a referenced domain’s SPF record without replacing your own.
exp= (Modifier): Provides a custom explanation string for SPF failures. When a message fails SPF, the receiving server can look up this TXT record to retrieve a human-readable reason.
include vs redirect: Key Difference
| include | redirect | |
|---|---|---|
| Type | Mechanism | Modifier |
| Effect | Adds senders from referenced domain | Replaces entire SPF evaluation |
| Can use with all? | Yes | No — all overrides redirect |
| DNS lookup count | Counts toward 10-lookup limit | Counts toward 10-lookup limit |
SPF Evaluation Results and What They Mean
When a receiving mail server evaluates an SPF record, it returns one of seven possible results. Understanding each result helps domain owners diagnose delivery failures and improve their SPF configuration. For strategies on fixing common SPF failures, see our guide on how to optimize your SPF record.
SPF Record Syntax Examples
Simple SPF Record
v=spf1 ip4:203.0.113.5 -all
v=spf1 → version tag. ip4:203.0.113.5 → authorizes one IPv4 address. -all → all other servers fail. This is a common setup for a small domain sending email from a single server.
Advanced SPF Record
v=spf1 ip4:203.0.113.0/24 include:_spf.google.com include:_spf.mailhost.com ~all exp=explain._spf.example.com
This record authorizes an entire /24 IP range, two third-party senders, accepts unlisted senders with a SoftFail flag, and provides a custom failure explanation. Each include, a, mx, exists, and redirect mechanism triggers DNS lookups. If the total exceeds 10, SPF returns a PermError.
Enterprise SPF Record Example
v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net ~all
This record is common for organizations using Google Workspace, Microsoft 365, and a third-party delivery platform. Each include adds DNS lookups, so teams should validate carefully to avoid PermError results.
MSP SPF Management Example
For MSPs managing many client domains, the goal is not only to write one valid SPF record, but to monitor changes across all clients. Centralized SPF validation helps detect duplicate records, lookup-limit risks, and broken includes before clients experience delivery issues. PowerDMARC’s MSP/MSSP Partner Program allows service providers to manage authentication across all client domains from a single dashboard without switching tools or manually parsing DNS records.
SPF TXT Record Syntax Examples by Use Case
| Use Case | SPF TXT Record | Explanation | Caution |
|---|---|---|---|
| MX servers only | v=spf1 mx -all | Only MX servers may send | Fails if sent via non-MX |
| Single IPv4 | v=spf1 ip4:203.0.113.5 -all | One specific IP authorized | Update when IP changes |
| Multiple senders | v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all | Google + Microsoft 365 | Monitor lookup total |
| Redirect | v=spf1 redirect=_spf.example.com | Policy delegated | Do not combine with all |
| No sending | v=spf1 -all | Parked domain, no email | Use only for non-sending |
How to Use Multiple include Mechanisms in SPF Record Syntax
v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net include:_spf.salesforce.com ~all
Each include mechanism triggers at least one DNS lookup, and nested includes add more. The total across the entire chain must not exceed 10. SPF processing stops at the first match, so order matters, place the most commonly used senders first. If the lookup count is approaching 10, use PowerDMARC’s SPF flattening tool to optimize your record automatically. For complex enterprise setups, SPF macros offer a more scalable alternative to traditional flattening by dynamically expanding at evaluation time.
Too Many DNS Lookups in SPF Records
RFC 7208 limits the total number of DNS lookups during SPF evaluation to 10. This limit applies to the full lookup chain — including nested lookups triggered by include, a, mx, exists, and redirect mechanisms. If the limit is exceeded, the receiving server returns a PermError, causing SPF to fail entirely. There is also a lesser-known constraint: the 2-void-lookup limit. If more than two DNS queries return NXDOMAIN, SPF also fails. For a detailed walkthrough of how to resolve this, see how to fix too many DNS lookups.
Mechanisms that count: include (1 + nested), a (1), mx (1 per MX + A lookups), exists (1), redirect (1 + nested), ptr (multiple — deprecated).
Mechanisms that do NOT count: ip4 and ip6 do not trigger DNS lookups.
How to reduce DNS lookups: Remove include mechanisms for senders you no longer use. Replace a and mx mechanisms with explicit ip4 values where possible. Avoid ptr. Use PowerSPF (Hosted SPF) to consolidate includes and stay within the limit without manual DNS maintenance. For more on the flattening process itself, see SPF Flattening: From DNS Overload To Streamlined SPF.
How to Publish an SPF TXT Record in DNS
SPF is published as a TXT record in your domain’s DNS at the root domain level (e.g., example.com) or at the relevant subdomain. Use our free SPF record generator to create a valid record instantly before publishing.
| DNS Field | Value to Enter | Notes |
|---|---|---|
| Host / Name | @ or blank for root domain | Use subdomain name for subdomain SPF records |
| Type | TXT | Legacy SPF-type (Type 99) deprecated; always use TXT |
| Value | Your full SPF record, e.g. v=spf1 include:_spf.google.com -all | Must begin with v=spf1 |
| TTL | 3600 (1 hour) | Lower TTL speeds up propagation during changes |
Important: A domain must have only one SPF TXT record. Publishing multiple TXT records starting with v=spf1 causes a PermError.
SPF Syntax Validation Workflow
Step 1: Inventory all sending sources — Microsoft 365, Google Workspace, CRMs, marketing tools, helpdesk systems, payroll, and regional senders.
Step 2: Write or update the SPF record — Add only authorized mechanisms and includes.
Step 3: Check lookup count — Ensure the record does not exceed the 10-DNS-lookup limit.
Step 4: Validate syntax — Use an SPF checker tool to detect formatting, duplicate, and deprecated mechanism issues.
Step 5: Monitor authentication results — Review DMARC reports to confirm legitimate senders are passing SPF and DKIM alignment.
SPF Record Syntax Rules, Validation, and Common Errors
Writing an SPF record is all about putting mechanisms and qualifiers in the right order and making sure the record actually works as intended. Even small syntax mistakes, such as a missing tag or an extra space, can cause the record to fail, resulting in emails being rejected, marked as spam, or leaving your domain vulnerable to spoofing.
This section covers three key areas: best practices for writing SPF syntax, common mistakes to avoid, and how to validate your record before publishing it live.
Follow best practices for SPF syntax
Getting SPF right starts with following a few golden rules that make your record both effective and reliable:
- Always begin with the correct version tag: v=spf1.
- Limit DNS lookups to avoid exceeding the 10-lookup limit, which will cause the record to break.
- Use the include mechanism carefully to prevent loops or circular references.
- Keep records as concise as possible — overly complex configurations are harder to maintain and more likely to fail.
- Review SPF records regularly, especially if your email infrastructure changes or if you add/remove providers.
SPF syntax management for MSPs and MSSPs
For MSPs and MSSPs managing SPF across many client domains, best practices go beyond writing a single correct record. Key operational considerations include:
- Standardize SPF templates for common client configurations (Google Workspace + Microsoft 365, for example) to speed up onboarding and reduce syntax errors.
- Automate lookup-count monitoring to receive alerts before a client’s SPF record exceeds the 10-DNS-lookup limit — especially when clients add new SaaS tools.
- Use centralized dashboards to detect duplicate SPF records, broken includes, or missing mechanisms across all client domains simultaneously.
- Document changes whenever a new sender is added to a client’s environment to maintain an accurate audit trail for compliance and troubleshooting.
Avoid common syntax errors
Many SPF issues come from simple but damaging mistakes. Watch out for these pitfalls:
- Missing version tag: every record must start with v=spf1.
- Duplicate qualifiers: using more than one qualifier for the same mechanism is invalid.
- Excessive mechanisms: long, bloated records increase the risk of errors and exceed DNS limits.
- Syntax formatting issues: misplaced spaces, typos, or unsupported characters can cause the record to fail.
- Multiple SPF records: a domain must only have one SPF record — if more than one exists, validation will fail.
- Deprecated mechanisms: avoid ptr, which is no longer recommended and may not be supported by all servers.
Remember: even if the intent of the record is correct, syntax errors will cause SPF to fail completely.
Validate your SPF record syntax
Before publishing your SPF record, validation is critical. Validators check that the syntax is correct and that the record doesn’t exceed DNS lookup limits or contain unsupported mechanisms.
- Use SPF record check tools, such as PowerDMARC’s SPF checker, to quickly identify issues.
- Validation helps ensure the record works consistently across different receiving mail servers.
- Testing new or updated records in a staging environment is recommended before applying them live.
- Regular validation after changes keeps your SPF policy up to date and functional.
By validating, you reduce the risk of emails bouncing, going to spam, or leaving your domain vulnerable to spoofing.
SPF Record Syntax in Action
Correct SPF record syntax is vital for secure email delivery and protection against spoofing. Each part: version tag, mechanisms, qualifiers, and modifiers, works together to guide how mail servers handle your messages.
As SPF adoption continues to grow with global pass rates now at 80.24%, organizations that invest in clean, validated SPF syntax gain a measurable advantage in deliverability, compliance, and security posture.
For a complete step-by-step walkthrough of the initial setup process, see how to set up SPF records. And to ensure you meet the latest compliance mandates, review the Google and Yahoo email authentication requirements for 2026.
Frequently Asked Questions
1. How do I write an SPF record?
Start with v=spf1, add mechanisms to list authorized senders (such as ip4: for specific IPs or include: for third-party services), and end with a qualifier like -all to block everything else. Publish the record as a single DNS TXT record at your domain’s root.
2. What happens if my SPF record syntax is wrong?
Mail servers may reject or flag your emails as spam, and your domain becomes more vulnerable to spoofing. A syntax error such as a missing version tag, duplicate SPF records, or exceeding the 10-DNS-lookup limit can cause SPF to fail entirely.
3. What is an example of an SPF record using MX?
An SPF record using MX looks like: v=spf1 mx -all, which allows only the domain’s mail exchange servers to send email on its behalf.
4. How many DNS lookups are allowed in an SPF record?
SPF allows a maximum of 10 DNS lookups per evaluation, as defined in RFC 7208. Mechanisms that count include: include, a, mx, exists, redirect, and ptr. If exceeded, SPF returns a PermError.
5. Can you have multiple SPF records for one domain?
No. A domain must have a single SPF TXT record. Multiple records starting with v=spf1 cause a PermError. Merge all authorized senders into one record.
6. What is the difference between SPF -all and ~all?
-all (hard fail) tells receivers to reject mail from unlisted senders. ~all (soft fail) tells receivers to accept but flag it. Use ~all during testing and switch to -all once all legitimate senders are confirmed.
7. Does SPF alone prevent email spoofing?
No. SPF only validates the envelope sender (Return-Path), not the visible From address. It must be paired with DKIM and DMARC for complete protection against spoofing and phishing.
8. What is SPF flattening and when do I need it?
SPF flattening replaces include mechanisms with the resolved IP addresses, reducing DNS lookups. It is needed when your SPF record exceeds or approaches the 10-DNS-lookup limit. Automated tools like PowerSPF handle this dynamically.
9. How long does it take for an SPF record to propagate?
DNS propagation typically takes 1 to 4 hours, depending on your DNS provider and TTL settings. In some cases, it can take up to 48 hours. Always validate your record after publishing.
Domain & Email Security Expert at PowerDMARC
Ahona is the Marketing Manager at PowerDMARC, with 5+ years of experience in writing about cybersecurity topics, specializing in domain and email security. Ahona holds a post-graduation degree in Journalism and Communications, solidifying her career in the security sector since 2019.
Latest posts by Ahona Rudra (see all)
- Fax Security: A Complete Guide to Protecting Sensitive Documents in 2026 - July 30, 2026
- What Is An Email Filtering Service? - July 29, 2026
- Email Spoofing: What It Is and How to Stop It - July 29, 2026
