What is v=spf1? What Is It Meant For?

You’re looking at a DNS record that starts with v=spf1, and you know it matters but changing it without fully understanding it can break email delivery across your entire domain.

One missing include:, one lookup too many, or one syntax error can cause emails to fail authentication, land in spam, or be rejected outright

SPF (Sender Policy Framework) is a foundational part of email authentication. It tells receiving servers which sources are allowed to send email on your behalf. The v=spf1 tag is what activates that policy but everything that follows determines whether your emails are trusted or blocked.

The challenge is that SPF looks simple on the surface but becomes complex as you add multiple sending sources, marketing tools, and infrastructure. Lookup limits, nested includes, and alignment issues introduce failure points that aren’t always visible until deliverability drops.

This guide breaks down exactly what v=spf1 means, how SPF records are structured, how evaluation works, and how to build and maintain a record that doesn’t fail under real-world conditions.

How SPF evaluation works

SPF evaluation is a step-by-step validation process that happens every time an email is received. It determines whether the sending server is authorized to send on behalf of the domain used in the Return-Path.

Here’s how it works in practice:

• An email is received claiming to be from your domain: The message arrives at the recipient’s mail server with both visible headers (From) and hidden routing details (Return-Path).
• The receiving server extracts the Return-Path domain: This is the domain SPF actually checks. It represents the sender used during email transmission.
• The server queries DNS for the SPF record (v=spf1): It looks up the TXT record published on that domain. If no SPF record exists, the result is None (no authentication).
• The sending server’s IP is evaluated against the SPF record: The server processes the SPF record from left to right:
  • Checks each mechanism (ip4, include, a, etc.)
  • Resolves any DNS lookups required
  • Stops at the first matching rule
• A result is generated based on the match: Possible outcomes include:
  • Pass → Sender is authorized
  • Fail / SoftFail → Sender is not authorized (strict vs lenient handling)
  • Neutral / None → No clear policy or no SPF record
  • PermError / TempError → SPF could not be evaluated due to errors
• The result is combined with DKIM and DMARC: SPF alone does not decide delivery. The receiving server uses it alongside:
  • DKIM (message integrity)
  • DMARC (alignment + policy)
    to decide whether to accept, filter, or reject the message

What Is an SPF Record?

An SPF record is a DNS TXT record that defines all servers and services allowed to send email for your domain. When an email is received, the receiving server checks this record to validate whether the sending source is authorized.

What Does v=spf1 Mean?

The v=spf1 tag is the identifier that tells receiving mail servers this DNS TXT record is an SPF policy. It signals that the record should be parsed and evaluated using SPF rules defined in RFC 7208.

Without this tag, the record is not treated as SPF at all, no validation happens, and the domain effectively has no SPF protection.

When a receiving server looks up your domain:

• It scans TXT records for one that starts with v=spf1
• Only that record is considered for SPF evaluation
• Everything that follows is interpreted as authorization rules (mechanisms, qualifiers, modifiers)

For SPF to work correctly, v=spf1 must follow strict requirements:

• Must appear at the very beginning of the record
• Must be written exactly as v=spf1 (no typos, no extra spaces)
• Must exist in only one SPF record per domain

If the version tag is incorrect in any way, the entire record fails:

• Missing entirely → SPF returns None (no record found)
• Misspelled (v=spf 1, v=spf2, v=SPF1) → Invalid syntax → PermError
• Placed after another value → Record is ignored as malformed

Receiving servers cannot interpret your SPF policy, and authentication fails for all emails.

Anatomy of an SPF Record: Full Syntax Breakdown

Every SPF record follows a consistent structure, with a rule set that gets executed in sequence. Understanding how each part contributes to that evaluation is what prevents configuration mistakes.

An SPF record always starts with a version tag (v=spf1), followed by a series of mechanisms that define authorized senders. These mechanisms can be combined with qualifiers, which control how matches are treated, and sometimes modifiers, which adjust how the record is evaluated. All of this lives in a single line of text, but each element directly affects how receiving servers interpret your domain’s email.

Example record

