SPF Record Example: How to Read and Write One Correctly

SPF records look simple enough to write from memory, and that's exactly what causes most of the problems with them. A single missing include, an extra SPF record published by mistake, or a lookup limit quietly exceeded can leave a domain with authentication that looks correct at a glance but fails in practice. Working through a real SPF record example, mechanism by mechanism, is a far more reliable way to understand the syntax than trying to memorize the specification. This also helps identify syntax errors in the current-domain configuration.

Basic SPF Record Syntax

An SPF record is published as a single TXT record at the root of a domain and always begins with v=spf1, identifying the record as SPF version 1. Everything that follows is a series of mechanisms, each specifying an authorized source of mail, followed by a qualifier that determines how strictly a failure to match should be treated. Understanding SPF record syntax also means knowing how each include mechanism, IP range, and terminating mechanism is evaluated.

Mechanism	What It Authorizes	Common Use
ip4 / ip6	A specific IP address or range	Direct mail servers you control
include	All sources listed in another domain's SPF record	Third-party ESPs and CRMs
a / mx	The domain's own A record or mail servers	Legacy or self-hosted mail
all	Everything not matched above	Always the final mechanism

An IPv4 mechanism can use a single authorized IP address, such as ip4:199.1.1.1, or a network expressed with a prefix-length, such as ip4:199.1.1.0/24. The a and mx mechanisms may reference DNS A records and MX records, while spf1 ptr is an older mechanism that is generally best avoided.

A Simple SPF Record Example, Explained

Consider a domain sending mail only through a single email service provider: v=spf1 include:_spf.exampleesp.com -all.

Reading this SPF record example mechanism by mechanism: v=spf1 declares the record version. include:_spf.exampleesp.com tells receiving email servers to also check the referenced SPF record published by the ESP, which lists all of the ESP's authorized sending IP addresses. The final -all applies a hard fail to any source not covered by the include, telling receiving email servers that any mail claiming to be from this domain, but not originating from the ESP's listed infrastructure, should not be trusted. In this example, the mechanism matches only when the sender appears in the included policy, and evaluation ends at the final all mechanism.

A Multi-ESP SPF Record Example

Most organizations don't send exclusively through one platform. A more realistic SPF record example might look like this: v=spf1 include:_spf.exampleesp.com include:_spf.anothercrm.com include:_spf.transactionalmail.com ~all.

Each include here authorizes a different third-party sending source, perhaps a marketing ESP, a CRM handling sales outreach, and a separate transactional email service. Notice the qualifier on this example is ~all, a softfail, rather than the hard fail used in the simpler example, a more cautious choice when a sending setup involves multiple platforms. This is a common approach for email marketing services while the domain owner confirms every legitimate sender.

It's worth flagging the lookup limit here. Each include mechanism typically triggers its own DNS lookup, and SPF specifies a maximum of 10 total lookups. Exceeding this limit causes the entire record to fail evaluation, known as an SPF permerror, regardless of whether the actual sending source would have otherwise been authorized. Nested includes in a referenced SPF record can also consume lookups, so the visible record may not show the full total.

Common SPF Mistakes These Examples Avoid

A few mistakes account for a large share of real-world SPF problems:

Publishing multiple separate SPF records for the same domain, which most receiving servers will treat as invalid, causing SPF to fail entirely. An existing SPF record should be updated rather than adding multiple SPF records to the domain zone file.
Exceeding the 10 DNS lookup limit, often without realizing it, as more third-party services get added over time.
Using a permissive +all or forgetting the all mechanism entirely, which authorizes any source, anywhere, to send mail claiming to be from that domain. SPF qualifiers determine whether an unmatched source receives a pass, softfail, neutral, or hard-fail result.
Forgetting to update the record after switching or adding email platforms, leaving a genuinely used sending source unauthorized. This can cause incoming email checks to produce an unexpected SPF authentication result.
Adding an include mechanism without checking its SPF mechanism syntax or the provider's required include value, which can create an invalid policy even when the overall record looks correct.

Testing Your SPF Record After Publishing

After publishing or updating an SPF record, verification should happen before assuming it's working correctly. Free SPF validation tools can check syntax, confirm there's exactly one SPF record published, and calculate the total DNS lookup count against the 10-lookup limit. They can also verify that the TXT record is visible in DNS and identify problems with A records, MX records, or an incorrectly formatted SPF mechanism.

Beyond syntax validation, sending a genuine test email through each authorized platform and checking the resulting message headers for an SPF result of pass is a useful final confirmation, since it verifies the record works correctly in practice, not just in theory. The receiving email server should show which mechanism produced the explicit result and whether the sending IP was an authorized IP address.

Frequently Asked Questions

Can I have more than one SPF record for a domain?

No. Only one SPF TXT record should exist per domain. If multiple sending sources need to be authorized, they should all be included within that single record, as shown in the multi-ESP SPF record example above. Combining the values into one existing SPF record avoids an SPF permerror.

What happens if my SPF record exceeds the 10 DNS lookup limit?

The entire record fails evaluation with a permerror, which most receiving servers treat as equivalent to a failure, even for sources that would otherwise have been correctly authorized. This is one reason to review every include mechanism and its nested referenced SPF record.

Should I use ~all or -all at the end of my SPF record?

It depends on confidence in the completeness of the record. -all (hard fail) is appropriate once every legitimate sending source is confirmed and included, as in the first SPF record example above. ~all (softfail) is more cautious during initial setup. In either case, the all mechanism should normally be the final, terminating mechanism.

How do I find the correct include value for my email service provider?

Most major ESPs and CRMs publish their required SPF include value directly in their sending or authentication documentation, ready to drop into your own SPF record example. Check the provider's SPF record FAQs and confirm that the value is current before publishing it.

Should SPF be used with DKIM and DMARC?

Yes. SPF is one part of a broader sender policy framework. A dmarc record can use SPF and DKIM alignment results to help receiving servers decide how to handle unauthenticated messages, while ongoing monitoring can help detect configuration errors and insider threats.

Learn how Mailora helps you monitor SPF configuration alongside DKIM and DMARC, so authentication issues like exceeded lookup limits, syntax errors, and incorrect include mechanisms get caught before they affect deliverability.