What is an SPF record? One record for every service that sends as your domain

What is an SPF record? It is one DNS TXT record, starting with v=spf1, that lists the servers allowed to send email for your domain, so receiving mail servers can spot forgeries. Its standard is RFC 7208, published by the Internet Engineering Task Force (IETF) in April 2014.

At a mid-size or large company, the hard part is the list: payroll, billing, the customer system, the help desk and marketing email all send as your domain, and all must fit in one record within 10 DNS lookups. For how SPF works with DKIM and DMARC, see our guide to DMARC policy not enabled.

How does an SPF record work?

Every message has two sender addresses: the From address people see, and the envelope sender (the MAIL FROM or bounce address) used during delivery. SPF checks the envelope sender.

The receiver looks up that domain's SPF record and compares the sending server's IP address with its terms, left to right. The first match decides the result: pass, fail, softfail or neutral. No match means neutral.

Mail can pass SPF for the sender's own domain while showing a different identity in the From line. Tying SPF to the visible From address is DMARC's job.

How do you read an SPF record line by line?

An example company record (all names and addresses are reserved for documentation):

example.com.  IN  TXT  "v=spf1 ip4:192.0.2.10 ip6:2001:db8:1::/48 include:_spf.mailhost.example include:spf.billing.example ~all"

• v=spf1 marks an SPF record.
• ip4:192.0.2.10 and ip6:2001:db8:1::/48 allow servers the company runs itself.
• The two include terms check the email platform's and billing system's records; a pass there is a pass here. The standard admits the name "was poorly chosen": an include uses the other record's result, not its contents.
• ~all softfails every other server: probably not authorized.

Part	What it means	Example	Lookups and notes
v=spf1	Version, always first	v=spf1	Exactly this text
ip4	IPv4 address or range	ip4:192.0.2.0/24	None
ip6	IPv6 address or range	ip6:2001:db8::/32	None
a	Addresses a host name points to	a:relay.example.com	1
mx	The domain's inbound mail servers	mx	1; only if they also send
include	Another domain's SPF result	include:_spf.mailhost.example	1, plus every lookup inside it
redirect	Another domain's record, if nothing here matched	redirect=_spf.example.com	1; ignored alongside all
-all	Every other server fails	v=spf1 -all	Domains that send no mail
~all	Every other server softfails	~all	Not grounds to reject on its own
?all	Neutral, no statement	?all	Treated like no record
+all	Every server passes	+all	Anyone can send as you

The sign before a term is its qualifier: + pass (the default), - fail, ~ softfail, ? neutral. Skip the ptr term, which the standard says "SHOULD NOT be published".

How do you list every service that sends as your domain?

The standard calls this "not just a simple technical exercise". The National Institute of Standards and Technology (NIST), in its trustworthy email guide, SP 800-177 Rev. 1, warns of sending servers "not known to higher-level management" and outside firms that send for you.

CISA's guidance under Binding Operational Directive 18-01 says to start with "the most critical services that you know send on your behalf," such as alerts and monitoring, payroll and HR systems, and invoicing. Then add the email platform, the customer system, the help desk, marketing email, e-signature tools and website forms.

For each, record its owner, the domain it uses as the envelope sender, and whether it signs with DKIM for your domain. If a service uses its own envelope domain, receivers check its SPF record, not yours, so it needs DKIM for your domain or a bounce subdomain under yours.

Expect gaps. The current DMARC standard, RFC 9989, notes that "a Domain Owner can overlook a server here or be unaware of a third-party sending agreement there." DMARC aggregate reports show what you missed. The inventory is also item 2 on our email security checklist for IT and finance teams.

Keep it current: no team turns on a sending service until IT adds it, and when a contract ends, its include comes out. RFC 9989 asks domain owners to "periodically review their SPF records".

Why can a domain publish only one SPF record?

RFC 7208 says a domain name "MUST NOT have multiple records" that a check would select. Two records give a permanent error ("permerror") for all your mail. A common cause is a team following a new tool's setup guide and adding a second record. Merge instead: one v=spf1, all the terms, one all at the end. Long records can be split into quoted strings of up to 255 characters, which receivers join without spaces.

The rule applies per name: NIST notes that a subdomain needs its own record. Domains that share senders can point to one central record:

_spf.example.com.  IN  TXT  "v=spf1 ip4:192.0.2.10 include:_spf.mailhost.example ~all"
example.com.       IN  TXT  "v=spf1 redirect=_spf.example.com"
example.net.       IN  TXT  "v=spf1 redirect=_spf.example.com"
www.example.com.   IN  TXT  "v=spf1 -all"

Change the central record and every domain follows; the last line locks a name that never sends.

What is the 10-DNS-lookup limit?

