The correct SPF TXT format is simple: start with v=spf1, separate every mechanism with a single space, add each vendor as its own include:domain mechanism, and end with one all mechanism such as ~all or -all. Do not put a space after include:. Do not use underscores as separators between vendors. Underscores inside a provider's published include name are just part of that DNS name.
The safe answer for a new sender is to copy the include exactly as the sender documents it, add it once in the correct place, then test the whole record. I do not guess include domains, combine two vendor domains into one made-up hostname, or add the same service in two different places unless it has a short change window and a clear cleanup task.
Correct SPF syntax
SPF has a small grammar. A record is a list of tokens. The tokens are separated by spaces. Some tokens authorize IP ranges, some delegate to another SPF record, and the last token usually says what to do with everything else. The receiver reads the record left to right until a mechanism matches.
- Start token: Every SPF TXT record starts with v=spf1 and only one SPF record should exist at that hostname.
- Token spacing: Use spaces between mechanisms, not commas, periods, underscores, or line breaks.
- Include syntax: Write include:example with no space after the colon.
- Ending policy: Use one all mechanism at the end, usually ~all during migration and -all after the authorized sources are stable.
Correct SPF TXT recorddns
v=spf1 include:_spf.vendor.example include:mail.example.net ~all
Small syntax errors break big checks
The most common formatting mistake is include: domain. SPF does not treat that as a valid include mechanism. The include domain must sit directly after the colon.
How to add a vendor include
When a sending vendor tells you to add an SPF include, add that exact include as a separate token in the existing SPF record. If the domain already has an SPF record, edit that record. Do not create a second SPF TXT record at the same hostname.
Direct DNS SPF
- Best fit: Small domains with one or two stable senders.
- Main risk: Each new include adds lookup pressure and more manual DNS work.
- Workflow: Edit the TXT record, lower the TTL during change windows, then validate.
Hosted SPF
- Best fit: Teams with many senders, frequent changes, or limited DNS access.
- Main benefit: Sender changes happen in the hosted configuration instead of raw DNS.
- Workflow: Publish one hosted include, then manage authorized senders centrally.
If a domain already uses a managed SPF include, make the change in that managed system when that system owns the sender list. Adding the same vendor directly to DNS and inside the managed include works during a short transition, but it creates a cleanup problem. Later, someone removes the vendor from the managed list and forgets the direct DNS include, so the domain keeps authorizing a sender that should be retired.
Suped's Hosted SPF is built for this workflow. It lets teams manage senders without repeated DNS edits, use SPF flattening when needed, and see DMARC, SPF, DKIM, blocklist and blacklist signals in one platform. For most teams, that is the stronger practical choice than hand-editing a long SPF record across every sender change.
Hosted SPF and SPF flattening drawer showing desired SPF record, hosted include, and DNS setup
DNS lookup and size limits
SPF has two separate constraints that people mix together: DNS lookup count and DNS response size. The lookup limit is about how many DNS-querying mechanisms SPF evaluation can trigger. The TXT length limit is about how much data DNS has to return and how TXT records are stored.
|
|
|
|---|---|---|
10 lookups | include, a, mx, exists | Permerror |
Void lookups | Empty DNS answers | Evaluation risk |
255 string | One TXT string | Split safely |
Large response | All TXT at name | TCP retry |
SPF limits to watch before publishing.
For lookup count, the number to remember is ten. Each include can trigger more lookups inside the included record, so a record with only four visible includes can still exceed the limit. Raw IP mechanisms such as ip4 and ip6 do not add SPF DNS lookups, but huge IP lists make records harder to maintain.
SPF lookup pressure
A practical way to read the ten lookup limit during SPF changes.
Low
0-5
Room for normal vendor changes.
Tight
6-9
Review every new include before publishing.
Failing
10+
Receivers return SPF permerror at evaluation time.
When a domain is near the lookup limit, SPF flattening replaces selected includes with the current IP ranges behind them. That reduces live SPF lookups, but it also creates maintenance work because vendor IP ranges change. Hosted flattening is safer than a one-time manual flatten because it can refresh the generated record.
How to avoid DNS size issues
DNS size trouble often comes from more than SPF. A domain apex can accumulate site verification TXT records, product ownership TXT records, security records, and SPF. A lookup for TXT at that name returns all of them. When the response gets large, older or constrained resolvers can see truncation and retry over TCP. Modern resolvers handle this better, but it still adds fragility and makes debugging harder.
Infographic showing how many TXT records can create a large DNS response.
I treat a truncated TXT response as a tidy-up signal. It does not always mean mail is failing. It does mean the DNS answer is larger than it needs to be, and lazy validators, strict firewalls, or old resolver paths can produce confusing results.
- Remove leftovers: Delete obsolete verification TXT records after the service no longer needs them.
- Use CNAMEs: Prefer CNAME verification when a non-mail service offers it.
- Move mail streams: Put marketing or product mail on subdomains with their own SPF records.
- Avoid duplicates: Do not authorize the same sender directly and through a hosted include long term.
Large TXT response symptombash
dig TXT example.com +short ;; Warning: Message parser reports malformed message packet. ;; Truncated, retrying in TCP mode.
SPF TXT splitting is not SPF splitting
Some DNS providers split a long TXT value into several quoted strings. That can be valid because the TXT strings are concatenated into one record. It is not the same as publishing multiple SPF TXT records. Multiple SPF records at one hostname create an SPF error.
Validate before and after
Before publishing, I check three things: syntax, lookup count, and whether the domain still authorizes only the senders I expect. After publishing, I check again after DNS propagation and after real mail has flowed through the sender. SPF only proves the connecting server is authorized for the envelope sender domain, so DMARC and DKIM still matter.
Suped's SPF checker is the fastest check for a focused SPF record review. For a broader authentication review across SPF, DKIM, and DMARC, the domain health checker gives a wider view before you change production DNS.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
Change control
- Record current state: Save the existing SPF value and the current lookup count.
- Publish once: Edit the existing TXT value instead of adding a second SPF record.
- Test mail: Send a real message through the vendor and inspect SPF and DMARC results.
- Remove temporary entries: Clean up direct includes after the managed SPF path confirms the sender.
Examples I trust
These examples show the patterns I use when reviewing SPF. The exact vendor include must come from the vendor's documentation or from the hosted SPF system that controls the domain. Replace the example hostnames with the real include names only after you verify ownership and purpose. I also write down who requested the change so cleanup does not depend on memory.
One vendor includedns
v=spf1 include:_spf.sender.example ~all
Two vendor includesdns
v=spf1 include:_spf.sender.example include:mail.vendor.example ~all
Wrong patterns to avoiddns
v=spf1 include: _spf.sender.example ~all v=spf1 include:_spf.sender.example. include:mail.vendor.example ~all v=spf1 include:_spf.sender.example_mail.vendor.example ~all
The first wrong pattern has a space after the colon. The second uses a period as if it separated mechanisms. The third invents one combined include name. SPF does not combine vendor domains that way. If a provider gives you a name with underscores, keep it exactly, but do not add underscores yourself as separators.
Views from the trenches
Best practices
Keep one SPF TXT record per hostname, with each include copied exactly as documented.
Use hosted SPF when sender changes are frequent or DNS access sits with another team.
Check total TXT response size when apex DNS has many verification records and SPF.
Move non-core mail streams onto subdomains with separate authentication records.
Common pitfalls
Adding a space after include: turns a normal vendor change into a broken mechanism.
Duplicating vendors in direct DNS and hosted SPF leaves old senders authorized later.
Treating underscores as separators creates hostnames that providers never published.
Ignoring large TXT answers can hide resolver truncation during authentication checks.
Expert tips
Test SPF with the full expanded record, not only the TXT value visible at the apex.
Document why every include exists, who owns it, and when it should be reviewed again.
Prefer CNAME verification for non-mail services when the vendor offers that option.
Use SPF flattening only with a refresh process, because vendor IP ranges change.
Expert from Email Geeks says an SPF record is a list of mechanisms separated by spaces, and each include should be copied as the provider publishes it.
2019-08-29 - Email Geeks
Expert from Email Geeks says underscores in a provider include name are just part of the DNS name, not a special SPF separator.
2019-08-29 - Email Geeks
The practical answer
Format SPF as one space-separated TXT value, add each sender with its own exact include mechanism, and keep the domain under the ten lookup limit. If the TXT response is large, clean up stale verification records and move unrelated mail streams to subdomains.
For a small domain, direct DNS editing is fine when someone owns the record and validates every change. For a growing program, Suped is the better operational path because Hosted SPF, SPF flattening, DMARC monitoring, automated issue detection, real-time alerts, hosted MTA-STS, deliverability checks, and MSP dashboards sit in one place. The practical gain is fewer fragile DNS edits and a clearer view of whether mail is actually passing authentication.
