SPF records: syntax, examples and common mistakes

What an SPF record does, and what it does not

SPF (Sender Policy Framework, RFC 7208) lets you publish which servers may send mail for your domain. When a message arrives, the receiving server looks up the SPF record for the domain in the envelope sender (the MAIL FROM or return-path address) and checks whether the sending IP address is on the list.

SPF has three limits worth knowing before you rely on it:

• It checks the envelope domain, not the From address people see. A criminal can pass SPF for their own domain while showing yours in the From line. DMARC closes that gap by requiring the SPF domain to align with the visible From domain.
• It breaks when mail is forwarded, because the forwarding server is not in your record. DKIM survives forwarding better, which is why you need both.
• It covers one domain or subdomain at a time. The record for example.co.uk does not cover news.example.co.uk; each subdomain that sends mail needs its own.

SPF on its own does not stop anyone spoofing your domain. It is one input to DMARC, explained on our email authentication hub and in our sister site's DMARC guide.

SPF record syntax

Every SPF record starts with v=spf1, lists the permitted sources (mechanisms) from left to right, and ends with an all mechanism that says what to do with everything else:

Do not use +all, which authorises every server on the internet to send as you. RFC 7208 also asks receivers to limit void lookups (DNS queries that return no answer, often from an include for a service that no longer exists) to two, so dead includes can break SPF as well as waste lookups.

SPF record examples

These examples use example.co.uk and documentation IP addresses. Replace them with your own domain, your own IP addresses and the include values your providers publish:

Publish the record as a TXT record at the domain itself (often entered as @ at your DNS host). Microsoft recommends a TTL of at least 3,600 seconds to avoid DNS lookup timeouts. There is nothing to configure inside Microsoft 365 or the Google Admin console: both say SPF is set at your domain host.

Should SPF end in -all or ~all?

The two biggest mail platforms give different advice:

• Microsoft recommends -all for Microsoft 365 domains, because it also recommends DKIM and DMARC. It notes that DMARC treats both -all and ~all as SPF failures, but that a DMARC policy is effectively ignored for ~all failures when a message has no DKIM signature.
• Google recommends ~all for Google Workspace domains, which tells receivers to treat unlisted senders as suspicious rather than reject them outright.

In practice the choice matters less once DKIM and DMARC are in place, because DMARC then decides what happens to failing mail. A sensible rule is to follow your main platform's advice for active domains, and to use v=spf1 -all for every parked domain. Use ?all only while testing.

The 10 DNS lookup limit

RFC 7208 limits SPF evaluation to ten DNS-querying terms. The include, a, mx, ptr and exists mechanisms and the redirect modifier each count; ip4, ip6 and all do not. Lookups inside an included record count too, so ten include statements can easily mean more than ten lookups. If evaluation goes over the limit, SPF returns a permerror and the message fails SPF.

Ways to get back under the limit:

1. Remove senders you no longer use. Old newsletter tools and retired CRMs are the usual culprits.
2. Move bulk and marketing services to subdomains. Each subdomain has its own record and its own budget of ten lookups, and Microsoft recommends this anyway to protect your main domain's reputation.
3. Replace an include with IP ranges where a vendor publishes a stable, documented set of addresses, and review it regularly. Microsoft says not to do this for Microsoft 365, whose sending IP addresses change frequently.
4. Use hosted SPF. Valimail's Instant SPF answers each query with a record tailored to the sending server, and IRONSCALES DMARC flattens SPF automatically at frequent intervals, so neither is constrained by the limit in the same way.

Google's help page describes the limit as up to ten include tags. Microsoft's is more precise about nested lookups, so count every level when you check a record.

Common SPF mistakes

Most SPF failures come from a handful of errors:

The trailing full stop, include= and stray space errors are the examples Microsoft gives in its own SPF guidance, and Microsoft also notes that two records, or an include that does not resolve, cause a permerror.

Adding third-party senders and gateways

Every service that sends with your domain in the envelope address needs to be covered: add the include or IP ranges given in that provider's documentation. Better still, turn on the provider's DKIM signing with your domain, because DKIM alignment survives forwarding and does not use up SPF lookups.

If your outbound mail is relayed through a secure email gateway, such as Proofpoint Essentials, Symantec Email Security.cloud, Trend Micro's Cloud Email Gateway Protection or Sophos Email in gateway mode, the gateway becomes the server that delivers your mail to the world. Add the SPF value that gateway's documentation specifies, and keep your Microsoft 365 or Google Workspace include only if some mail can still leave directly. API-based products that inspect mail inside the mailbox do not normally send on your behalf, so they usually need no SPF change; check the vendor's documentation for features such as encrypted delivery portals that do send mail.

How to check an SPF record

There are three quick ways to check:

• Look up the record. Any DNS lookup tool or SPF checker will show the TXT record for your domain, and many count the DNS lookups for you.
• Read a message header. Send a message to Gmail, open it and choose More, then Show original; the authentication results show whether SPF passed and for which domain.
• Read your DMARC reports. Aggregate reports list every source sending as your domain and whether each one passed SPF, which is how you find senders the record is missing.

SPF is the first item on our Google bulk sender guidelines checklist, because Gmail now requires it, or DKIM, from every sender.

How we help

Forever Systems can review SPF across every domain you own, count the real lookups, remove dead includes, move bulk senders to subdomains and lock down parked domains, then add DKIM and DMARC so SPF is doing a useful job. If your record keeps outgrowing the limit, we supply hosted options such as Valimail and IRONSCALES DMARC; pricing is confirmed at quote. Contact us for a review of your SPF records.