Why does MXToolbox not show my SPF record even though my ESP says it is set up?
Published 22 May 2025
Updated 28 Jul 2026
14 min read
Summarize with
Updated on 28 Jul 2026: We added authoritative DNS checks and clarified how SPF TXT records appear for return-path domains after DNS changes.
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 policy belongs on that branded return-path domain, either as a TXT record or through the DNS setup the ESP specifies.
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, its hostname must return the SPF policy the ESP requires.
- Active DNS zone: A record saved in an old or unused zone will never appear publicly.
- DNS cache: A recursive resolver can retain the previous positive or negative answer until its TTL expires.
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 returns an SPF TXT record. When those two pieces match, the MXToolbox result stops being mysterious.
Suped is useful here because Suped's product puts DMARC, SPF, DKIM, DNS diagnostics, and source-level authentication results in one place. The workflow is concrete: identify the sending source, see the return-path behavior, check whether SPF is passing with DMARC alignment, 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 normally 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. When the SMTP reverse path is empty, as it often is for delivery status notifications, SPF evaluates the HELO identity instead.
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 returned for that name.
- SPF answer: No SPF record if the lookup returns no TXT value starting 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 data or may use a CNAME for its branded return-path. Follow any CNAME to its target before deciding the SPF policy is missing. Do not add a TXT record at a hostname that already has a CNAME.
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, Received-SPF, 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.example; 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. If smtp.mailfrom is empty, inspect the SPF result for the HELO identity.
- 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 response at that exact domain.
- Check alignment: Confirm whether SPF has DMARC alignment with the visible From domain.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
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. Check them in this order because it keeps the investigation 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 |
Inactive DNS zone | The change was saved outside the delegated zone. | Authoritative nameservers |
Cached DNS answer | A resolver still has the earlier result. | Previous TTL |
CNAME return-path | The SPF policy is reached through an alias. | CNAME target |
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 for the mechanisms and modifiers that trigger DNS queries during one evaluation. 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.
Check authoritative DNS before waiting
If the SPF TXT record is still not showing after the earlier cached answer should have expired, stop treating the issue as generic DNS propagation. Find the nameservers delegated for the domain, then query each authoritative nameserver directly. This separates a record that was never published from a stale answer held by a recursive resolver.
Query the delegated and authoritative DNSbash
dig NS example.com dig @ns1.example.net TXT bounce.example.com +noall +answer nslookup -type=TXT bounce.example.com ns1.example.net
- Absent from every authoritative nameserver: Check the active DNS provider, zone, host field, and saved value.
- Present authoritatively but absent in a cached lookup: Wait for the prior positive or negative TTL to expire, then query again.
- Different answers across authoritative nameservers: Fix the zone publication or synchronization problem before retesting.
- CNAME returned at the branded hostname: Follow the target and do not publish TXT data at the CNAME owner.
Publish SPF as TXT
SPF version 1 policies are published in DNS TXT records. RFC 7208 discontinued use of the separate SPF resource-record type. An old page or checker that asks for both TXT and SPF record types is giving obsolete advice, so duplicating the policy under the legacy type is not the fix.
What the SPF record should look like
If normal mailbox email uses your organizational domain as its return-path, that domain usually needs one SPF record authorizing the mailbox sending system. If a marketing ESP uses your own branded return-path subdomain, that subdomain needs the ESP's policy. 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.mailbox-provider.example ~all"
Example branded return-path SPF recorddns
bounce.example.com. TXT "v=spf1 include:spf.esp.example ~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.mailbox-provider.example include:spf.esp.example ~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 addresses 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
An SPF pass is not automatically a DMARC-aligned SPF pass. DMARC passes when SPF passes with an RFC5321.MailFrom domain that has alignment with the visible From domain, or when DKIM passes with an aligned signing 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 without alignment
The ESP return-path domain has valid SPF, but it does not have DMARC alignment with your visible From domain.
- DMARC: Needs aligned DKIM to pass.
- DNS fix: Adding an include to your root domain does not create SPF alignment.
SPF passes with alignment
The return-path domain uses your domain or a subdomain that has DMARC alignment with the visible From domain.
- DMARC: Can pass through SPF alignment.
- DNS fix: Publish the required DNS setup on the branded return-path domain.
The practical goal is not to make every checker show every record everywhere. The goal is to make the real message pass authentication in the right way, then monitor DMARC reports so you know which sources have alignment, 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 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.
A durable setup often uses 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.
SPF flattening drawer showing an over-limit record, sender editing, lookup counts, and the hosted record setup
A practical fix checklist
Use this checklist before asking the DNS owner to add another include. It keeps the request precise and prevents the sending team, DNS owner, and ESP from checking 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 published as a TXT record, not only saved as a note in an ESP admin screen. Verification records, DKIM records, and site-verification TXT records do not count as SPF unless the TXT value begins with v=spf1. A CNAME-based branded return-path is different: follow the CNAME target to see the returned SPF policy.
When a checker and an ESP disagree, collect the real message header first. Without it, 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 create alignment 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 to 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 required DNS record at that exact hostname.
For ongoing management, Suped's product connects the DNS record, the real sending source, and the DMARC result. That workflow helps when teams add an ESP, retire a sender, migrate a subdomain, or approach the SPF lookup limit.
