DNS SPF Record: How It Works, and How to Set It Up

Every email your organization sends carries your domain’s reputation with it. If your SPF record is misconfigured, or missing entirely, receiving servers have no reliable way to verify that the email actually came from you. Legitimate emails land in spam. Marketing campaigns bounce. Attackers send messages that look like they came from your domain.

SPF (Sender Policy Framework) is one of three core email authentication protocols, alongside DKIM and DMARC, that tells receiving mail servers which IP addresses are authorized to send email on behalf of your domain. It’s published as a DNS TXT record. On the surface, it looks simple. In practice, SPF is where most email authentication problems start. 

This guide covers exactly what an SPF record is, how SPF verification works step by step, how to create one, and how to fix the most common SPF errors, including the 10-DNS-lookup limit that silently breaks email delivery for growing organizations.

What Is a DNS SPF Record?

A DNS SPF (Sender Policy Framework) record is a type of DNS TXT record that specifies which mail servers are authorized to send emails for your domain. It helps receiving mail servers verify that incoming messages come from legitimate sources, reducing the risk of spoofing and phishing. When an email is received, the server checks the SPF record of the sender’s domain to confirm the sending IP is allowed. 

If the IP is not listed, the message may be flagged, rejected, or sent to spam. Properly configuring an SPF record improves email deliverability and strengthens domain authentication.

You can check your domain’s SPF record instantly with a free SPF lookup tool. It takes five seconds and shows you exactly what’s published in your DNS.

How Does SPF Authentication Work?

SPF authentication follows a structured DNS lookup and validation process every time an email is received:

• Your domain publishes an SPF record as a DNS TXT entry. This record defines all authorized sending sources using mechanisms such as ip4, ip6, include, and a, along with a default policy (-all, ~all, or ?all).
• When an email is sent, the sending server includes a Return-Path (envelope sender) address that represents the domain responsible for delivery.
• The receiving mail server extracts the domain from the Return-Path address.
• It performs a DNS query to retrieve the SPF record associated with that domain.
• The sending server’s IP address is then evaluated against each mechanism in the SPF record, processed in order until a match or policy decision is reached.
• SPF enforces a limit of 10 DNS lookups during this evaluation to prevent excessive recursion, exceeding this results in a PermError.
• Based on the outcome, SPF returns a result such as Pass, Fail, SoftFail, Neutral, None, PermError, or TempError.
• The receiving server uses this result, alongside DKIM authentication and DMARC policy alignment, to determine how the message should be handled (deliver, quarantine, or reject).

A critical detail: SPF validates the Return-Path (envelope sender) domain, not the visible From header. If these domains differ, as is common with third-party sending platforms, SPF may pass, but DMARC alignment can fail, which directly affects inbox placement.

Each SPF result code has a specific practical meaning:

DMARC aggregate reports show you exactly which emails are passing and failing SPF across all your sending sources. Without DMARC reporting, SPF failures happen silently and you never know until someone complains.

SPF Record Syntax and Format Explained

Understanding SPF syntax starts with reading a complete record and knowing how each part is evaluated. Here’s a typical example:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com ip4:203.0.113.0/24 -all (where /24 represents a range of 256 IP addresses using Classless Inter-Domain Routing (CIDR) notation)

This single line tells receiving servers exactly which sources are allowed to send email for your domain and what to do if a sender is not listed.

SPF Version Tag (v=spf1)

Every SPF record must begin with v=spf1. This identifies the TXT record as an SPF policy. There are no other valid versions. If this tag is missing or incorrect, the record is ignored entirely.

SPF Mechanisms (Authorized Senders) 

Mechanisms define who is allowed to send email. They are evaluated from left to right, and the first match determines the result.

The include: mechanism is the most commonly used and the one that causes the most problems. Every include: triggers a recursive DNS lookup. If Google’s SPF record includes three other domains, those all count toward your 10-lookup limit.

A common point of confusion: the a mechanism in SPF references the domain’s DNS A record. It does not create a separate “A record for SPF.” When you add a to your SPF record, you’re authorizing whatever IP addresses your domain’s A record resolves to.

Modifiers (redirect=)

