MXToolbox can show "No SPF Record found" because it checks the domain you enter, while your ESP checks the domain used in the SMTP return-path, also called MAIL FROM or RFC5321.MailFrom. Those are often not the same domain. So the ESP can be correct that SPF passes for its bounce domain, while MXToolbox is also correct that the visible domain or subdomain you typed has no SPF TXT record.
The fastest way to resolve the mismatch is to inspect a real sent message, find the return-path domain in the headers, then check SPF on that domain, not only the visible From domain. If the ESP uses its own bounce domain, you usually do not need to add the ESP include to your root SPF record. If the ESP lets you use your own branded return-path, then the SPF record belongs on that branded return-path domain.
This is easy to confuse because ESP setup screens often say "SPF is set up" while also recommending an SPF include as a best practice. That recommendation only helps when the domain in your DNS record is actually the domain SPF receivers evaluate. Otherwise it can add unused lookups, create noise during troubleshooting, and authorize sender infrastructure that is not needed for that domain.
The short answer
What is probably happening
Your ESP is probably using an ESP-controlled return-path domain for SPF. MXToolbox is probably checking your visible sending domain, such as example.com or mail.example.com. SPF is checked against the return-path domain used during SMTP, not automatically against the domain people see in the From line.
- Checked domain: The domain typed into MXToolbox has no v=spf1 TXT record.
- ESP domain: The ESP's own bounce domain has the SPF record it needs.
- Branded return-path: If you configured one, SPF should exist on that subdomain.
- Propagation: If the record was added recently, cached DNS answers can lag behind the change.
I would treat the ESP setup page as a clue, not as final proof. The proof is in a real email header and in public DNS. Header data shows which domain SPF was evaluated against. DNS shows whether that domain has an SPF TXT record. When those two pieces match, the MXToolbox result stops being mysterious.
Suped is useful here because it puts DMARC, SPF, DKIM, DNS diagnostics, and source-level authentication results in one place. That makes the workflow concrete: identify the sending source, see the return-path behavior, check whether SPF is passing and aligned, then fix the record only where it matters.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Why the checked domain matters
SPF does not start with the friendly From address that a recipient sees in their inbox. SPF starts with the SMTP envelope sender. In headers, you will usually see it as Return-Path, smtp.mailfrom, envelope-from, or MAIL FROM. If that domain belongs to your ESP, then the ESP's SPF setup can pass even when your own domain has no SPF record.
For example, a marketing email might show news@example.com in the From header, but the bounce address might sit under bounce.esp-mail.net. A plain SPF lookup for example.com will not show the ESP-controlled SPF record because SPF was never supposed to be checked there for that message.
MXToolbox SPF lookup screen showing no SPF record found for a checked domain.
What MXToolbox sees
- Input: The exact domain or subdomain you typed into the lookup.
- DNS result: The public TXT records published at that name.
- SPF answer: No SPF record if no TXT value starts with v=spf1.
What the ESP means
- Sending path: The infrastructure and bounce domain used for the message.
- ESP result: SPF can pass on an ESP domain you never typed.
- Setup label: The platform can report success for its own configured path.
That is why the same organization can see SPF on an old sending subdomain but not on a new one. The old subdomain may have a TXT record that includes several senders. The new subdomain may only have verification TXT records, CNAMEs, or DKIM records, with no SPF record at all. In that case, MXToolbox is accurately reporting the DNS state for the new name.
How to verify the real SPF domain
Send a fresh test email from the ESP to a mailbox you can inspect. Open the raw message source, then search for Authentication-Results and Return-Path. The goal is to identify the domain after smtp.mailfrom, instead of relying on the display From address.
Header lines to inspecttext
Return-Path: <bounce-12345@mail123.esp-example.net> Authentication-Results: mx.google.com; spf=pass smtp.mailfrom=mail123.esp-example.net; dkim=pass header.d=example.com; dmarc=pass header.from=example.com
In that example, SPF was checked against mail123.esp-example.net, not example.com. MXToolbox returning no SPF for example.com would not contradict that header result.
- Send: Use the actual ESP workflow, not a generic test from another system.
- Open headers: Find Return-Path and Authentication-Results in the raw message.
- Identify SPF: Use the domain shown after smtp.mailfrom as the SPF domain.
- Check DNS: Look up the TXT record at that exact domain.
- Check alignment: Confirm whether SPF aligns with the visible From domain for DMARC.
Email tester
Send a real email to this address. Suped opens the report when the test is ready.
?/43tests passed
Preparing test address...
If you want a DNS-only check after finding the right domain, use the SPF checker on that exact return-path domain. For a broader view across SPF, DKIM, and DMARC, use a domain health check.
Common causes
When MXToolbox and an ESP disagree, the cause is usually one of a few specific patterns. I would check them in this order because it keeps you close to the actual message path instead of guessing at DNS.
|
|
|
|---|---|---|
ESP return-path | The ESP uses its own bounce domain. | smtp.mailfrom |
Wrong subdomain | SPF sits on another sending name. | Exact DNS name |
Recent DNS change | Resolvers still have cached answers. | TTL timing |
TXT without SPF | Verification TXT exists, but no SPF. | TXT values |
Multiple SPF records | More than one SPF TXT breaks evaluation. | Record count |
Lookup limit | SPF exceeds 10 DNS lookups. | Include chain |
Typical causes of an SPF lookup mismatch
A common mistake is copying the SPF record from an old domain into a new domain without checking whether every include is still used. Old ESP includes often survive long after the platform has been removed. That wastes DNS lookups and makes SPF harder to reason about.
Do not add every ESP include by default
SPF has a hard 10 DNS-lookup limit. Each unnecessary include pushes you closer to SPF permerror, and it can authorize mail servers that do not need to send for that domain.
- Keep: Includes that match real current sending paths.
- Remove: Includes for tools you no longer use.
- Validate: The return-path domain before changing SPF.
What the SPF record should look like
If your organization sends normal mailbox email through Google Workspace, your organizational domain usually needs an SPF record that includes Google's sending infrastructure. If a marketing ESP uses your own branded return-path subdomain, that subdomain needs the ESP's include. If the ESP uses its own return-path domain, your visible domain's SPF record is not what decides SPF for that ESP's mail.
Example root-domain SPF recorddns
example.com. TXT "v=spf1 include:_spf.google.com ~all"
Example branded return-path SPF recorddns
bounce.example.com. TXT "v=spf1 include:aspmx.pardot.com ~all"
Do not publish two SPF TXT records at the same hostname. If you need to authorize multiple senders at one name, combine them into one record. Keep the record short enough to understand, and test the full include chain after each change.
Combined SPF record exampledns
example.com. TXT "v=spf1 include:_spf.google.com include:esp.net ~all"
If the record is close to the lookup limit, use SPF flattening carefully. Flattening should be managed, because ESP IP ranges change. Suped's hosted SPF workflow is built for that operational problem: manage sender includes without repeated DNS edits, keep lookup counts under control, and see when a source starts failing.
SPF checker
Find SPF syntax issues, lookup limits, and weak records.
?/16tests passed
How this affects DMARC
SPF passing is not the same as SPF aligning. DMARC requires SPF to pass and align with the visible From domain, or DKIM to pass and align with the visible From domain. If your ESP passes SPF on its own return-path domain, that SPF result can be unaligned for DMARC.
Flowchart showing SPF domain checks and DMARC alignment decisions.
That is why a message can be acceptable even when SPF is not doing the aligned work. Aligned DKIM can carry DMARC on its own. This is common with ESPs that sign with your domain but use their own return-path domain. The message can pass DMARC because DKIM aligns, while SPF passes on a different domain or is not aligned.
SPF passes but does not align
The ESP return-path domain has valid SPF, but it is not your visible From domain or a matching organizational domain.
- DMARC: Needs aligned DKIM to pass.
- DNS fix: Adding an include to your root domain does not make SPF align.
SPF passes and aligns
The return-path domain uses your domain or a subdomain that aligns with the visible From domain.
- DMARC: Can pass through SPF alignment.
- DNS fix: Publish SPF on the branded return-path domain.
The practical goal is not to make every checker show every record everywhere. The practical goal is to make the real message pass authentication in the right way, then monitor DMARC reports so you know which sources are aligned, which are only passing DKIM, and which are failing.
Issues page showing top issues, verified sources, unverified sources, and authentication pass rates
When to add the ESP include
Add the ESP's SPF include only when that domain is actually used as the SPF domain for mail you send. That usually means one of two things: your ESP has you publish SPF on a branded bounce subdomain, or your own domain is the envelope sender for that mail stream.
- Add it: The header shows smtp.mailfrom under your domain or branded bounce subdomain.
- Skip it: The ESP always uses its own return-path domain and aligned DKIM handles DMARC.
- Review it: The ESP documentation uses vague wording such as best practice without showing the exact return-path behavior.
- Remove it: The tool is no longer in your stack or the include is never queried by real mail.
The best long-term setup is usually a branded return-path and aligned DKIM, with DMARC monitoring to confirm what is happening in production. A branded return-path gives you more control over authentication and reputation signals, but it also means your DNS must be correct and maintained.
For teams that do not want to keep editing TXT records by hand, hosted SPF can reduce operational friction. In Suped, hosted SPF also ties into monitoring, issue detection, and fix steps, so the SPF record is not treated as a static text blob that everyone forgets until it breaks.
Hosted SPF and SPF flattening drawer showing desired SPF record, hosted include, and DNS setup
A practical fix checklist
Use this checklist before asking IT to add another include. It keeps the request precise and avoids the common pattern where marketing, IT, and the ESP all look at different domains.
What to send to your DNS owner
- Domain: The exact hostname that needs the SPF TXT record.
- Evidence: A header line showing smtp.mailfrom or Return-Path.
- Record: The single combined SPF record to publish.
- Cleanup: Includes for retired senders that should be removed.
- Validation: A test plan using a real ESP send after DNS updates.
If MXToolbox still shows no SPF record after the update, check the exact hostname again. A TXT record at example.com does not apply to e.example.com. A TXT record at bounce.example.com does not apply to example.com. SPF inheritance does not work that way.
Also check whether the DNS change was made as a TXT record, not as a note in an ESP admin screen. ESP verification records, DKIM records, CNAMEs, and site-verification TXT records do not count as SPF unless the value begins with v=spf1.
When a checker and an ESP disagree, the first thing I want is the real message header. Without that, everyone is guessing which domain SPF was checked against.
Suped email authentication note
Views from the trenches
Best practices
Inspect message headers before editing SPF, so the checked return-path domain is clear.
Keep one SPF record per hostname and remove unused ESP includes during sender reviews.
Use branded return-path domains when the ESP supports them and DMARC alignment matters.
Common pitfalls
Checking the visible From domain often misses the ESP return-path domain used for SPF.
Copying old SPF records can preserve retired senders and consume scarce DNS lookups.
Adding an ESP include to the root domain will not make SPF align if it is unused.
Expert tips
Compare old and new sending subdomains to spot missing TXT records and stale includes.
Ask for the exact hostname and full SPF string when handing DNS changes to IT teams.
Treat ESP setup status as directional until a live email header confirms the result.
Marketer from Email Geeks says MXToolbox can be checking a different domain than the ESP, especially when the ESP controls the SPF return-path domain.
2023-04-11 - Email Geeks
Marketer from Email Geeks says a real campaign header should be inspected because Authentication-Results shows the domain used for the SPF evaluation.
2023-04-11 - Email Geeks
What I would do next
If MXToolbox shows no SPF record, do not assume the ESP is wrong and do not blindly add another include. Start with a real email header. If SPF is passing against an ESP-owned return-path domain, MXToolbox is simply checking a different name. If your own branded return-path is supposed to be in use, publish or fix the SPF record at that exact hostname.
For ongoing management, Suped is the stronger practical choice for most teams because it connects the DNS record, the real sending source, and the DMARC result. That matters more than a one-off lookup, because SPF problems usually come back when teams add an ESP, retire a sender, migrate a subdomain, or hit the lookup limit.
