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

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, 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).

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):

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.

Every mechanism, with copy-ready examples and the mistakes we see most, is covered in SPF record syntax and examples.

What are the SPF lookup limits?

SPF can trigger many DNS queries, so RFC 7208 caps them. 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).

This limit catches large organizations too. In our October 2026 scan of the Tranco top 1,000 domains, 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 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 describes the rewriting workarounds. Our guide to why forwarding breaks SPF and DMARC 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, 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 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, and 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:

The reason for caution is in RFC 9989 section 7.1: 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.

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 require SPF or DKIM from everyone sending to Gmail.
2. Get each provider's documented value. Our SPF records by email provider pages list the exact include for common services, such as Microsoft 365 and 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 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 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.
8. Add DKIM and DMARC. SPF alone doesn't protect the From address.

Our SPF guides

Next steps

1. Run your domain through the 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 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.
5. Get the whole picture at once with the Email Health Check. If you'd like to hear when someone changes your SPF record, iBlockSpam domain monitoring sends drift alerts.

SPF records tend to break when someone adds a service months later. The Free Domain Watch 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.