Modifiers control how SPF evaluation behaves rather than defining senders.

• redirect=
  Transfers the entire SPF evaluation to another domain. Unlike include:, which adds another policy into your record, redirect= replaces your evaluation completely.
  Use this only when one domain should fully inherit another domain’s SPF configuration.

DNS Lookup Limit (Critical Constraint)

SPF allows a maximum of 10 DNS lookups per evaluation. Mechanisms like include:, a, mx, exists:, and redirect= all count toward this limit.

If the limit is exceeded, SPF returns a PermError, and authentication fails, even if the sender is legitimate. This is why large, complex records often require optimization (such as reducing unused includes or flattening).

SPF Qualifiers (The “all” Mechanism)

The qualifier on the all mechanism at the end of your SPF record defines your SPF policy – what happens to email from servers not explicitly listed:

SPF works as a logical rule set. The receiving server reads your record from left to right, checks each mechanism, and stops at the first match. If no match is found, the all rule applies.

A well-structured SPF record is:

• Complete (all legitimate senders included)
• Efficient (within lookup limits)
• Strict (using -all once validated)

This ensures accurate authentication and prevents unauthorized use of your domain for email sending.

How to Create and Publish an SPF Record

Setting up an SPF record involves identifying all legitimate sending sources, defining them clearly in DNS, and validating that configuration works as expected. Follow each of the below 5 steps in order.

Step 1: Identify all your sending sources

List every service that sends email on behalf of your domain. This typically includes your primary mailbox provider (such as Google Workspace or Microsoft 365), marketing platforms (like Mailchimp or HubSpot), Customer Relationship Management (CRM) systems (Salesforce), support tools (Zendesk), and transactional email services (SendGrid, Amazon SES). Each of these services sends from different infrastructure, so all must be explicitly authorized. Most providers publish an SPF include value in their documentation, which tells receiving servers to trust their sending IPs.

Step 2: Build your SPF record

An SPF record is a single-line TXT entry that starts with v=spf1. You then define authorized senders using mechanisms:

• include: for third-party services (e.g., include:_spf.google.com)
• ip4: or ip6: for specific IP addresses or ranges you control
  Mechanisms are evaluated left to right. At the end, you define a policy:
• ~all (soft fail) marks unauthorized senders as suspicious
• -all (hardfail) explicitly denies them

Example:

v=spf1 include:_spf.google.com include:servers.mcsv.net ip4:198.51.100.0/24 ~all

This record tells receiving servers exactly which sources are allowed and how to treat everything else.

Step 3: Publish the record in DNS

Log in to your DNS provider (such as Cloudflare, Route 53, or GoDaddy). Create a new TXT record for your root domain:

• Host/Name: @ (or leave blank, depending on provider)
• Value: your complete SPF record
  Once saved, the record becomes publicly accessible via DNS. Changes may take time to propagate.

Step 4: Validate the record

After publishing, verify that:

• The SPF record is correctly formatted (no syntax errors)
• All includes resolve properly
• Total DNS lookups do not exceed the limit of 10 (SPF fails with a PermError if exceeded)

Validation ensures that receiving servers can reliably process your record without errors.

Step 5: Monitor SPF results

SPF is not a one-time setup. As you add or remove sending sources, your SPF record must be updated. To monitor performance:

• Enable DMARC to receive aggregate reports showing SPF pass/fail rates
• Review which sources are passing or failing authentication
• Remove unused services and fix misaligned or unauthorized senders

Important: Only one SPF record is allowed per domain. If multiple TXT records starting with v=spf1 exist, SPF evaluation fails entirely with a PermError. Always merge all sending sources into a single, complete record.

The SPF 10-DNS-Lookup Limit (And Why It Breaks Your Email)

SPF evaluation is not unlimited. Under RFC 7208, a receiving server can perform a maximum of 10 DNS lookups while processing your SPF record. If this limit is exceeded, SPF returns a PermError (permanent error) and the check fails completely.

This is not a partial failure. A PermError means SPF cannot be evaluated at all. As a result, every email sent from your domain loses SPF authentication, regardless of whether the sender is legitimate.

What counts toward the 10-lookup limit?

