SPF

For an in-depth treatment, see How SPF Works. This page is a quick reference.

SPF record format

Published as a TXT record on the domain:

example.com.   IN TXT  "v=spf1 ip4:203.0.113.0/24 include:_spf.google.com include:sendgrid.net ~all"

Components:

• v=spf1 — version tag, always first.
• ip4: / ip6: — explicit IP ranges authorized.
• include: — pull in another domain's SPF record (used for third-party email services).
• a, mx — authorize the domain's A or MX hosts.
• ~all / -all — fall-through policy. ~all = soft fail (accept but mark); -all = hard fail (reject).

The 10-lookup limit

RFC 7208 limits evaluation to 10 DNS lookups. Every include:, a, mx, ptr, exists counts. Exceeding produces permerror. Most organizations hit this limit by stacking too many third-party services in their SPF.

Fixes:

• Remove unused services from the record.
• Use SPF flattening (services like dmarcian, EasyDMARC inline literal IPs in place of includes).
• Consolidate sending to fewer providers.

What SPF authenticates

SPF checks the envelope sender — the MAIL FROM address used in the SMTP transaction, not the From: header users see. This distinction matters because attackers can set the visible From: to anything; SPF authenticates a different field.

DMARC ties SPF authentication to the visible From: domain, which is what makes the combination useful for preventing brand-spoofing phishing.

The forwarding problem

SPF breaks on email forwarding. If alice@example.com forwards to bob@another.com, the forwarder's IP is not in example.com's SPF record — SPF fails at another.com's receiver. This is one reason DKIM matters: DKIM survives forwarding while SPF does not. DMARC requires only one of SPF or DKIM to pass and align, tolerating forwarding scenarios.

Common SPF mechanisms

How DMARC uses SPF

DMARC requires both:

1. SPF passes (the connecting IP is authorized for the MAIL FROM domain), AND
2. SPF aligns (the MAIL FROM domain matches the From: header domain at the Organizational Domain level).

An SPF pass that doesn't align with the From: domain provides no DMARC protection. This is why marketing platforms that use their own bounce domains (e.g., bounces@mailgun.org) while showing the customer's From: (news@customer.com) need explicit alignment configuration or fall back to DKIM-only DMARC compliance.

Frequently Asked Questions

What does an SPF record look like?

A typical SPF record: v=spf1 ip4:203.0.113.0/24 include:_spf.google.com include:sendgrid.net ~all. The v=spf1 tag identifies it as SPF; the mechanisms (ip4:, include:, etc.) define which sources are authorized; ~all is the fall-through policy (soft fail). Published as a TXT record on the domain. Only one SPF record per domain is allowed — multiple cause receivers to return permerror.

What is the SPF 10-lookup limit?

RFC 7208 limits SPF evaluation to 10 DNS lookups total. Every include:, a, mx, ptr, and exists mechanism counts. Exceeding the limit returns permerror, treated as a fail by DMARC. Most organizations hit this limit by accumulating too many include: mechanisms from third-party email services. Fixes: drop unused services, or use SPF flattening (replace includes with literal IP ranges).

What is the difference between ~all and -all?

~all (soft fail) tells receivers that mail from unauthorized sources is probably spam but they should accept it and mark accordingly. -all (hard fail) tells receivers to reject unauthorized mail. Use ~all during rollout while you discover all your legitimate senders. Switch to -all only after you're confident no legitimate sender will be missed.

Does SPF protect the visible From: address?

No — SPF authenticates the envelope sender (the MAIL FROM in the SMTP transaction), not the visible From: header. An attacker can pass SPF for one domain while setting From: to another. DMARC ties SPF authentication to the visible From: domain. SPF alone is necessary but not sufficient; SPF + DMARC together protect the visible sender.