How SPF Works: The Complete Authentication Flow Explained

SPF (Sender Policy Framework) is one of the core technologies that keeps email trustworthy. But how does it actually work? Understanding the mechanics helps you configure it correctly and troubleshoot when things go wrong.

The SPF Authentication Flow

When you send an email, it passes through several servers before reaching its destination. At the receiving end, the email server performs an SPF check to verify the sender. Here's exactly what happens:

Step 1: Email arrives at the receiving server. Your email reaches the recipient's mail server (like Gmail, Outlook, or a corporate mail gateway). The server notes the IP address of the server that delivered the email.

Step 2: Server extracts the domain. The receiving server looks at the return-path header (also called the envelope sender or MAIL FROM address). This is the address where bounces go, and it's the domain that SPF validates.

Step 3: DNS lookup for SPF record. The receiving server queries DNS for a TXT record at the return-path domain. It's looking for a record that starts with v=spf1.

Step 4: Evaluate the SPF record. The server parses the SPF record and checks whether the sending IP address matches any of the authorized sources listed in the record.

Step 5: Return a verdict. Based on the evaluation, the server assigns an SPF result: pass, fail, softfail, neutral, none, temperror, or permerror.

This entire process takes milliseconds. The result then influences (but doesn't solely determine) whether your email lands in the inbox, spam folder, or gets rejected.

SPF Mechanisms Explained

SPF records use mechanisms to define which servers are authorized to send email. Each mechanism tells receiving servers how to evaluate potential senders.

include

The include mechanism references another domain's SPF record. This is how you authorize third-party email services.

v=spf1 include:_spf.google.com include:sendgrid.net -all

When a server evaluates this record, it recursively checks the SPF records of _spf.google.com and sendgrid.net. If the sending IP matches any of those, the email passes.

ip4 and ip6

These mechanisms authorize specific IP addresses directly.

v=spf1 ip4:203.0.113.0/24 ip6:2001:db8::/32 -all

The ip4:203.0.113.0/24 authorizes any IP from 203.0.113.0 to 203.0.113.255. The ip6 mechanism works the same way for IPv6 addresses.

a

The a mechanism authorizes the IP addresses that your domain's A records point to. If your domain's A record points to 203.0.113.42, that IP is authorized to send email.

v=spf1 a -all

You can also specify a different domain: a:mail.example.com authorizes whatever IPs mail.example.com points to.

mx

The mx mechanism authorizes the servers listed in your domain's MX records. Since your MX servers receive email for your domain, they often need to send email too (like auto-replies or forwards).

v=spf1 mx -all

exists

The exists mechanism performs a DNS lookup and passes if any A record exists for the specified domain. It's primarily used for advanced configurations and macro expansion.

all

The all mechanism matches everything. It's always placed at the end of an SPF record to define what happens with senders that didn't match any previous mechanism.

v=spf1 include:_spf.google.com -all

The -all says "reject anything that didn't match earlier mechanisms."

SPF Qualifiers

Each mechanism can have a qualifier that determines what happens when a match occurs. If no qualifier is specified, + (pass) is assumed.

In practice, you'll see these most often:

• -all — Hard fail. Unauthorized emails should be rejected.
• ~all — Soft fail. Unauthorized emails should be treated with suspicion but not rejected outright. This is often used during SPF setup or when you're not 100% certain you've listed all legitimate senders.
• ?all — Neutral. Rarely used, essentially means "I don't know."

Most organizations start with ~all and move to -all once they're confident their SPF record is complete.

What Happens When SPF Fails

An SPF check can return several results:

Pass — The sending IP is authorized. This is good. It doesn't guarantee inbox delivery, but it's a positive signal.

Fail — The sending IP is explicitly not authorized (matched a - mechanism or -all). The email may be rejected or marked as spam.

SoftFail — The sending IP is probably not authorized (matched ~all). The email isn't rejected but is treated with more suspicion.

Neutral — The SPF record makes no assertion about the IP (?all). The email is treated as if there were no SPF record.

None — No SPF record exists for the domain. The email has no SPF authentication.

TempError — A temporary error occurred during the DNS lookup. The receiving server may retry or accept the email tentatively.

PermError — The SPF record has a syntax error or exceeds limits (like the 10 DNS lookup limit). This is bad—fix your record immediately.

SPF and the Bigger Picture

SPF is one part of a three-part email authentication system:

SPF validates that the sending server is authorized by the return-path domain.

DKIM (check yours) adds a cryptographic signature to emails, proving they haven't been tampered with in transit.

DMARC (check yours) ties SPF and DKIM together, requiring that at least one aligns with the visible "From" domain. It also tells receiving servers what to do with emails that fail authentication.

Together, these three protocols significantly reduce email spoofing and improve deliverability for legitimate senders.

Common SPF Pitfalls

Too many DNS lookups. SPF has a limit of 10 DNS lookups per evaluation. Each include, a, mx, and redirect counts toward this limit. Exceeding it causes a PermError, and your emails may fail authentication. See our guide on the SPF 10 DNS lookup limit.

Multiple SPF records. You can only have one SPF record per domain. Having multiple causes evaluation to fail. Combine all your authorized sources into a single record.

Forgetting email services. If you use a CRM that sends on your behalf, a transactional email service, or a marketing platform, each needs to be in your SPF record. Missing one means those emails may fail SPF.

Not monitoring changes. SPF records need updates when you add or remove email services. Monitoring your records catches issues before they affect deliverability.

Monitor Your SPF Records

Checking once is good. Monitoring continuously is better. The Email Deliverability Suite watches your SPF, DKIM, DMARC, and MX records daily and alerts you when something breaks.