The following mechanisms trigger DNS lookups:

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

The ip4: and ip6: mechanisms do not count toward the lookup limit because they reference IP addresses directly, with no DNS resolution required

Why this limit is easy to exceed

The main issue comes from nested (recursive) lookups.

When you add an include:, you are not just adding one lookup but also inheriting everything inside that provider’s SPF record.

For example:

• You include Google → Google’s SPF may include multiple other domains
• You include Microsoft 365 → adds several more lookups
• You include marketing and transactional tools → each adds its own chain

These quickly stack up. Even if your record looks short, the actual lookup count can exceed 10 during evaluation.

The 2 “void lookup” limit (often overlooked)

SPF also enforces a limit of 2 void lookups.

A void lookup happens when a DNS query returns no result (Non-Existent Domain (NXDOMAIN) or an empty response).

Common causes:

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

If more than two void lookups occur, SPF again returns a PermError.

A PermError does not mean “fail for some senders.” It means:

• SPF is considered invalid
• Receiving servers cannot trust your SPF policy
• SPF effectively provides no protection or authentication

Since SPF is one of the signals used by DMARC, this can also lead to:

• DMARC failures (if DKIM doesn’t align)
• Increased spam placement
• Message rejection by stricter receivers

As your email stack grows, your SPF record naturally becomes more complex. Without active management:

• Lookup counts increase silently
• Unused services remain in the record
• Errors accumulate over time

SPF is fragile in this way. It works reliably only when the record is kept within limits, accurate, and continuously maintained.

How Fast You Hit the Limit (Real Example)

Here’s what a typical mid-market SaaS stack looks like in terms of DNS lookups:

You haven’t even added Zendesk, SendGrid, your helpdesk, or your payroll provider yet. If your organization uses Google Workspace plus four or five SaaS tools that send email, you’re likely at or over the limit right now.

How to Fix SPF Lookup Limit Issues

If your SPF record exceeds the 10-DNS-lookup limit, you need to reduce complexity without breaking legitimate sending sources. These are the three practical approaches, in order of impact:

Remove unnecessary mechanisms

Start with a full audit of your SPF record.

• Identify every include: and mechanism currently listed
• Verify whether each service is still actively sending email for your domain
• Remove anything that is no longer in use

Common issues:

• Old marketing tools left in the record
• Duplicate includes across subdomains
• Test or temporary services never cleaned up

Each unused include: you remove immediately frees up one or more DNS lookups. This is the simplest and lowest-risk way to get back under the limit.

Replace include: with ip4:/ip6: where possible

If a sender uses a fixed and small set of IP addresses, you can replace its include: with direct IP entries.

• Example: replace include:vendor.com with ip4:x.x.x.x
• This removes DNS lookups entirely for that sender

When this works well:

• Internal infrastructure
• Dedicated IPs from a provider
• Vendors with clearly documented, stable IP ranges

Trade-off to consider:

• You take on maintenance responsibility
• If the provider updates or rotates IPs, your SPF record becomes outdated
• This can cause silent SPF failures until corrected

Use this only where IP stability is predictable.

Use SPF flattening or SPF Macros

When you rely on multiple third-party services, manual cleanup alone is usually not enough. You need a way to reduce lookups without losing coverage.

SPF Flattening

• Resolves all include: mechanisms into their underlying IP addresses
• Replaces them with a flat list of ip4: / ip6: entries
• Eliminates most DNS lookups

Limitation:

• Flattened records are static
• If a provider (like Google or Microsoft) updates its sending IPs, your record does not automatically update
• This creates a gap where legitimate emails may fail SPF without warning

SPF Macros (dynamic alternative)

• Keep SPF evaluation dynamic while controlling lookup depth
• Reduce reliance on large include chains
• Better suited for environments with frequently changing sender infrastructure

Not sure how many lookups your SPF record uses? Check your lookup count with our free SPF Checker

For organizations that need to stay under the 10-lookup limit without manual DNS management, PowerDMARC’s PowerSPF offers both traditional flattening and modern SPF Macros, letting you choose the technique that fits your environment. The record auto-updates when third-party providers change their authorized IP ranges.

Why SPF Alone Is Not Enough

