SPF, or Sender Policy Framework, works by allowing domain owners to publish a list of authorized mail servers in their DNS records. When a receiving mail server gets an email claiming to be from your domain, it checks that list to verify the sending server is allowed to send on your behalf. If the server is not on the list, the email fails SPF authentication. Understanding how SPF configuration works end to end helps you troubleshoot failures, improve inbox placement, and build a stronger authentication foundation alongside DKIM and DMARC.
What does an SPF record actually contain?
An SPF record is a DNS TXT record published on your domain that lists every mail server, IP address, or third-party service authorized to send email on your behalf. It begins with a version tag (v=spf1), followed by one or more mechanisms that define permitted senders, and ends with an all-mechanism that tells receiving servers what to do with mail from unlisted sources.
Here is what a typical SPF record includes:
- v=spf1: The version tag that identifies the record as SPF.
- ip4 or ip6: Specific IP addresses or ranges authorized to send mail.
- include:: References to SPF records published by third-party senders like your ESP or CRM.
- a and mx: Shortcuts that authorize the IP addresses behind your domain’s A record or MX record.
- ~all or -all: The catch-all qualifier. A tilde (~) means soft fail, while a hard minus (-) means fail for anything not explicitly listed.
Every mechanism in the record is evaluated in order from left to right. The first matching mechanism determines the result, which is why the order of entries matters for both accuracy and performance.
How does a receiving mail server check SPF?
When a receiving mail server accepts an incoming connection, it checks SPF by looking up the TXT record published for the domain in the email’s envelope sender address, also called the Return-Path or MAIL FROM address. It then compares the IP address of the connecting server against the mechanisms listed in that SPF record.
The process follows these steps:
- The sending server connects and provides the envelope sender domain.
- The receiving server queries DNS for a TXT record on that domain starting with v=spf1.
- The receiving server works through each mechanism in order, checking whether the sending IP matches.
- The first match determines the SPF result, which is then passed along in the email’s authentication headers.
One important detail is that SPF evaluates the envelope sender domain, not the friendly From address visible to recipients. This distinction becomes significant when emails are forwarded, because the connecting IP changes but the envelope sender may stay the same, causing SPF to fail even for legitimate mail.
What are the possible SPF authentication results?
SPF authentication produces one of several defined results that tell the receiving server how to interpret the check. The most common results are Pass, Fail, SoftFail, Neutral, None, TempError, and PermError, each carrying a different meaning for how the receiving server should handle the message.
- Pass: The sending IP matched an authorized mechanism. The email is considered legitimate from an SPF perspective.
- Fail: The sending IP did not match, and the record ends with -all. The email should be rejected or heavily filtered.
- SoftFail: The sending IP did not match, and the record ends with ~all. The email is suspicious but not outright rejected.
- Neutral: The domain owner has explicitly stated no assertion about the sending IP, typically using ?all.
- None: No SPF record was found for the domain.
- TempError: A temporary DNS lookup failure prevented the check from completing.
- PermError: A permanent error in the SPF record itself, such as exceeding the DNS lookup limit, made the check impossible.
PermError is particularly important to watch for. SPF allows a maximum of ten DNS lookups during evaluation. Records with many include: statements from multiple ESPs and tools can easily exceed this limit, causing a PermError result that effectively breaks SPF for every email you send.
Why does SPF fail even when the record looks correct?
SPF can fail despite a seemingly correct record for several common reasons rooted in how the protocol actually evaluates mail. The most frequent causes are exceeding the ten DNS lookup limit, sending through a server not listed in the record, email forwarding, and subtle mismatches between the envelope sender domain and the domain where the SPF record lives.
Exceeding the DNS lookup limit
Every include:, a, mx, or redirect mechanism triggers an additional DNS query. SPF caps these at ten. If your record includes several third-party senders, such as a marketing platform, a transactional email service, a CRM, and a helpdesk tool, those includes can chain together and push you past the limit. The result is a PermError that causes SPF to fail for all your mail, regardless of whether the sending IP would otherwise match.
Email forwarding breaks the envelope path
When a recipient’s mail server forwards an email to another address, the connecting IP changes to the forwarding server’s IP. SPF checks the connecting IP against the original sender’s record, so the forwarding server almost certainly does not appear in that record. This is a structural limitation of SPF, not a configuration error, and it is one of the reasons DKIM and DMARC exist alongside SPF rather than as replacements for it.
How does SPF work alongside DKIM and DMARC?
SPF, DKIM, and DMARC are three separate but complementary email authentication protocols that work together to verify sender identity and instruct receiving servers on how to handle unauthenticated mail. SPF verifies the sending server, DKIM verifies the message content, and DMARC ties both together under a published policy with reporting.
Here is how each layer contributes:
- SPF confirms that the IP address sending the email is authorized by the domain in the envelope sender. It protects against unauthorized use of your domain in the sending infrastructure.
- DKIM adds a cryptographic signature to the message headers. Because the signature travels with the message, it survives email forwarding where SPF does not.
- DMARC requires that at least one of SPF or DKIM aligns with the visible From domain. It also lets domain owners set a policy (none, quarantine, or reject) and receive aggregate reports on authentication activity across their domain.
A strong SPF configuration is the foundation, but SPF alone is not enough. Without DKIM, forwarded mail loses its authentication signal. Without DMARC, there is no enforcement policy and no visibility into who is sending mail using your domain. The three protocols are designed to be deployed together, with each one covering gaps the others leave open.
How Email Industries helps with SPF configuration
Getting SPF right is more involved than it first appears. Between managing lookup limits, coordinating records across multiple sending services, and ensuring alignment with DKIM and DMARC, even experienced teams run into problems that quietly undermine deliverability. That is where we come in.
At Email Industries, we help organizations build and maintain a solid SPF configuration as part of a complete authentication strategy. Here is what we bring to the table:
- SPF record auditing: We review your existing record for errors, redundant mechanisms, and lookup limit violations that could be causing silent failures.
- Multi-sender coordination: We map every service sending mail on your behalf and structure your SPF record to stay within limits while covering all legitimate senders.
- DKIM and DMARC alignment: We ensure your SPF configuration works in concert with your DKIM signatures and DMARC policy so authentication holds up across forwarding scenarios and third-party sending.
- Ongoing monitoring: Using our Blackbox risk-scoring technology and Alfred platform, we help you stay ahead of changes that could break authentication over time.
If your emails are landing in spam or your authentication results are inconsistent, a misconfigured SPF record is often part of the problem. We would be glad to take a look and help you get it sorted out. Reach out and contact our team to get started.
Related Articles
- How are full service email agencies adapting to AI and automation?
- How often do full service agencies review and update strategies?
- How do email advertising agencies adapt to algorithm changes?
- What are the most common mistakes made during email platform migrations?
- What data do you need to transfer during an email platform migration?
- How do email advertising agencies approach seasonal campaigns?
- How quickly can agencies restore damaged sender reputation?
- What is a domain warmup schedule and how do you build one?
- Can you run IP warming on a shared IP address?
- What is a full service email marketing agency?
- How do agencies set up proper email authentication?
- How do ESPs handle IP warming for new senders?
- How do agencies ensure CAN-SPAM compliance?
- What is the difference between a managed and self-service email platform migration?
- How do email deliverability agencies track inbox placement rates?
