How SPF Works: Technical Deep Dive

You know SPF lets you declare which servers can send email for your domain. But what actually happens under the hood when a receiving mail server processes an incoming message? This article walks through the full verification chain — from DNS query to final result.

The SPF Check Lifecycle

Every SPF check follows the same sequence. Understanding it helps you debug deliverability issues and write better SPF records.

Envelope Sender vs From Header

This is the single most misunderstood part of SPF. There are two "from" addresses on every email, and SPF only checks one of them.

Envelope Sender (Return-Path): This is the address used during the SMTP transaction. It's set in the MAIL FROM command and shows up in the Return-Path header. SPF checks this domain.

From Header: This is the address recipients see in their email client. SPF does not check this. An attacker can set the From header to anything they want, and SPF won't catch it.

This matters for third-party services too. When SendGrid or Mailchimp sends email on your behalf, they often use their own domain in the Return-Path (like bounces.sendgrid.net). SPF passes for their domain, not yours. For SPF to help with DMARC, the Return-Path domain needs to match (or be a subdomain of) your From header domain.

The DNS Lookup Process

When a receiving server evaluates your SPF record, it may need to perform multiple DNS queries. Here's what triggers a lookup:

Mechanisms That Require DNS Lookups

• include: — Requires a lookup for the referenced domain's SPF record, plus any nested lookups within it
• a — Looks up the A (or AAAA) record for the specified domain
• mx — Looks up the MX records, then resolves each MX hostname to IP addresses
• exists: — Performs an A record lookup to check if the domain resolves
• redirect= — Fetches the SPF record from another domain (counts as a lookup)

Mechanisms That Don't Require DNS Lookups

• ip4: — Direct IP comparison, no DNS needed
• ip6: — Direct IP comparison, no DNS needed
• all — Matches everything, no DNS needed

SPF Evaluation Order

Mechanisms are evaluated strictly left to right. The first match wins. This matters more than you might think.

Given this record:

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

The evaluation order is:

1. Is the sending IP 203.0.113.50? If yes, pass. Stop.
2. Is the sending IP in Google's authorized list? If yes, pass. Stop.
3. Nothing matched, hit -all. Result: fail.

If you put ip4 mechanisms first, you save DNS lookups for messages from those IPs. This is a minor optimization, but it's good practice.

SPF Result Codes

The SPF check produces one of seven results. Each one tells the receiving server something different.

Pass

The sending IP matched an authorized mechanism. This is what you want for all your legitimate sending sources.

Fail vs Softfail

-all produces a fail — a strong statement that unauthorized IPs should be rejected. ~all produces a softfail — a weaker statement that says "this IP probably isn't authorized, but don't reject it outright."

In practice, most receiving servers treat softfail similarly to fail when DMARC is also configured with p=reject or p=quarantine. Softfail is mainly useful during initial SPF setup when you're still identifying all your sending sources.

Permerror

A permerror means your SPF record is broken. Common causes include exceeding the 10-lookup limit, having syntax errors, or having multiple SPF records on the same domain. This is the worst outcome — it means SPF can't be evaluated at all.

SPF and DMARC Alignment

DMARC adds a critical layer on top of SPF by requiring alignment. This means the domain in the Return-Path (checked by SPF) must match the domain in the From header (what recipients see).

There are two alignment modes:

• Strict alignment — The Return-Path domain must exactly match the From header domain
• Relaxed alignment — The Return-Path domain can be a subdomain of the From header domain (or vice versa)

For example, if your From header is user@example.com:

• Return-Path of bounce@example.com — passes both strict and relaxed alignment
• Return-Path of bounce@mail.example.com — passes relaxed alignment only
• Return-Path of bounce@sendgrid.net — fails both. SPF might pass, but DMARC won't count it

What Happens After SPF

SPF is just one input in the receiving server's decision. Here's the full picture:

1. SPF check produces a result (pass/fail/softfail/etc.)
2. DKIM check verifies the cryptographic signature (if present)
3. DMARC check evaluates whether SPF or DKIM passed and aligned
4. Reputation systems consider the sender's history, IP reputation, and domain age
5. Content filtering scans the message body for spam signals
6. Final decision — deliver to inbox, send to spam, or reject

A passing SPF check doesn't guarantee inbox delivery. But a failing SPF check significantly increases the chance of rejection or spam classification, especially when combined with a strict DMARC policy.

Practical Implications

Understanding how SPF works technically has direct consequences for how you set up your records:

Monitor Your New SPF Record

You've created your SPF record — now make sure it keeps working. The Email Deliverability Suite watches your SPF, DKIM, DMARC, and MX records daily and alerts you when something breaks.