# What is SPF, and how does an SPF record work?

URL: https://iblockspam.com/blog/what-is-spf
Last updated: 2026-10-09
Published: 2026-10-09
Topic: SPF, DKIM & DMARC
Author: iBlockSpam Team

> What an SPF record is, how receivers check it against the envelope sender, the 10-lookup limit, what SPF can't do, and how to create one for your domain.

## Short answer

SPF (Sender Policy Framework) is a DNS TXT record that lists the servers allowed to send mail for your domain. Receivers compare the connecting server's IP address with the record for the envelope sender (MAIL FROM) domain and get pass, fail, softfail or another result. SPF doesn't check the visible From address; DMARC does that.

SPF is the oldest of the three email authentication records and the one most domains already have. It answers one narrow question: is this server allowed to send mail using this domain in the envelope? This guide explains how receivers run that check, where it stops being useful, and how to publish a record that works. It's also the hub for our SPF guides.

## What is an SPF record?

SPF stands for Sender Policy Framework. It is defined in [RFC 7208](https://www.rfc-editor.org/rfc/rfc7208.html), a Standards Track document from April 2014 that replaced the experimental RFC 4408. In the RFC's words, it lets domain owners "authorize hosts to use their domain names in the 'MAIL FROM' or 'HELO' identities."

The record is a single DNS TXT record on the domain itself:

```
example.com.  3600  IN  TXT  "v=spf1 include:spf.protection.outlook.com ip4:203.0.113.10 -all"
```

- `v=spf1` marks the TXT record as SPF. Receivers discard TXT records that don't start with exactly this.
- `include:` and `ip4:` are **mechanisms**: each one describes servers that may send.
- `-all` is the catch-all at the end. It sets the result for every server not listed.

RFC 7208 section 3.1 says SPF records "MUST be published as a DNS TXT (type 16) Resource Record" only. The separate SPF record type from the experimental phase is discontinued. A domain may publish only one SPF record; two or more give PermError ([section 4.5](https://www.rfc-editor.org/rfc/rfc7208.html#section-4.5)).

## How does a receiver check SPF?

SPF normally runs during the SMTP conversation, before the message body arrives; RFC 7208 says the check "SHOULD be performed" then. The receiving server knows three things at that point: the IP address that connected, the name the server gave in `HELO`/`EHLO`, and the envelope sender in `MAIL FROM`.

1. **Optionally check the HELO name.** RFC 7208 section 2.3 says it is "RECOMMENDED" to check the HELO identity as well. A conclusive HELO result can save the more complex MAIL FROM check.
2. **Check the MAIL FROM domain.** Verifiers "MUST check the 'MAIL FROM' identity" if a HELO check wasn't done or wasn't conclusive (section 2.4). For bounces, which have an empty MAIL FROM, SPF uses `postmaster@` plus the HELO name instead.
3. **Fetch the TXT record** for that domain and keep the one that starts with `v=spf1`.
4. **Evaluate mechanisms left to right.** The first one that matches the connecting IP decides the result, using its qualifier. Nothing after it is read.
5. **Record the result**, usually in an `Authentication-Results` or `Received-SPF` header, and apply local policy.

The function returns one of seven results ([section 2.6](https://www.rfc-editor.org/rfc/rfc7208.html#section-2.6)):

| Result | What it means | Typical cause |
|---|---|---|
| `pass` | The IP is authorized | The server is listed |
| `fail` | The IP is explicitly not authorized | Unlisted server, record ends `-all` |
| `softfail` | Probably not authorized | Unlisted server, record ends `~all` |
| `neutral` | The domain makes no statement | Record ends `?all` |
| `none` | No SPF record, or no usable domain | No `v=spf1` record published |
| `temperror` | A temporary DNS problem | Timeout; retrying may work |
| `permerror` | The record can't be interpreted | Two records, syntax error, too many lookups |

RFC 7208 deliberately leaves handling to the receiver: "the protocol establishes no normative requirements for handling any particular result." Microsoft puts it plainly for `-all` and `~all`: "What actually happens to the message depends on the destination email system."

## What are SPF mechanisms and qualifiers?

Mechanisms match the sending IP. The common ones are `ip4`, `ip6`, `include`, `a`, `mx` and `all`. Each can carry a qualifier: `+` pass (the default), `-` fail, `~` softfail and `?` neutral. Two modifiers, `redirect=` and `exp=`, round out the syntax.

| Mechanism | Matches when | Counts toward the lookup limit? |
|---|---|---|
| `ip4`, `ip6` | The IP is in the listed address or range | No |
| `include:domain` | The other domain's SPF check passes for this IP | Yes |
| `a`, `mx` | The IP belongs to the named host or MX hosts | Yes |
| `exists`, `ptr` | Special cases; `ptr` shouldn't be used | Yes |
| `all` | Always; goes last | No |

Every mechanism, with copy-ready examples and the mistakes we see most, is covered in [SPF record syntax and examples](https://iblockspam.com/blog/spf-record-syntax-examples).

## What are the SPF lookup limits?

SPF can trigger many DNS queries, so RFC 7208 caps them. [Section 4.6.4](https://www.rfc-editor.org/rfc/rfc7208.html#section-4.6.4) sets three limits:

- **10 DNS-querying terms.** The `include`, `a`, `mx`, `ptr` and `exists` mechanisms and the `redirect` modifier count, including those inside records you include. Implementations "MUST limit the total number of those terms to 10", and going over "MUST return 'permerror'."
- **2 void lookups.** A lookup that returns no records, or a domain that doesn't exist, is a "void lookup". Implementations "SHOULD limit 'void lookups' to two", and exceeding the limit produces PermError. An `include` that points at a retired vendor domain is the usual cause.
- **10 address records per `mx` or `ptr` term.** An `mx` mechanism whose hosts resolve to more than 10 A or AAAA lookups returns PermError.

`ip4`, `ip6` and `all` don't count. Microsoft notes that fewer than 10 `include` statements "doesn't guarantee fewer than 10 DNS lookups", because includes can nest ([Microsoft Learn](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure)).

This limit catches large organizations too. In our [October 2026 scan of the Tranco top 1,000 domains](https://iblockspam.com/research/email-security-top-1000), 22 domains published an SPF record over the 10-lookup limit and 4 published more than one SPF record. Our guide to [SPF PermError: too many DNS lookups](https://iblockspam.com/blog/spf-too-many-dns-lookups) shows how to count and cut lookups.

## What doesn't SPF do?

SPF is useful but narrow. Know its blind spots before you rely on it.

### It doesn't check the From address

SPF authenticates the MAIL FROM domain (and optionally HELO). The `From:` line people read in their mail client is a different header and can name any domain. A spammer can pass SPF for `attacker.example` while showing your domain in From. Linking the two is DMARC's job.

### It breaks when mail is forwarded

When a message is forwarded, it arrives from the forwarder's IP, which isn't in your record. RFC 9989 section 7.4 says such mail "will most likely fail SPF checks" unless the forwarder rewrites the MAIL FROM address, while "DKIM signatures will generally remain valid." [Appendix D of RFC 7208](https://www.rfc-editor.org/rfc/rfc7208.html#appendix-D) describes the rewriting workarounds. Our guide to [why forwarding breaks SPF and DMARC](https://iblockspam.com/blog/email-forwarding-breaks-spf-dmarc-arc) covers SRS and ARC.

### It doesn't cover subdomains

SPF is checked for the exact domain in MAIL FROM. `news.example.com` needs its own record; it doesn't inherit `example.com`'s. Microsoft says each subdomain that sends mail "requires its own SPF TXT record."

### It says nothing about content

A message from an authorized server can still be spam or phishing. SPF proves only where the message came from, not whether it's wanted.

## How does SPF work with DMARC?

[RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html), the current DMARC standard, uses SPF as one of its two inputs. It is explicit about which identity: "DMARC relies solely on SPF validation of the MAIL FROM identity." HELO results don't count.

An SPF pass helps DMARC only when the MAIL FROM domain **aligns** with the From domain. Under the default relaxed mode, `bounce.example.com` aligns with `example.com`; `mailer-vendor.net` doesn't. RFC 9989 explains why alignment is needed: "any Domain Owner, even a bad actor, can publish an SPF record for its domain and send an email that will obtain an SPF 'pass' result."

This is the most common surprise with third-party senders. Many newsletter, CRM and helpdesk tools use their own bounce domain by default. SPF passes, but for their domain, so it doesn't count toward your DMARC result. The fix is a custom return-path (often called a custom MAIL FROM or bounce domain) on a subdomain of yours, or aligned DKIM. Our guide to [why DMARC fails](https://iblockspam.com/blog/why-dmarc-fails) walks through the cases.

To DMARC, `fail`, `softfail`, `neutral`, `none` and `permerror` are all the same: no aligned SPF pass. Then DKIM has to carry the message. See [what DMARC is and how it works](https://iblockspam.com/blog/what-is-dmarc), and [SPF vs DKIM vs DMARC](https://iblockspam.com/blog/spf-vs-dkim-vs-dmarc) for what each record proves.

## Should an SPF record end in ~all or -all?

Both are defensible for a sending domain, and sources disagree:

| Source | Advice for domains that send mail |
|---|---|
| [M3AAWG](https://www.m3aawg.org/sites/default/files/m3aawg-email-authentication-recommended-best-practices-09-2020.pdf) | "SPF records should end in ~all" |
| [Google](https://knowledge.workspace.google.com/admin/security/set-up-spf) | "Google recommends you use ~all in your SPF record" |
| [Microsoft](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure) | Recommends `-all` for Microsoft 365 domains that also use DKIM and DMARC |

The reason for caution is in [RFC 9989 section 7.1](https://www.rfc-editor.org/rfc/rfc9989.html): some receivers check SPF early, so a `-all` failure "could cause a message to be rejected early in the SMTP transaction, before any DMARC processing takes place", even when aligned DKIM would have passed it.

A sensible default: use `~all` while you're still finding all your senders, and consider `-all` once DKIM is on every service and DMARC reports are clean. For a domain that never sends mail, publish `v=spf1 -all`; Microsoft and M3AAWG both recommend that for parked domains. Never use `+all`, and don't leave `?all` in production. The full comparison is in [SPF softfail vs hardfail](https://iblockspam.com/blog/spf-softfail-vs-hardfail).

## How do I create an SPF record?

1. **List every service that sends as your domain:** your mailbox platform, website and forms, CRM, helpdesk, invoicing and newsletter tools. Google's [sender guidelines](https://support.google.com/mail/answer/81126) require SPF or DKIM from everyone sending to Gmail.
2. **Get each provider's documented value.** Our [SPF records by email provider](https://iblockspam.com/spf) pages list the exact include for common services, such as [Microsoft 365](https://iblockspam.com/spf/microsoft-365) and [Google Workspace](https://iblockspam.com/spf/google-workspace), with their measured lookup cost.
3. **Move bulk senders to a subdomain** where you can. Microsoft recommends this for services you don't directly control, and the subdomain gets its own 10-lookup budget.
4. **Build one record.** The [SPF Record Generator](https://iblockspam.com/tools/spf-generator) assembles it from your services and counts lookups.
5. **Publish or edit it at your DNS host.** Replace the existing record; never add a second `v=spf1` record.
6. **Check it** with the [SPF Checker](https://iblockspam.com/tools/spf-checker) for syntax, lookup count and the `all` ending.
7. **Test real mail.** Send from each service to an outside mailbox and look for `spf=pass` in the headers, using the [Email Header Analyzer](https://iblockspam.com/tools/email-header-analyzer).
8. **Add DKIM and DMARC.** SPF alone doesn't protect the From address.

## Our SPF guides

| If you need to... | Read |
|---|---|
| Write or fix a record, term by term | [SPF record syntax and examples](https://iblockspam.com/blog/spf-record-syntax-examples) |
| Fix PermError from too many lookups | [SPF too many DNS lookups](https://iblockspam.com/blog/spf-too-many-dns-lookups) |
| Choose between `~all` and `-all` | [SPF softfail vs hardfail](https://iblockspam.com/blog/spf-softfail-vs-hardfail) |
| Find the exact include for a provider | [SPF records by email provider](https://iblockspam.com/spf) |
| Understand forwarding failures | [Why forwarding breaks SPF and DMARC](https://iblockspam.com/blog/email-forwarding-breaks-spf-dmarc-arc) |
| Compare SPF with DKIM and DMARC | [SPF vs DKIM vs DMARC](https://iblockspam.com/blog/spf-vs-dkim-vs-dmarc) |
| Lock down domains you don't send from | [Protect parked domains from spoofing](https://iblockspam.com/blog/protect-parked-domains-from-spoofing) |

## Next steps

1. Run your domain through the [SPF Checker](https://iblockspam.com/tools/spf-checker) to see your record, its lookup count and its `all` ending.
2. If anything is missing or broken, rebuild the record with the [SPF Record Generator](https://iblockspam.com/tools/spf-generator) and replace the old one.
3. Publish `v=spf1 -all` on every domain you own that doesn't send mail.
4. Set up DKIM on each sending service, then publish DMARC; start with [what DMARC is](https://iblockspam.com/blog/what-is-dmarc).
5. Get the whole picture at once with the [Email Health Check](https://iblockspam.com/tools/email-health-check). If you'd like to hear when someone changes your SPF record, iBlockSpam [domain monitoring](https://iblockspam.com/features/domain-monitoring) sends drift alerts.

SPF records tend to break when someone adds a service months later. The [Free Domain Watch](https://iblockspam.com/free-monitoring) checks your public SPF, MX, DMARC and MTA-STS records weekly and emails you when one changes; it needs no account.

Browse our other [SPF, DKIM and DMARC guides](https://iblockspam.com/blog/topic/authentication).

## Frequently asked questions

### What does SPF stand for in email?

Sender Policy Framework. It's defined in RFC 7208, published in April 2014, which replaced the earlier experimental RFC 4408. The framework lets a domain owner publish, in DNS, which servers may use the domain in the SMTP MAIL FROM and HELO identities, so receivers can check each connecting server against that list.

### Does SPF check the From address that people see?

No. SPF checks the envelope sender, the MAIL FROM address used during the SMTP conversation, which often appears as Return-Path. The From line in the mail client can be a different domain entirely. DMARC closes that gap by requiring the SPF-checked domain to align with the visible From domain.

### What happens to an email that fails SPF?

It depends on the receiver. RFC 7208 sets no required handling: a receiver may reject a fail, mark it, or simply record the result and let DMARC, DKIM and reputation decide. A softfail should not be rejected on that result alone. A PermError usually means the record itself is broken.

### How many SPF records can a domain have?

One. RFC 7208 says a domain must not publish more than one record starting with v=spf1, and receivers return PermError if they find two. Merge every sending service into a single record. Each subdomain that sends mail needs its own record, because SPF is checked for the exact domain.

### Is SPF enough to stop spoofing of my domain?

No. SPF only protects the envelope sender, and an attacker can pass SPF with their own domain while showing yours in From. You need DKIM and a DMARC policy of quarantine or reject to stop exact-domain spoofing, plus inbound filtering for lookalike domains, which SPF can't touch.

## Sources

- [RFC 7208: Sender Policy Framework (SPF) for Authorizing Use of Domains in Email](https://www.rfc-editor.org/rfc/rfc7208.html)
- [RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC)](https://www.rfc-editor.org/rfc/rfc9989.html)
- [Microsoft Learn: Set up SPF to identify valid email sources for your Microsoft 365 domain](https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure)
- [Google Workspace Admin Help: Set up SPF](https://knowledge.workspace.google.com/admin/security/set-up-spf)
- [M3AAWG Email Authentication Recommended Best Practices (September 2020)](https://www.m3aawg.org/sites/default/files/m3aawg-email-authentication-recommended-best-practices-09-2020.pdf)
- [Gmail Help: Email sender guidelines](https://support.google.com/mail/answer/81126)

## Free tools for this guide

- [SPF Checker](https://iblockspam.com/tools/spf-checker): Count real DNS lookups, find PermErrors, loops and risky "all" settings.
- [SPF Record Generator](https://iblockspam.com/tools/spf-generator): Build a valid SPF record from your mail providers, with a DNS lookup count.
- [DMARC Checker](https://iblockspam.com/tools/dmarc-checker): Check your policy, reporting and the safe path from p=none to reject.
- [Email Health Check](https://iblockspam.com/tools/email-health-check): Grade your domain's MX, SPF, DKIM, DMARC and transport security in one scan.

---

Source: iBlockSpam, https://iblockspam.com/blog/what-is-spf (this is a Markdown copy; the HTML page is canonical). Quote with attribution and a link. Site index for AI assistants: https://iblockspam.com/llms.txt