SPF is a foundational authentication method, but it was not designed to fully protect against modern spoofing and abuse. It has three core limitations that make it insufficient on its own.

Limitation 1: SPF checks the envelope sender, not the From header

SPF validates the Return-Path (envelope sender), the domain used during email transmission. However, users see the From header, which can be different.

This creates a gap that attackers can exploit:

• An attacker sends email from their own domain (which passes SPF)
• They set the visible From address to appear as your domain or a trusted individual
• SPF passes because the sending domain is legitimate
• The recipient still sees a spoofed identity

SPF has no built-in way to verify that the sending domain matches the visible sender. DMARC solves this by enforcing alignment between SPF (or DKIM) and the From header domain.

Limitation 2: SPF breaks on email forwarding

SPF relies on the sending server’s IP address. When an email is forwarded:

• The forwarding server becomes the new sending source
• Its IP is checked against the original domain’s SPF record. Because the forwarding server is not listed as an authorized sender, SPF fails.
• Since it’s not listed, SPF fails

This happens even when the email is completely legitimate. It’s not a misconfiguration but a limitation of how SPF works.

Impact:

• Legitimate forwarded emails often fail SPF
• Receiving systems must rely on other signals (like DKIM) to validate the message

Limitation 3: SPF has no reporting mechanism by itself

SPF does not provide any built-in reporting.

Without an additional layer:

• You don’t know which sources are passing or failing SPF
• You can’t detect unauthorized senders using your domain
• You have no visibility into authentication issues affecting deliverability

DMARC adds reporting, giving you aggregate data on SPF and DKIM results across all receivers.

Modern email infrastructure, with forwarding, mailing lists, third-party senders, and sophisticated spoofing, has outgrown what SPF can do alone. DKIM adds a cryptographic signature that survives forwarding, solving SPF’s biggest weakness. DMARC is the policy layer that connects SPF and DKIM to the From header.

For the full comparison of how these protocols work together, see our guide on SPF vs DKIM vs DMARC.

Common SPF Record Mistakes (And How to Fix Them)

Most SPF failures come down to a few repeatable issues. The problem is mostly lack of maintenance and validation. Here’s how to identify and fix them with clear actions.

Mistake 1: Multiple SPF records on the same domain.

SPF requires a single, authoritative policy. If multiple TXT records start with v=spf1, receiving servers cannot determine which one to evaluate. The result is a PermError, meaning SPF fails entirely for every message.

Why it happens:

• Different teams add records independently (marketing, IT, support tools)
• New vendors provide “add this record” instructions without checking existing setup

How to fix it:

• Audit all TXT records for your domain
• Identify every SPF-related entry
• Merge all mechanisms into one complete record

What to watch for:

• Partial records left behind after migrations
• Subdomains incorrectly used instead of the root domain 

Mistake 2: Exceeding the 10-DNS-lookup limit

Once SPF evaluation crosses 10 DNS lookups, it stops immediately and returns a PermError. This invalidates SPF for all senders, even legitimate ones.

Why it happens:

• Overuse of include: for multiple SaaS tools
• Nested includes from providers (you include them, they include others)
• No visibility into cumulative lookup count

How to fix it:

• Map out every mechanism and its lookup impact
• Remove unused or redundant includes first
• Reassess whether every tool truly needs to send from your domain

What to watch for:

• “Hidden” lookups inside third-party includes
• Gradual buildup over time as new tools are added

Mistake 3: Using +all (pass all)

This explicitly tells receiving servers to trust any sending source, effectively disabling SPF as a security control.

Why it happens:

• Misinterpretation of SPF syntax
• Temporary testing configurations never reverted

How to fix it:

• Replace with ~all while validating your setup
• Move to -all once all legitimate senders are confirmed

What to watch for:

• Old records copied from unreliable sources
• Domains that appear “authenticated” but have no real protection

Mistake 4: Using the deprecated ptr mechanism

Mechanisms like ptr introduce slow, unreliable lookups and may be ignored by modern receivers, leading to inconsistent SPF results.

Why it happens:

• Legacy configurations carried forward over time
• Outdated documentation or templates

How to fix it:

