SPF – which servers may send mail in your name

SPF lists the servers allowed to send mail for your domain. Here is what the record contains, why the ten-lookup limit breaks good records, and what each SPF finding means.

SPF is a guest list. In your domain's DNS you publish the servers that may hand over mail with your address on it. A receiving server compares the server that actually delivered the message against your list, and your record tells it how seriously to take a sender that is not on it.

The list is only useful if it is complete: mailbox provider, newsletter tool, shop, invoicing software, website contact form, helpdesk. Every path you forget becomes a real message that fails the check; every path you leave on the list after you stopped using it is a door nobody watches.

What the record looks like

SPF is a single TXT record on the domain itself.

example.com.  TXT  "v=spf1 include:spf.protection.outlook.com include:servers.mcsv.net ip4:198.51.100.25 ~all"

The ending decides what the record is worth. -all means everything unlisted is a forgery – correct once your list is complete. ~all is the sensible starting point. ?all says nothing at all and is worth no more than an empty record. +all declares every server on earth allowed.

Only one SPF record is allowed per domain, and that rule is stricter than it sounds: two records that are each perfectly correct add up to no protection, because receivers discard SPF entirely when they find two. It is the most common way a carefully built record stops working – somebody adds a service and publishes a second record instead of editing the first.

The ten-lookup limit, with real numbers

An SPF record may cost a receiving server at most ten DNS lookups. Each include:, a, mx, ptr, exists and redirect costs one – including the ones inside the records you include. Past ten, the result is not "mostly fine": it is a permanent error, and a record in error is treated as if it did not exist.

None of this is visible in your own record. Four includes look tidy; the cost sits in other people's records and moves when they change theirs. Measured against DNS on 16 September 2026:

The last line is not a typo. One include can spend the whole budget on its own, and the owner who added it did nothing wrong. It is also why a record that worked for two years can fail one Tuesday without anybody touching it.

The way out is fewer services on the main domain: drop includes you no longer use, and move bulk sending to a subdomain such as news.example.com, which gets its own budget of ten. DMARC still lines up, because relaxed alignment is the default.

How to set it up

Edit the TXT record at the provider that hosts your DNS – not always the one hosting the website. These building blocks were verified against DNS on 16 September 2026:

Step by step at GoDaddy

1. Sign in, open My Products, then DNS next to the domain.
2. Search the TXT records for one starting with v=spf1. If there is one, edit it – never add a second.
3. Set the name to @, the domain itself.
4. Build the value in one line: v=spf1, one include: per sending service, then ~all.
5. Save, and allow up to an hour for the change to spread.
6. Run the check again and look at the lookup count, not only at the colour.

The same six steps apply at Namecheap (Advanced DNS), Cloudflare (DNS, Records) and 123-reg (Manage DNS). The wording changes, the job does not.

The findings in detail

No SPF record

No TXT record on your domain begins with v=spf1. There is no list at all, so recipients cannot tell your mail server from anyone else's: forgeries pass unmarked, and your own mail is filed as spam more often, because a domain without authentication looks careless to a filter.

What to do: list every system that sends with your address in the From line, build one record from it, end that with ~all. Once the DMARC reports show nothing legitimate failing, -all is the finishing touch.

Multiple SPF records

More than one TXT record on your domain starts with v=spf1. Each may be perfect on its own; together they are worth nothing, because the standard tells receivers to treat a domain with two SPF records as a permanent error and skip SPF entirely.

What to do: merge them into one, keep exactly one closing all, delete the rest. Then check the lookup count – merged records often land just over the limit.

SPF exceeds the lookup limit

Following your record the way a receiving server does, we counted more than ten DNS lookups. Past the limit the evaluation ends in an error and the record is ignored, so SPF fails for your own mail – and takes DMARC with it whenever DKIM is not signing.

What to do: drop includes for services you have stopped using. If everything is genuinely in use, move bulk sending to a subdomain with its own record.

SPF ends in +all

