“No SPF record found” — what breaks, what does not, and the record to publish

A checker told you your domain publishes no SPF record. This page covers what SPF actually controls, the record to publish, the one limit that silently breaks SPF records that look correct, and — the part most pages skip — why SPF on its own does not stop anyone from sending email in your name.

What SPF is

SPF is one TXT record at the root of your domain listing the mail servers permitted to send on its behalf. A receiving server reads it and compares the list against the server the message actually arrived from.

Note the second sentence, because it is the half people miss. A missing SPF record is not only a security gap — it is a deliverability problem for your own mail. Spam filters weigh authentication, and a domain with no SPF record at all is a domain with one fewer reason to be trusted. If your invoices have been landing in customers’ junk folders, this is one of the first things to rule out.

The record to publish

Start from what actually sends mail as you. Almost every business has more than it thinks: the mailbox provider, the website contact form, an invoicing tool, a booking system, a newsletter platform, and sometimes the accountant.

Name:   @            (the root of the domain)
Type:   TXT
Value:  v=spf1 include:_spf.google.com include:servers.mcsv.net ~all

Replace the include: entries with the ones your own providers publish — every serious provider documents theirs. Then the ending, which is the part that decides what the record does:

In our agency sample, 12 of 522 domains (2.3%) publish an SPF record that refuses nobody — a record that exists, passes a “do you have SPF” check, and authorises the internet.

The limit that breaks correct-looking records

An SPF record may trigger at most ten DNS lookups when it is evaluated. Every include:, a, mx, ptr and redirect counts, and each include: counts everything inside it too. Exceed ten and the result is permerror: receivers are entitled to treat the whole record as invalid, so a record you can read and that looks entirely reasonable authenticates nothing.

This is the most common way a business that has done the work still fails. Four or five include: entries is enough to reach the limit, because a single provider include can spend three or four lookups by itself. Our free check counts them for you and tells you the number. If you are over, the fix is to replace the largest include with the specific ip4: ranges it resolves to, or to consolidate providers.

nslookup -type=TXT yourcompany.com
dig +short TXT yourcompany.com

One SPF record per domain. Two v=spf1 records on the same name is a permerror for the same reason — if you are adding a provider, merge its include: into the record you have rather than publishing a second one.

Why SPF alone does not stop somebody sending as you

This is the part worth reading twice, because a great deal of advice implies otherwise.

SPF authenticates the envelope sender — the address the sending server declares in the SMTP conversation. That address is not the one your recipient sees. The From: line displayed in a mail client is a separate header, and a forger is free to put your domain there while using an envelope sender on a domain they control and whose SPF they pass perfectly.

So a message can pass SPF, be entirely legitimate by SPF’s own reckoning, and still show your company in the From line. The check that closes that gap is DMARC, which requires the authenticated domain to match the visible one and tells receivers what to do when it does not.

The practical order is therefore: publish SPF, then publish DMARC, then move DMARC off p=none. SPF without DMARC leaves the forged-From case wide open, and it is the case that costs money.

Every figure on this page is generated from the stored raw measurement files behind our 604-domain study (522 agency-built sites measured 2026-08-20, 83 independent domains measured 2026-08-01), and the quoted finding wording is read out of the running checker at build time. An automated control re-asserts both against this live page on every operating cycle; if either changed and this page did not, it fails. Generated 2026-09-05T23:34:13Z.