# Sender Policy Framework (SPF)

> A DNS policy that authorizes IP addresses to use a domain in the SMTP envelope.

- **Category:** Authentication
- **Updated:** July 2026
- **Canonical page:** [https://emailbump.com/glossary/spf](https://emailbump.com/glossary/spf)

## Definition

SPF lets a domain publish which systems may send mail using that domain as the SMTP MAIL FROM or HELO identity. The receiver looks up the applicable TXT record and compares the connecting IP with its mechanisms.

SPF does not directly authenticate the visible From header. DMARC connects SPF to that visible identity only when the SPF-authenticated domain aligns with the From domain.

## Why it matters

SPF gives receivers a machine-readable authorization signal and contributes to DMARC. It is particularly useful for direct delivery, although forwarding often breaks SPF because the forwarding server’s IP is not in the original domain’s policy.

## How it works

1. The sender declares an envelope MAIL FROM domain.
2. The receiver queries that domain’s SPF TXT record.
3. Mechanisms such as ip4, ip6, include, a, and mx are evaluated in order.
4. The receiver returns an SPF result such as pass, fail, softfail, neutral, or temperror.

## Example: A small SPF policy

```text
example.com.  TXT  "v=spf1 include:spf.sender.example ip4:192.0.2.10 -all"

v=spf1                  SPF version
include:...             authorize a provider
ip4:192.0.2.10          authorize one IPv4 address
-all                    all other sources fail
```

## Common mistakes

- Publishing multiple SPF records for the same domain.
- Exceeding the ten DNS-lookup limit during evaluation.
- Authorizing unused vendors indefinitely.
- Expecting SPF alone to survive forwarding or protect the visible From address.

## Key takeaways

- SPF authenticates an envelope identity, not the visible From by itself.
- Keep one record, minimize lookups, and audit includes.
- Use aligned DKIM as a resilient companion.

## Related definitions

- [Email authentication](https://emailbump.com/glossary/email-authentication.md) — The DNS and cryptographic mechanisms receivers use to verify sending identities and domain authorization.
- [DomainKeys Identified Mail](https://emailbump.com/glossary/dkim.md) — A cryptographic signature that lets a domain take responsibility for selected message content.
- [Domain-based Message Authentication, Reporting, and Conformance](https://emailbump.com/glossary/dmarc.md) — An alignment, policy, and reporting layer that connects SPF or DKIM to the visible From domain.

## Related guides

- [How to check your email domain reputation—and improve it](https://emailbump.com/blog/check-email-domain-reputation.md) — A practical guide to authenticated sending domains, Google Postmaster Tools, reputation signals, investigation workflows, stream separation, and recovery.
- [Why Gmail shows “via”—and how to fix your sender identity](https://emailbump.com/blog/gmail-via-label-dkim-alignment.md) — A practical guide to the domains behind Gmail’s via label, aligned DKIM and SPF, third-party senders, forwarding, and the headers that reveal the real problem.
- [DMARC in 2026: how it fights phishing—and where it stops](https://emailbump.com/blog/dmarc-phishing-protection.md) — A practical guide to domain alignment, reporting, safe enforcement, and the phishing attacks DMARC cannot solve on its own.

## Primary sources

- [RFC 7208: Sender Policy Framework](https://www.rfc-editor.org/rfc/rfc7208)