How Does an SPF Check Work?

When a message arrives, the receiving mail server checks the sending domain's SPF record before it does almost anything else with the message. It takes the IP address of the server that connected to it, checks that IP address against the SPF record published by the domain the message claims to be from, and returns one of several results. That result becomes one input the receiving system uses to decide what happens to the message, it is not a verdict on its own.

What Information Does an SPF Check Use?

An SPF check draws on four pieces of information, all of them available during the SMTP session before the message body is even read:

• The connecting server's IP address. The IP address of the system that opened the SMTP connection to deliver the message.
• The HELO/EHLO identity. The hostname the sending server announces when it opens the connection. HELO and EHLO are two SMTP commands that do the same job; EHLO is the modern version.
• The MAIL FROM identity, also called the envelope-sender domain. This is the address used in the SMTP transaction itself, and it can be different from the address a person sees in their inbox.
• The domain's SPF record, a DNS TXT record the domain owner publishes that lists which servers are authorized to send mail using that domain in the identities above.

None of these four is the visible From address a recipient reads in their email client. SPF checks the SMTP-level identities, not the header a person sees.

SPF Verification Process

The sequence above is the same one a receiving mail server runs on every inbound message, condensed into six stages.

1. The outbound mail server begins an SMTP session, opening the connection that will carry the message to the receiving server.
2. The receiving server captures the connecting IP address, the HELO/EHLO identity, and the MAIL FROM identity before it does anything else with the message.
3. The receiving server selects the identity to evaluate. RFC 7208 requires checking the MAIL FROM identity when one is present. Some receivers also check the HELO identity as a secondary check, particularly for messages with no MAIL FROM domain, such as bounce notifications.
4. It requests the domain's DNS TXT record, looking specifically for one that starts with v=spf1. A domain can publish other TXT records for other purposes; only the one starting with v=spf1 is the SPF record.
5. It evaluates the record's mechanisms from left to right, checking the connecting IP address against each one until a mechanism matches or the record runs out of mechanisms to check, at which point an error condition can apply instead.
6. It returns an SPF result to the rest of the receiving system, which combines that result with DMARC, sender reputation, and its own filtering policy to decide what happens to the message next.

What Do the SPF Results Mean?

An SPF check does not only produce a simple pass-or-fail answer. RFC 7208 defines seven possible results, and each one tells the receiving server something different about the connecting IP address.

The exact way a receiving system treats each result depends on that system's own local policy. Two providers can handle a softfail differently, and a fail does not automatically mean a message gets rejected everywhere. Some systems reject on SPF fail alone; others fold the result into a broader score alongside DMARC and reputation data before deciding.

How Does an SPF Record Get Evaluated?

An SPF record is built from mechanisms, each one a rule that either matches the connecting IP address or does not. The most common are:

• ip4 / ip6: matches the connecting IP address directly against a specific address or range, for example ip4:192.0.2.0/24.
• include: pulls in another domain's SPF record and evaluates it as part of this one, commonly used when a company sends through a third-party service such as an email marketing platform.
• a: matches if the connecting IP address matches one of the domain's own A or AAAA DNS records.
• mx: matches if the connecting IP address matches one of the domain's own MX (mail exchanger) records.
• exists: matches based on whether a specific DNS lookup returns a result at all, used in more advanced setups.
• all: matches everything, and is always placed last. A qualifier in front of it decides what happens to anything not already matched by an earlier mechanism.
• redirect: not a mechanism itself but a modifier that points evaluation to another domain's SPF record entirely, used instead of an all mechanism.

Mechanisms are generally evaluated left to right, and the first one that matches the connecting IP address determines the result; nothing after it gets checked.

RFC 7208 also caps the number of DNS-querying mechanisms in a record, such as include, a, mx, exists, and redirect, at 10 lookups total per SPF check. Go over that limit and the record can return a permerror instead of a usable result, which is why most domains keep the count in mind rather than adding every sending service to one growing record.

A short example makes the pieces easier to see. This is illustrative only, not a real record to copy into a domain's DNS:

v=spf1 ip4:192.0.2.10 include:_spf.example.com -all

• v=spf1 marks this as an SPF record, version 1.
• ip4:192.0.2.10 authorizes one specific IP address to send for the domain.
• include:_spf.example.com pulls in and evaluates another domain's SPF record, typically a sending service the domain owner uses.
• -all is the catch-all mechanism placed last. The minus sign is a qualifier meaning hard fail, so any IP address not matched by an earlier mechanism gets an explicit fail result.

What Does SPF Protect, and What Does It Not Protect?

SPF's job is narrow: it can help prevent a server that is not on a domain's authorized list from sending mail using that domain's envelope-sender identity. That is useful, and it is also limited in specific ways worth naming directly. SPF does not:

• Validate the visible From address by itself. SPF checks the MAIL FROM and HELO identities, not the header a recipient reads.
• Encrypt email. SPF is an authorization check, not a transport-security control.
• Inspect attachments or message content. SPF never opens the message; it only checks where it came from.
• Survive forwarding reliably. When a message is forwarded, the forwarding server's IP address is usually not on the original domain's SPF record, so SPF can fail even for a legitimate message.
• Work well alone. SPF is strongest when combined with DKIM and DMARC, which cover the gaps SPF leaves open.

How Does SPF Work With DMARC?

DMARC checks whether the domain authenticated by SPF, or by DKIM, aligns with the domain visible in the message's From header. For that alignment check, the SPF-authenticated identity that matters is the MAIL FROM domain, not the HELO identity; DMARC does not evaluate HELO at all. The companion article on how SPF, DKIM and DMARC work together covers DMARC alignment, policies, and reporting in more detail.

Common SPF Configuration Problems

• Publishing more than one SPF record. RFC 7208 allows only one per domain; a second record typically causes a permerror instead of the two being combined.
• Exceeding the 10-DNS-lookup limit, often by adding sending services over time without ever removing old ones.
• Forgetting an authorized third-party sending service, which causes that service's mail to fail SPF.
• Using an overly permissive mechanism, such as a broad IP range that authorizes more infrastructure than the domain uses.
• Failing to remove old services, which widens the set of servers authorized to send as the domain for no current reason.
• Assuming SPF protects the visible From address on its own, when that protection depends on DMARC being configured and enforced too.

The companion post on SPF record syntax covers how to write and fix a record's mechanisms directly, and the SPF checker reads a domain's live record over DNS to flag these problems for free.

Key Takeaway

SPF gives a receiving mail server one specific, useful piece of evidence: whether the connecting IP address is authorized to send for the SMTP identity the message presents. It is not a complete spoofing defense on its own, and it does not touch the address a recipient sees. Configured correctly, kept under the 10-lookup limit, and combined with DKIM and DMARC, SPF becomes one solid piece of a domain's broader email authentication setup