• Remove deprecated mechanisms like ptr
• Replace with explicit include: or ip4: / ip6: entries

What to watch for:

• Over-engineered records trying to handle edge cases
• Mechanisms that add complexity without clear benefit

Mistake 5: Missing legitimate sending sources

Emails from valid platforms fail SPF, which can lead to:

• Messages landing in spam
• Delivery delays or rejections
• DMARC failures if no aligned fallback exists

Why it happens:

• New tools added without updating SPF
• Lack of coordination between teams managing email systems

How to fix it:

• Maintain a centralized list of all approved sending sources
• Add SPF includes as part of the onboarding process—not after issues appear
• Periodically verify that all active senders are covered

What to watch for:

• Transactional systems (billing, alerts) often overlooked
• Regional or team-specific tools sending independently

Mistake 6: SPF record exceeding 255 characters in a single DNS string

SPF records that exceed DNS limits or are improperly formatted may be truncated or misinterpreted, leading to silent failures.

Why it happens:

• Too many includes and mechanisms in a single record
• DNS providers handling long TXT values differently

How to fix it:

• Keep the record as concise as possible
• Use multiple quoted strings within a single TXT record if needed
• Re-check the published record after saving (not just the input)

What to watch for:

• Records that look correct in your DNS panel but resolve incorrectly
• Formatting issues introduced during manual edits

Run a free SPF health check to see if your record has any of these errors

SPF Best Practices for 2026

A correct SPF record is not just about syntax. It’s about maintaining a policy that stays accurate as your email infrastructure evolves. These best practices help ensure your SPF setup remains reliable, efficient, and aligned with modern sender requirements.

1. Maintain a single SPF record per domain

SPF allows only one TXT record starting with v=spf1. Multiple records cause a PermError, breaking authentication entirely. Always merge new entries into your existing record.

2. Keep all legitimate sending sources included

Your SPF record must reflect every system that sends email on your behalf. Missing a sender leads to SPF failures, which directly impacts deliverability and DMARC alignment.

3. Stay within the 10 DNS lookup limit

Each include:, a, mx, exists:, and redirect= counts toward the limit. Exceeding 10 results in a PermError, invalidating SPF for all emails. Regularly audit and optimize your record.

4. Remove unused or outdated includes

Old tools, test environments, and deprecated services often remain in SPF records long after they stop sending. These add unnecessary complexity and consume a lookup budget.

5. Prefer ip4: and ip6: for controlled infrastructure

If you manage dedicated IPs or stable sending ranges, use direct IP mechanisms instead of include:. This reduces DNS lookups and improves performance.

6. Avoid using +all under any circumstance

The +all qualifier allows any server to send on behalf of your domain, effectively disabling SPF as a security control. It should never be used in production.

7. Use ~all during setup, then move to -all

Start with ~all (softfail) while validating your configuration. Once all legitimate senders are confirmed and aligned with DMARC, switch to -all (hardfail) for strict enforcement.

8. Avoid deprecated or risky mechanisms like ptr

The ptr mechanism is deprecated and unreliable. It introduces unnecessary DNS lookups and may be ignored by modern receivers. Use explicit mechanisms instead.

9. Monitor SPF performance with DMARC reports

SPF does not provide visibility on its own. Enable DMARC reporting to track which sources are passing or failing SPF across all receivers and identify unauthorized activity.

10. Treat SPF as a continuously managed system

SPF is not a one-time setup. Every new tool, platform, or vendor that sends email must be reflected in your SPF record. Review and update it regularly to prevent silent failures.

How SPF Works With DKIM and DMARC

SPF, DKIM, and DMARC are designed to work as a coordinated system. Each solves a different part of the email trust problem, including sender legitimacy, message integrity, and identity alignment, and only together do they provide reliable protection and enforcement.

When an email is received, authentication happens in layers:

• SPF checks whether the sending server’s IP is authorized for the domain in the Return-Path (envelope sender)
• DKIM verifies a cryptographic signature attached to the message, confirming it was not altered and that the signing domain is valid
• DMARC evaluates the results of SPF and DKIM and checks whether either one aligns with the visible From address