Your record ends in +all: every server on the internet may send in your name. Anybody can forge your address and pass SPF doing it. The record is syntactically perfect and protects nothing – worse than no record, because it does not even look suspicious to a filter.

What to do: replace +all with ~all today. There is no legitimate use for it on a domain that sends real mail.

SPF ends in ?all

Your record ends in ?all – neutral, meaning no statement about servers that are not listed. Receivers do exactly what you told them: nothing. The record is worth what an empty one is worth, while leaving the impression that SPF is handled.

What to do: change ?all to ~all, watch the DMARC reports for two to four weeks, then move to -all.

SPF without a closing mechanism

The record has no all mechanism and no redirect=. A receiver that worked through your list without a match has no instruction and defaults to neutral, so the list does nothing for the mail that matters – the mail you did not send.

What to do: add ~all at the end, and make sure it really is last. Mechanisms after all are never evaluated, so an include behind it is silently dead.

SPF uses ptr

Your record contains a ptr mechanism, which asks receivers to resolve the sending address backwards and check the resulting name. It is slow, easy to mislead, and discouraged by the standard for years: some providers skip it, others treat it as an error and drop the record.

What to do: delete the term and name the servers properly – ip4: or ip6: for a fixed address, a or mx when they already appear in your DNS, or the provider's include:.

SPF points nowhere

More than two names in your record returned no SPF record at all – a service shut down, a provider that moved domain, a typo present since the beginning. From three such void lookups on, strict receivers treat the whole record as faulty, so the dead entries take the live ones with them.

What to do: remove the includes that lead nowhere. They cost lookups and can do nothing useful. If you are unsure whether a service is still in use, the DMARC reports say so.

Very long SPF record

Your record is longer than 450 characters. DNS splits long TXT records into 255-character chunks, which is normal, but panels differ in how they split and reassemble them and some drop a chunk. Length is not itself a fault; it is a reliable sign the record has grown past what anyone still understands.

What to do: treat it as a prompt to clear out, and move long ip4: lists to a subdomain record. After a DNS migration, check that the record still arrives in one piece.

SPF refers back to itself

Following your includes we reached a domain we had already visited – two domains including each other, or a record including its own domain. Evaluation stops there with an error and the record is discarded. It often appears after a merger, when two records are pointed at each other so that "both work".

What to do: untangle the nesting. Decide which domain holds the real list and let the other include it, in one direction only.

Included domain has multiple SPF records

One of the domains you include publishes more than one SPF record itself. The one-record rule applies at every level, so that branch ends in an error, and depending on how strict the receiver is, your record goes with it. The fault is not in your DNS and cannot be fixed there.

What to do: the finding names the domain. If it is yours, merge its records. If it belongs to a service provider, send them the finding – it affects all their customers and is usually fixed within days.

Unknown term in the SPF record

Your record contains a term the standard does not define – often a typo such as includ:, or a fragment copied from a different kind of record. Lenient receivers skip it; strict ones declare the whole record faulty. SPF then fails for some recipients and passes for others, which is hard to diagnose from the inside.

What to do: the finding names the term. The standard defines all, include, a, mx, ptr, ip4, ip6, exists, plus redirect and exp. Anything else comes out.

Frequently asked questions

Does SPF alone protect my domain from forgery?

No. SPF checks the technical envelope sender, which recipients never see. A forger can pass SPF with their own domain and still display your address in the From line. Only DMARC ties SPF and DKIM to the address the recipient reads.

Can a subdomain have its own SPF record?

Yes, and it is often the best move. A subdomain does not inherit its parent's record, so news.example.com carries its own budget of ten lookups. Bulk sending belongs there; the main domain keeps a short record for everyday mail.

How long does a change take to work?

The old record stays cached for as long as its TTL says – commonly an hour, sometimes 24. Until then some receivers still see the previous version. Lower the TTL a day before a bigger move if your panel allows it.

Is the strict ending -all risky?

Only if the list is incomplete, because a forgotten sending path then turns into mail that never arrives. Run ~all first, read the DMARC reports until they show nothing but your own systems, then switch.