What is the SPF rule for email?

The SPF rule for email is a DNS-based authentication mechanism that defines which mail servers are authorized to send email on behalf of your domain. When a receiving mail server gets a message, it checks the sender’s domain for an SPF record and compares the sending server’s IP address against the list of approved senders. If the IP matches, the email passes SPF. If it does not, the email fails or is flagged as suspicious.

SPF is one of the three core email authentication standards, alongside DKIM and DMARC, and it plays a foundational role in protecting your domain from spoofing and improving inbox placement. The sections below unpack how SPF configuration works in practice, from record syntax to forwarding problems to the infamous 10-lookup limit.

How does the SPF rule actually work?

SPF works by allowing domain owners to publish a list of authorized sending IP addresses in their DNS. When an email arrives, the receiving server performs a DNS lookup on the domain in the envelope “From” address, retrieves the SPF record, and checks whether the sending server’s IP is on the approved list. The result determines whether the message passes, fails, or is treated with suspicion.

The check happens at the SMTP envelope level, not the visible “From” header you see in your inbox. This distinction matters because it means SPF validates the domain used during the mail transfer process, which can differ from the display name a recipient sees. This is why SPF alone is not a complete solution against spoofing, but it remains an essential first layer of defense.

SPF configuration is set entirely through DNS. You publish a TXT record on your domain, and every time someone receives an email claiming to be from that domain, their mail server silently runs this check in the background. The whole process typically completes in milliseconds.

What does an SPF record look like?

An SPF record is a DNS TXT record that starts with v=spf1 and lists the mechanisms that define which servers are allowed to send mail for your domain. A typical record ends with either ~all (softfail) or -all (fail) to instruct receiving servers on how to handle mail from sources not listed in the record.

Here is a straightforward example of what an SPF record might look like:

• v=spf1 declares the SPF version being used
• include:sendingprovider.com authorizes a third-party sending service
• ip4:203.0.113.5 directly approves a specific IP address
• -all tells receiving servers to reject anything not listed above

Each mechanism in the record is evaluated in order from left to right. You can authorize your own mail servers, third-party email service providers, marketing platforms, and transactional email tools all within a single record. The key is keeping the record lean, accurate, and within the DNS lookup limits covered later in this article.

What are the SPF pass, fail, and softfail results?

SPF produces one of several result codes after evaluating an incoming message. The three most common outcomes are Pass (the sending IP is authorized), Fail (it is explicitly not authorized), and SoftFail (it is not authorized, but the domain owner has not committed to rejection). Each result signals a different level of trust to the receiving mail server.

Here is a breakdown of the main SPF results:

• Pass: The sending IP matches an approved mechanism. The email is treated as legitimate from an SPF perspective.
• Fail (-all): The sending IP is not authorized, and the domain owner has explicitly said to reject it. This is the strictest outcome.
• SoftFail (~all): The sending IP is not authorized, but the domain owner is signaling uncertainty rather than hard rejection. Mail servers typically accept the message but may mark it or apply additional scrutiny.
• Neutral (?all): The domain owner makes no assertion about the sending IP. Rarely used in practice.
• None: No SPF record was found for the domain at all.
• TempError / PermError: The SPF check could not be completed due to a DNS error or a misconfigured record.

For most senders, the practical choice comes down to -all versus ~all. Using -all is more assertive and better for domains with a well-maintained SPF record. Using ~all is safer during transitions or when you are not fully confident your record covers every legitimate sending source.

Why does SPF break when email is forwarded?

SPF breaks during email forwarding because the forwarding server relays the message using its own IP address, which is almost certainly not listed in the original sender’s SPF record. Since SPF checks the IP of the server that delivered the message, not the original sender, the forwarded email fails SPF even though it is a legitimate message.

This is one of the most frustrating and well-known limitations of SPF. When a recipient’s email server forwards a message to another address, it typically preserves the original envelope “From” domain but sends the email from its own infrastructure. The receiving server at the final destination then checks SPF against the original domain, finds that the forwarding server’s IP is not listed, and marks the message as a fail.

The practical consequence is that forwarding can trigger spam filters or cause DMARC failures, since DMARC can use SPF alignment as part of its evaluation. This is one of the reasons DKIM is considered more forwarding-resilient than SPF. DKIM uses a cryptographic signature attached to the message headers, which survives forwarding as long as the message content is not altered. A well-configured email authentication setup uses both standards together so that forwarded mail can still pass DMARC via DKIM even when SPF fails.