SPF and DKIM produce raw authentication results, but DMARC determines whether those results are meaningful in the context of what the recipient actually sees.

You need both SPF and DKIM because each covers the other’s weakness. SPF breaks on forwarding. DKIM survives it. DKIM can be stripped by some intermediaries, SPF doesn’t depend on message content. Together, they provide redundancy.

DMARC adds the policy layer: what should receivers do when both SPF and DKIM fail alignment? The three options are none (monitor only), quarantine (send to spam), and reject (block entirely). DMARC also adds reporting – without it, you never know when authentication fails.

Conclusion

SPF is the foundation of email authentication, but it’s only as strong as its configuration and only as useful as the DMARC framework it feeds into. A misconfigured SPF record breaks email delivery, exposes your domain to spoofing, and puts your organization out of compliance with current sender requirements.

The next step is the same whether you’re setting up SPF for the first time or troubleshooting a broken record: check your current configuration.

Check your domain’s email authentication setup with our free Domain Analyzer . It evaluates SPF, DKIM, DMARC, and more in seconds. Need ongoing monitoring, automated SPF management, and DMARC reporting? 

Start a 15-day free trial

Frequently Asked Questions

Can a domain have more than one SPF record?

No. RFC 7208 requires exactly one SPF record per domain. If two TXT records starting with v=spf1 exist, both return PermError and SPF fails entirely. Merge all authorized sources into a single record.

What does it mean if my domain has too many DNS lookups?

Your SPF record exceeds the 10-DNS-lookup limit set by RFC 7208. This causes SPF PermError, which breaks SPF authentication for all email – not just the overflow. Reduce includes, replace with ip4:/ip6:, or use SPF flattening or Macros to stay under the limit.

What is the difference between SPF softfail (~all) and hardfail (-all)?

Softfail (~all) tells receivers to accept the email but mark it as suspicious. Hardfail (-all) tells receivers to reject the email outright. Use softfail during initial setup and testing; switch to hardfail once all legitimate senders are confirmed and DMARC is in place.

Does SPF prevent email spoofing?

Not by itself. SPF checks the envelope sender (Return-Path), not the From header that recipients see. An attacker can pass SPF while spoofing the visible From address. You need DMARC – which checks alignment between SPF/DKIM results and the From header – to prevent display-name spoofing.

What happens when SPF fails?

It depends on the SPF qualifier and whether DMARC is configured. With -all and a DMARC reject policy, the email is blocked. With ~all and no DMARC, the email may still be delivered but flagged as suspicious. Without SPF at all, receivers have no SPF signal to evaluate.

How do I check my SPF record?

Use a free SPF lookup tool. Enter your domain, and the tool retrieves your SPF record from DNS, validates the syntax, counts DNS lookups, and flags any errors – including PermError and void lookup violations.

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

Yes. DMARC requires at least one of SPF or DKIM to pass and align. While DKIM alone can satisfy DMARC, having both SPF and DKIM provides redundancy. If one fails (for example, SPF breaks on forwarding), the other can still pass DMARC alignment.

What is SPF alignment?

SPF alignment means the domain in the Return-Path (envelope sender) matches the domain in the From header. DMARC checks this alignment. Without it, SPF can pass but DMARC will still fail – which is what happens with many third-party senders unless they’re configured to use your domain in the Return-Path.

How often should I update my SPF record?

Review your SPF record whenever you add or remove a sending service, and audit it at least quarterly. SPF records decay as vendors change IP ranges and as your organization’s sending stack evolves. An SPF record that was valid six months ago may be broken or incomplete today.

What is SPF flattening?

SPF flattening resolves all include: mechanisms into raw IP addresses, reducing the DNS lookup count. This keeps you under the 10-lookup limit but creates a static record that must be updated whenever a vendor changes their IPs. Modern alternatives like SPF Macros keep the record dynamic while staying under the limit.

• 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)

• DNS SPF Record: How It Works, and How to Set It Up - May 6, 2026
• What is v=spf1? What Is It Meant For? - May 5, 2026
• DMARC MSP Case Study: How Digital Infinity IT Group Streamlined Client DMARC & DKIM Management with PowerDMARC - April 21, 2026