What is an SPF record and why does it matter?

By Dominic LandryAugust 9, 2023Updated September 9, 20269 min read

Ask AI to explain

In brief

If you're involved in managing email deliverability for your tech company, you may have come across the term 'SPF record.' An SPF record, which stands for…

What is an SPF record?

An SPF record (Sender Policy Framework) is a DNS entry that lists which mail servers are allowed to send email for your domain. It's a core piece of email authentication that helps prevent email spoofing and unauthorized use of your domain name. When a receiving server gets a message that claims to come from you, it looks up your SPF record and checks whether the sending server is on your approved list.

SPF is defined in RFC 7208. One important detail: SPF checks the domain in the envelope's MAIL FROM (also called the Return-Path), not the visible From: address a recipient sees. That gap is exactly why SPF alone isn't enough, and why DMARC adds alignment on top of it.

Why are SPF records important?

SPF records matter because email is central to how businesses communicate, and attackers know it. Spam and phishing campaigns routinely forge sender addresses to trick recipients. An SPF record gives receiving servers a reliable way to tell your legitimate mail from a forgery, which protects your domain's reputation and improves the deliverability of the messages you actually send.

How SPF works

SPF lets a domain owner publish a list of authorized sending sources as a single TXT record in DNS. The record uses a small syntax of mechanisms (which sources to authorize) and qualifiers (what to do when a source matches). A receiving server reads the record, evaluates it against the connecting IP address, and returns a result such as pass, fail, or permerror.

A domain must have exactly one SPF TXT record. If two SPF records exist, compliant receivers return a permerror and the check fails, so multiple sources always have to be merged into one record.

SPF record structure and syntax

A typical SPF record looks like this:

v=spf1 include:_spf.google.com ip4:203.0.113.0/24 ~all

It always starts with v=spf1, followed by one or more mechanisms, and ends with an all mechanism that sets the default policy. For a full walkthrough of the syntax, see what is SPF.

Creating an SPF record

Publishing an SPF record for your domain is a straightforward process. Follow these steps to get started.

The six steps to publish an SPF record for your domain.

Identify the authorized email servers and services that send mail for your domain.
Choose the SPF mechanisms and qualifiers that match your sending practices.
Open the DNS management interface for your domain.
Create a new TXT record with your domain name in the "Host" or "Name" field.
In the "Value" or "Text" field, enter your SPF record following the correct syntax.
Save the change and allow time for DNS to propagate.

If you'd rather not hand-build the record, the SPF generator assembles a valid record from your sending sources.

Choosing the right SPF mechanisms

Pick the mechanisms that map to your actual email infrastructure. The commonly used ones are:

ip4: authorizes specific IPv4 addresses or ranges.
ip6: authorizes specific IPv6 addresses or ranges.
a: authorizes the IP address(es) in the domain's A record.
mx: authorizes the IP address(es) of the domain's MX record.
include: pulls in the SPF record of another domain, such as a mail provider.
all: sets the default action for any source that didn't match.

Each mechanism carries a qualifier that decides the outcome when it matches: + (pass, the default), ~ (softfail), - (fail), or ? (neutral). The qualifier on all is the one that matters most. See the FAQ below on ~all vs -all.

Common mistakes to avoid

Overly restrictive records: leaving out a legitimate sender means valid mail gets rejected.
Incorrect syntax: a typo anywhere in the record can cause a permerror.
Omitting the all mechanism: always end the record with an all qualifier so unmatched sources have a defined policy.
Too many DNS lookups: SPF allows a maximum of 10 DNS-querying mechanisms during evaluation (see the FAQ on permerror).

SPF best practices

To keep your SPF record effective, apply these deployment practices.

Checklist of four best practices for deploying an SPF record.

Deployment practices that keep your SPF record effective.

Keep it current: as your email infrastructure changes, update the record to add new senders and drop decommissioned ones. Monitor your delivery logs and run periodic audits to catch drift.
Watch the lookup count: the include, a, mx, ptr, exists, and redirect terms each count toward the 10-lookup limit; ip4, ip6, and all do not. If you're near the limit, consider SPF flattening to collapse nested includes into direct IP ranges.
Use CIDR notation: specify IP ranges (for example ip4:203.0.113.0/24) instead of listing addresses one by one.
Choose the right all policy: end with ~all (soft fail) if the domain sends mail, or -all for a strict "hard fail" only if it sends none. See hard fail versus soft fail for the reasoning.

SPF, DKIM, and DMARC together