v=spf1 ip4:192.0.2.0/24 include:_spf.google.com include:spf.protection.outlook.com -all 

ip4:192.0.2.0/24 (where /24 represents a range of 256 IP addresses using Classless Inter-Domain Routing (CIDR) notation)

What each part does

• v=spf1 identifies the record as an SPF policy and enables evaluation
• ip4:192.0.2.0/24 explicitly allows a known IP range, typically your own infrastructure
• include:_spf.google.com authorizes Google Workspace by referencing its SPF record
• include:spf.protection.outlook.com does the same for Microsoft 365
• -all defines the default policy: any sender not matched earlier is not allowed

This combination creates a complete authorization model, only specific sources are allowed, and everything else is denied.

How evaluation actually works

SPF is processed in a strict, predictable way:

• The receiving server reads the record from left to right
• Each mechanism is evaluated in sequence against the sending server’s IP
• As soon as a match is found, evaluation stops immediately
• The qualifier attached to that mechanism determines the result

If no mechanism matches:

• The all mechanism acts as the fallback decision

This means SPF is not a “check everything and decide” system. It’s a first-match-wins system.

SPF Mechanisms Explained

Mechanisms are the core of an SPF record. They define which sending sources are authorized and form the logic the receiving server evaluates against the sender’s IP address. Each mechanism adds a rule, and together they create your domain’s allowlist.

What matters in practice is not just what each mechanism does but how it behaves during evaluation and how it impacts limits and reliability.

Mechanisms are evaluated in order, and the first one that matches the sending IP determines the result. This means every mechanism you add affects both authorization coverage and evaluation complexity.

Some mechanisms directly match IPs, while others require DNS lookups to resolve additional data. 

How different mechanisms behave

The include: mechanism is the most commonly used and the most likely to cause lookup limit issues due to nested DNS queries.

SPF allows a maximum of 10 DNS lookups per evaluation. Mechanisms that count toward this limit:

• include:
• a
• mx
• exists:
• redirect=
• ptr

Mechanisms that do not:

• ip4:
• ip6:

This creates a practical trade-off:

• Convenience (include:) → higher lookup cost
• Control (ip4/ip6) → lower lookup cost but more maintenance

SPF Qualifiers Explained

Qualifiers define what action to take when a mechanism matches. While mechanisms answer “who is allowed,” qualifiers answer “what should happen next.” Together, they determine how strictly your SPF policy is enforced.

Every mechanism can be prefixed with a qualifier. If no qualifier is specified, the default is pass (+). The qualifier directly influences how the receiving server interprets the match and how strongly it trusts or rejects the message.

How qualifiers behave during evaluation

When a mechanism matches:

• The qualifier attached to it determines the result immediately
• SPF evaluation stops at that point
• That result is then used (along with DKIM and DMARC) to decide message handling

This means qualifiers are final decision signals in the SPF process.

What each qualifier actually does (in context)

In most SPF records, qualifiers are applied to the all mechanism at the end to define the default policy.

How qualifiers are typically used in SPF records

Most SPF records rely on qualifiers in one place: the all mechanism at the end.

• ~all → Default to soft enforcement (monitoring phase)
• -all → Default to strict enforcement (production-ready policy)

This final qualifier defines how to treat any sender not explicitly matched earlier.

Practical guidance

• Start with ~all during setup: This allows you to observe SPF results without blocking legitimate senders you may have missed.
• Move to -all once your record is complete: After confirming all valid sources are included, switch to hardfail for full enforcement.
• Avoid ?all :It does not provide meaningful protection or guidance to receiving servers.
• Never use +all:  This allows any sender to pass SPF, effectively disabling authentication for your domain.

SPF Modifiers Explained (Clarified)

Modifiers are a small but important part of SPF syntax. Unlike mechanisms, they do not define who is allowed to send. Instead, they change how SPF evaluation is handled once the record is being processed.

They are optional and used in specific scenarios where standard mechanism-based rules are not sufficient.

How modifiers behave during evaluation

Modifiers are evaluated after mechanisms are processed, and they influence how the overall result is determined or presented.

• They do not match sending IPs
• They do not authorize or deny senders directly
• They adjust the flow or outcome of SPF evaluation

