How to Create an SPF Record (Step-by-Step + Examples)

The limits that break SPF records

These are hard limits from RFC 7208, not guidelines. Exceed them and your record returns permerror, and receivers treat a permerror record as an authentication failure.

Ten DNS lookups. SPF evaluation must not perform more than 10 DNS-querying terms. The terms that count are include, a, mx, ptr, exists, and the redirect modifier. The terms that do not count are all, ip4, ip6, and exp. Critically, the count is recursive: an include: whose own record contains three include: statements spends four of your ten. Adding a fourth or fifth vendor is what usually tips a record over.

Two void lookups. A void lookup is a DNS query that returns either no records or NXDOMAIN. More than two is also a permerror. In practice this means a vendor you stopped using has removed their SPF record while your include: still points at it.

One SPF record per domain. Publishing two v=spf1 TXT records on the same name is a permerror. The receiver cannot choose between them, so it rejects both. When you add a vendor, merge their include: into the existing record. Never publish a second one.

255 characters per string. A single DNS TXT character-string cannot exceed 255 bytes. Longer SPF records are published as multiple quoted strings inside one TXT record, which resolvers concatenate with no space inserted. Most DNS providers handle this splitting for you.

Common issues with SPF records

Why does my SPF record return "permerror" or "too many DNS lookups"?

You have exceeded ten DNS-querying terms. Count recursively, each include: costs one lookup plus whatever its own record spends. Fix it by dropping vendors you no longer use, replacing an include: with the specific ip4: ranges the vendor publishes (those cost zero lookups), or moving a vendor onto a subdomain that sends with its own envelope domain.

Why does my mail fail SPF even though the sender is in the record?

Almost always because SPF is checking a different domain than you think. SPF validates the envelope sender, not the visible From:. Bulk platforms and ticketing systems frequently send with their own bounce domain in MAIL FROM, so SPF authenticates their domain and passes, while DMARC then fails your message for non-alignment. A DMARC report shows which domain was actually checked.

Why did mail break after I added a second SPF record?

Two v=spf1 records on one name is a permerror, and a permerror counts as an authentication failure. This usually happens when a vendor's setup wizard publishes its own record instead of editing yours. Delete one and merge the include: into the survivor.

Why does forwarded mail fail SPF?

Because forwarding changes the delivery path but not the envelope sender. The forwarding server is not in your SPF record, so SPF fails at the final destination. This is expected behaviour, not a misconfiguration you can fix in DNS, and it is precisely why DMARC accepts a DKIM pass or an SPF pass. DKIM signatures survive forwarding, so a properly signed message still authenticates.

Best practices

• Keep the record current. Remove vendors as you stop using them. Stale include: statements burn lookups and cause void-lookup errors.
• Never publish more than one SPF record. Merge, don't append.
• Pair SPF with DKIM and DMARC. SPF alone protects nothing the recipient can see. All three together, as covered in what are DMARC, DKIM, and SPF, are what stop spoofing.
• Monitor rather than assume. DMARC aggregate reports tell you which sources pass and fail. Guessing does not.

Related reading

• What are DMARC, DKIM, and SPF?
• How to understand DMARC reports
• Email deliverability is not set and forget