SPF is one leg of a three-part authentication stack. DKIM adds a cryptographic signature that proves the message wasn't altered in transit, and DMARC ties SPF and DKIM results to the visible From: domain and tells receivers what to do on failure. Aligning all three is what actually stops domain spoofing: see what are DMARC, DKIM, and SPF for how they fit together.

Troubleshooting SPF issues

When SPF fails, the cause is usually one of a handful of issues:

No SPF record: without one, receivers have no way to confirm your authorized senders.
Syntax errors: a malformed record produces a permerror. Validate it with the SPF checker.
Overly restrictive policy: a record that omits a legitimate sender rejects real mail.
Too many DNS lookups: exceeding 10 lookups returns a permerror and, under DMARC, is treated as a fail.
Propagation delay: DNS changes take time to spread; allow a few hours before assuming an edit didn't work.

To diagnose a problem, inspect the Authentication-Results and Received-SPF headers of a failing message to see whether SPF passed, softfailed, or errored, then confirm the sending IP is actually covered by your record. A DNS lookup tool helps you see exactly what receivers are resolving.

SPF and email deliverability

A correctly published SPF record improves deliverability in three ways: it reduces spoofing by blocking unauthorized senders, it builds a trustworthy sending reputation with receivers, and it helps mailbox providers separate your legitimate mail from spam. Combined with DKIM and DMARC, it forms the authentication baseline that Gmail, Yahoo, and Microsoft now expect from bulk senders, set out in Google's email sender guidelines, Yahoo's Sender Best Practices, and Microsoft's SPF configuration guidance.

Several RFCs govern this stack:

RFC 7208: defines the SPF protocol, its syntax, and its evaluation rules.
RFC 6376: defines DKIM, the cryptographic-signature partner to SPF.
RFC 9989: the current DMARC standard, which builds on SPF and DKIM. It replaced the original RFC 7489 in May 2026.

Note that Sender ID, an older SPF-like protocol, is effectively deprecated and no longer worth deploying.

Conclusion

SPF records are a foundational part of email authentication. A single, well-maintained SPF TXT record tells receivers exactly which servers may send for your domain, which improves deliverability and cuts off the easiest forms of spoofing. Pair it with DKIM and DMARC, keep the lookup count under 10, and review the record whenever your sending infrastructure changes.

Want to see where your domain stands? Check your record with the SPF lookup tool, or get a full picture across SPF, DKIM, and DMARC with the Email Security Score.

Evidence

Sources and further reading

RFC 7208: Sender Policy Framework - the SPF syntax, the MAIL FROM evaluation identity, and the 10-lookup limit.
RFC 6376: DomainKeys Identified Mail - the DKIM signature that complements SPF.
RFC 9989: DMARC - the current DMARC standard that aligns SPF results with the visible From: domain.
Google: Email sender guidelines - Gmail's authentication requirements for bulk senders.
Yahoo Sender Best Practices - Yahoo's matching requirements.
Microsoft: Set up SPF to identify valid email sources - Microsoft 365 SPF configuration.

Questions readers ask

Frequently asked questions

Can I have two SPF records?

No. A domain must publish exactly one SPF TXT record. If a receiver finds more than one v=spf1 record for the same domain, RFC 7208 requires it to return a permerror, which fails the check for all of your mail. When you add a new sending service, merge its include into your existing record rather than creating a second one.

Why does my SPF fail after 10 lookups?

SPF caps the number of DNS-querying terms at 10 per evaluation. The include, a, mx, ptr, exists, and redirect terms each count against that limit; ip4, ip6, and all do not. Exceed 10 and the receiver returns a permerror, which DMARC treats as a failure. Flattening nested includes into direct IP ranges is the usual fix, see fixing SPF alignment for DMARC.

Does SPF survive email forwarding?

Often not. When a message is forwarded, the forwarding server usually becomes the new sender, so the original SPF check breaks even though the mail is legitimate. This is a key reason SPF isn't sufficient on its own: a DKIM signature travels with the message and typically survives forwarding, and DMARC only needs one of SPF or DKIM to pass and align.

What's the difference between ~all and -all?

Both set the default policy for sources not otherwise authorized. -all is a "hard fail" that tells receivers to reject unauthorized mail outright. ~all is a "soft fail" that flags the mail as suspicious but usually still delivers it. Use ~all if the domain sends mail and -all only if it sends none. Once DMARC is enforcing, the two give the same protection against spoofing, so on a sending domain ~all is where the record settles rather than a step toward -all.

Does SPF check the visible "From" address?

No. SPF validates the domain in the envelope MAIL FROM (the Return-Path), not the From: header a recipient actually sees. An attacker can pass SPF for a domain they control while still forging your visible From:. Closing that gap is the job of DMARC alignment.