Six terms make the receiver run another DNS query: include, a, mx, ptr, exists and redirect. RFC 7208 says receivers "MUST limit the total number of those terms to 10"; past that, the result is permerror. The ip4, ip6 and all terms cost nothing. The count is "a single global limit for all evaluations," so lookups inside each include count too.

An example (illustrative counts): the email platform's include costs 3 (itself plus 2 inside), billing 1, the help desk 1, a marketing platform 4 and mx 1. That is 10. Add one more include, and mail from services checked after the tenth lookup gets a permanent error.

Also, an include pointing to a domain with no SPF record returns permerror, a common fate of old services' includes.

To stay under:

1. Remove includes for services you no longer use.
2. Use ip4 and ip6 for servers you run, not a or mx, unless their addresses change often.
3. Give high-volume senders their own bounce subdomain, with its own record and its own 10 lookups.
4. Avoid pasting a service's IP addresses into your record. NIST prefers include because it "avoids hard-coding IP addresses in multiple locations"; pasted addresses go stale.

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

For receivers to treat unlisted servers as unauthorized, the standard says the record must end in -all, or redirect to one that does. With ~all, receivers "SHOULD NOT reject the message based solely on this result".

The catch: RFC 9989 warns that some receivers check SPF before DMARC, so -all can get a message rejected even when an aligned DKIM signature would have passed DMARC, and that rejection never reaches your DMARC reports. NIST suggests ~ or ? instead of - when senders can't be listed with certainty.

A workable rule:

• Domains that send no mail: v=spf1 -all, "a well-established best practice" in the standard's words.
• Sending domains, while you're still finding senders: ~all.
• Sending domains with DMARC at quarantine or reject: ~all is enough for DMARC, which needs an SPF pass and treats softfail and fail alike; -all adds the early-rejection risk.

How do you test an SPF record?

1. Look it up with dig +short txt example.com or nslookup -type=txt example.com, and confirm exactly one line starts with v=spf1.
2. Count the lookups, including those inside each include, and leave room under 10.
3. Send a test from each service to a mailbox you control. In the Authentication-Results header, look for spf=pass; smtp.mailfrom shows whose record was checked.
4. Change it safely. NIST suggests lowering the record's time to live (for example, to 300 seconds) before a change and raising it (for example, to 3600) once tested.
5. Read DMARC aggregate reports after every change.

Our free email security check confirms you have exactly one SPF record and shows how it ends.

What are the most common SPF mistakes?

• Two SPF records on one domain
• More than 10 lookups
• Includes left for dropped services
• Ranges too broad: RFC 9989 notes that many publish "extremely broad records containing many extensive network ranges"
• +all, or no all
• Syntax slips: 192.0.2. instead of 192.0.2.0/24, or semicolons, which NIST says are not permitted
• No record on parked and web-only domains

How do SPF, DKIM and DMARC work together?

• SPF names the servers that may use your domain in the envelope sender. Forwarding breaks it, because the receiver sees the forwarder's server.
• DKIM (RFC 6376) signs each message with a key published under your domain. Relays "typically make no substantive change to the message content and thus preserve the DKIM signature," so it usually survives forwarding.
• DMARC checks that SPF or DKIM passed for a domain matching the visible From address, and tells receivers what to do when neither did.

RFC 9989 recommends using both DKIM and SPF, and says a domain at p=reject must not rely on SPF alone. DMARC is often the missing piece: in our October 2026 check of 519 South Florida law firms, 79% had nothing telling inboxes to throw away email faked in their name.

How can Raileon help?

Our free email security check reads your SPF, DKIM and DMARC records from public DNS in seconds, with no sign-up. If they need work, we set up SPF, DKIM and DMARC, then check your real email still gets delivered. On a free 20-minute call with the founder, we list your senders, write the records with whoever runs your email, and plan the move to p=reject.

FAQ

What is an SPF record?

A DNS TXT record, starting with v=spf1, that lists the servers allowed to send email for a domain. Receivers check each sending server against it to spot forged mail.

Can a domain have two SPF records?

No. Two records give a permanent error, so none of the domain's mail can pass SPF. Merge every service into one record with a single all at the end.

What happens when an SPF record goes over 10 DNS lookups?

Any check that needs an eleventh lookup returns a permanent error, so mail from the services listed last can't pass SPF. Remove unused includes, use ip4 and ip6 for your own servers, or move a busy sender to its own subdomain.

Do we need SPF, DKIM and DMARC, or is SPF enough?

SPF alone doesn't protect the From address people see. Use all three: SPF and DKIM show where mail came from, and DMARC ties them to the From address and says what to do with fakes.

Not sure what sends as your domain?

Bring the list you have, even a partial one. On a free 20-minute call, we'll review your SPF record and say what to fix first.

Book a free 20-minute call