Because of this, modifiers are typically used only in advanced or structured setups, not in basic SPF records.

redirect= – full delegation of SPF evaluation

The redirect= modifier transfers SPF evaluation to another domain.

• It tells the receiving server: “Ignore the rest of this record and evaluate SPF using the policy defined on another domain.”
• Unlike include::
  • include: adds another policy into your evaluation
  • redirect= replaces your evaluation entirely

Example:

v=spf1 redirect=_spf.example.com

In this case:

• Your domain does not define its own SPF rules
• All evaluation is handled by _spf.example.com

When to use it:

• Managing multiple domains with a centralized SPF policy
• Ensuring consistency across domains without duplicating records

exp= – custom explanation for failures

The exp= modifier provides a human-readable explanation when SPF fails.

• It points to a DNS record containing a text message
• That message can be returned to the sending server during failure

Example:

v=spf1 -all exp=explain._spf.example.com

This allows you to define a custom explanation like:

• Why the message failed
• What the sender should do next

How to Build an SPF Record

Creating an SPF record is a controlled, step-by-step process. The goal is to accurately list every legitimate sending source, while keeping the record valid, efficient, and enforceable.

Each step matters because SPF is evaluated exactly as written. Missing a sender or adding incorrect logic can directly impact delivery.

• Start with v=spf1: This activates SPF for your domain. Without it, the record is ignored and no authentication happens.
• Add your own sending infrastructure (ip4: / ip6:): Include any servers you control directly, such as transactional mail servers or internal systems. These are the most reliable entries because they don’t depend on external DNS lookups.
• Add your primary email provider (include:): If you use a platform like Google Workspace or Microsoft 365, you must include their SPF record. This ensures their entire sending infrastructure is authorized on your behalf.

Each include: adds at least one DNS lookup and may introduce additional nested lookups depending on the provider’s SPF structure.

• Add all third-party senders: This includes marketing tools, CRMs, support platforms, and any service that sends email using your domain.Each one must be explicitly authorized because SPF does not automatically trust external services.
• End with your policy (~all or -all): This defines how to treat any sender not listed above:
  • ~all → accept but treat as suspicious (used during setup)
  • -all → reject unauthorized senders (used once fully validated)
• Publish as a single DNS TXT record: SPF allows only one record per domain. All mechanisms must be combined into that single entry.
• Validate before and after publishing: Check for syntax errors, lookup limits, and missing sources. Also verify the live DNS record, not just what was entered.

Manually managing SPF becomes difficult as you add more sending sources. Each include increased lookup complexity, and providers can change IPs without notice.

Tools like PowerDMARC’s PowerSPF (Hosted SPF) automate this process by:

• Keeping your record within the 10-lookup limit
• Automatically updating IP changes from providers
• Reducing manual errors and maintenance

This helps ensure your SPF record stays valid and deliverability isn’t impacted over time.

Example record

v=spf1 ip4:203.0.113.5 include:_spf.google.com include:servers.mcsv.net -all

What this record actually does

• Authorizes a dedicated server (ip4:203.0.113.5)
• Authorizes Google Workspace (include:_spf.google.com)
• Authorizes Mailchimp (include:servers.mcsv.net)
• Rejects any sender not explicitly listed (-all)

This creates a closed and enforceable policy, only known sources can send, everything else is blocked.

The 10-Lookup Limit

The following mechanisms trigger DNS lookups:

• include:
• a
• mx
• exists:
• redirect=
• ptr (deprecated, but still counts if used)

These mechanisms require the receiving server to query DNS to resolve additional data before continuing evaluation.

What does NOT count

These are evaluated directly and do not trigger DNS queries:

• ip4:
• ip6:
• all
• v=spf1

The challenge is that SPF issues are not always visible at the surface level. Nested includes, inactive senders, and hidden IP ranges can push your record over the limit without obvious signs.

How Lookup Count Expands

Even a small SPF record can exceed limits due to nested includes. Here’s how lookup counts expand in practice:

Although only four include: mechanisms are visible, the total lookup count can exceed the 10-lookup limit once nested records are evaluated.