What is the SPF 10-lookup limit and how do you fix it?

The SPF 10-lookup limit is a hard constraint defined in the SPF specification that restricts the number of DNS lookups a receiving server will perform when evaluating your SPF record to a maximum of ten. If your record requires more than ten lookups to fully resolve, the evaluation returns a PermError, which can cause legitimate email to fail authentication.

Every include:, a:, mx:, and redirect= mechanism in your SPF record triggers at least one DNS lookup. Modern sending environments, where a domain might use multiple ESPs, a transactional email provider, a CRM, and a marketing automation platform simultaneously, can easily exceed this limit without anyone noticing until deliverability problems appear.

How to diagnose the problem

You can check your current lookup count using any SPF diagnostic tool. Enter your domain, and the tool will walk through each mechanism and count the DNS lookups required. If the count exceeds ten, you have a problem that needs fixing before it affects inbox placement.

How to fix it

There are two main approaches to resolving SPF lookup limit issues:

• Flatten your SPF record: Replace include: statements with the actual IP addresses those mechanisms resolve to. This removes the need for additional lookups. The downside is that you must update your record whenever a sending provider changes its IP ranges.
• Use a dynamic SPF management service: Some tools automatically maintain a flattened, up-to-date SPF record on your behalf, so you never manually chase IP changes from third-party senders.

Keeping your SPF record lean and accurate is an ongoing maintenance task, not a one-time setup. Every time you add a new email tool or switch providers, your SPF record needs a review.

How does SPF work with DKIM and DMARC?

SPF, DKIM, and DMARC are three complementary email authentication standards that work together to protect your domain. SPF verifies the sending server’s IP address, DKIM verifies the message content using a cryptographic signature, and DMARC uses the results of both to enforce a policy and report on authentication outcomes. All three should be configured together for effective protection.

DMARC is the layer that ties SPF and DKIM together. For a message to pass DMARC, it needs to pass either SPF or DKIM, and the authenticated domain must align with the domain in the visible “From” header. This alignment requirement is what makes DMARC meaningful as an anti-spoofing tool, since it closes the gap that SPF alone leaves open.

In practical terms, relying on SPF alone is not sufficient. Because SPF fails on forwarded mail and is vulnerable to the lookup limit, having a valid DKIM signature ensures that legitimate messages can still pass DMARC even when SPF does not. The combination of all three standards gives receiving servers a complete picture of whether an email is genuinely from your domain, and it gives you the reporting data to detect and respond to abuse.

Getting all three standards configured correctly and kept in sync as your sending infrastructure evolves is where most of the real work in email deliverability lies.

How Email Industries helps with SPF configuration

SPF configuration sounds straightforward until you are managing multiple sending platforms, troubleshooting a PermError, or trying to understand why forwarded mail keeps triggering DMARC failures. That is exactly where we step in. At Email Industries, we help organizations get their SPF setup right from the ground up and keep it that way as their sending environment changes.

Here is what we bring to the table:

• SPF record audits: We review your existing record for errors, redundancies, and lookup limit violations before they affect deliverability.
• Full authentication setup: We configure SPF alongside DKIM and DMARC to ensure all three standards work together correctly and your domain is protected against spoofing.
• Ongoing monitoring: We track authentication results and flag issues as your sending infrastructure evolves, so a new tool or provider change does not quietly break your SPF record.
• Forwarding and alignment troubleshooting: We diagnose complex scenarios like forwarding failures and DMARC misalignment that go beyond a simple DNS fix.
• Inbox placement improvement: Correct SPF configuration is one piece of a broader deliverability strategy, and we connect the dots across your entire sending setup.

Whether you are setting up authentication for the first time or untangling a configuration that has grown out of control, we are here to help. Reach out and contact us to talk through your SPF setup and what it might be costing your deliverability.

Related Articles

• What are the most reputable domains?
• Is SPF required for email?
• What are the most common BIMI implementation mistakes to avoid?
• What is the difference between BIMI and DMARC?
• What is a DMARC policy and how does it work?
• When should you update your DKIM keys for better security?
• How does DKIM authentication help with inbox placement?
• Can a broken SPF record cause your emails to land in spam?
• What is SPF configuration in email authentication?
• How do email advertising agencies handle underperforming campaigns?
• How do email advertising agencies handle creative development?
• When should you use a new domain for email migration?
• What is a domain warmup schedule and how do you build one?
• What is the difference between a warm IP and a cold IP?
• What is an ecommerce email marketing agency?