Void Lookup Limit (Often Overlooked)

SPF enforces not only a 10-DNS-lookup limit but also a limit of two void lookups.

A void lookup occurs when a DNS query returns no result, for example, a Non-Existent Domain (NXDOMAIN) response or an empty DNS answer.

A void lookup occurs when a DNS query returns no result, such as a Non-Existent Domain (NXDOMAIN) response or an empty DNS answer.

Common causes:

• Incorrect or outdated include: domains
• Typographical errors in SPF mechanisms
• Referencing domains that no longer exist

If more than two void lookups occur during SPF evaluation:

• SPF returns a PermError
• The entire SPF check fails
• Legitimate emails may lose authentication

Unlike lookup count issues, void lookups are often harder to detect because they result from invalid or stale DNS references rather than visible complexity.

Not sure how many DNS lookups your SPF record uses? 

Solutions like PowerDMARC’s SPF Analytics and Reporting provide:

• Visibility into all sending sources and IPs (even nested ones)
• Detection of lookup limit issues and misconfigurations
• Clear diagnostics with actionable fixes

This makes it easier to understand what your SPF record is actually doing and where it needs optimization.

Conclusion

SPF is a control layer that defines who can send email using your domain. The v=spf1 tag starts that process, but the reliability of your setup depends on how well the record is built, maintained, and kept within limits.

Most SPF issues don’t come from lack of setup, but from drift, new tools added without updates, unused includes left behind, or lookup limits exceeded over time. These failures are often silent until they affect delivery.

To keep SPF working as intended:

• Keep your record accurate and minimal
• Review sending sources regularly
• Stay within lookup limits
• Validate changes before and after publishing

SPF works best when treated as an active configuration rather than a one-time setup. When maintained properly, it gives receiving servers a clear and consistent signal they can trust and that directly supports deliverability and authentication across your entire email program.

Don’t wait for SPF errors to break your email delivery.

Get full visibility into your SPF record, fix lookup issues, and keep your configuration accurate as your sending infrastructure evolves. 

See how you can monitor and manage SPF easily with PowerDMARC.

FAQs

1. What happens if my SPF record is missing or not configured?

If no SPF record exists, receiving servers return a None result. This means your domain has no SPF-based authentication, and receivers rely on other signals like DKIM or spam filters. In practice, this increases the risk of spoofing and can negatively affect deliverability.

2. Can I have more than one SPF record on my domain?

No. A domain must have exactly one SPF record. If multiple TXT records start with v=spf1, SPF evaluation returns a PermError, and authentication fails for all emails. Always merge all sending sources into a single record.

3. How do I know if my SPF record is correct?

You need to validate three things:

• Syntax is correct (no typos or formatting issues)
• All legitimate sending sources are included
• DNS lookup count stays within the 10-lookup limit

Use an SPF checker tool and review real-world results through DMARC reports to confirm everything is working as expected.

4. What is the difference between SPF Pass, Fail, and PermError?

• Pass → The sending server is authorized
• Fail / SoftFail → The sender is not authorized (strict vs lenient handling)
• PermError → SPF is broken due to misconfiguration (e.g., too many lookups, invalid syntax)

PermError is the most critical because it means SPF cannot be evaluated at all.

5. Do I need SPF if I already have DKIM and DMARC?

Yes. SPF is one of the core authentication signals used by DMARC. While DKIM can pass independently, having both SPF and DKIM improves reliability and coverage. Many receivers expect all three to be properly configured.

6. Does SPF protect against email spoofing?

Not on its own. SPF only checks the Return-Path domain, not the visible From address. An attacker can still spoof the From header and pass SPF using their own domain. DMARC is required to enforce alignment and prevent this.

• About
• Latest Posts

Ahona Rudra

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)

• DMARC MSP Case Study: The Great Geek Expands SMB Email Security Services with PowerDMARC - June 25, 2026
• How Email Spoofing-as-a-Service Works and How To Stop It - June 24, 2026
• Phishing Reconnaissance: How Attackers Identify and Target Vulnerable Domains - June 24, 2026