Why does MXToolbox not show my SPF record even though my ESP says it is set up?
Published 22 May 2025
Updated 1 Oct 2026
14 min read
Summarize with
Updated on 1 Oct 2026: We clarified how to identify the SPF domain in a live message and distinguish a missing record from an SPF evaluation error.
MXToolbox can show "No SPF Record found" because it checks the domain you enter, while an ESP setup screen often checks the domain used in the SMTP return-path, also called MAIL FROM or RFC5321.MailFrom. Those are often different domains. The ESP can have SPF configured for its bounce domain while MXToolbox correctly reports that the visible domain or subdomain you typed has no SPF TXT record. A live message header confirms whether SPF actually passed.
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 usually happening
An ESP often uses its own return-path domain for SPF, while MXToolbox checks the visible sending domain you enter, 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.
- The domain typed into MXToolbox has no TXT record beginning with v=spf1.
- The ESP's own bounce domain can have the SPF record it needs.
- If you configured a branded return-path, its hostname must resolve to the SPF policy the ESP requires.
- A record saved in an old or unused DNS zone will not appear publicly.
- A recursive resolver can retain an earlier answer until its positive or negative cache period 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's product brings DMARC reports, SPF and DKIM results, DNS diagnostics, and sending sources into one workflow. Identify the sending source, inspect the return-path in a live message, check SPF and 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 uses the HELO identity to construct the MAIL FROM identity.
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
- The input is the exact domain or subdomain you typed into the lookup.
- The DNS result contains public TXT records returned for that name.
- A no-record answer means the lookup found no SPF TXT policy at that name.
What the ESP means
- The sending path uses particular infrastructure and a bounce domain.
- SPF can pass on an ESP domain you never typed into MXToolbox.
- A setup success label can describe a configured path without proving a live message passed.
That is why the same organization can see SPF on an old sending subdomain but not on a new one. The old subdomain has a TXT record that includes several senders, while the new one carries only verification data or 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. Use the domain after smtp.mailfrom rather than 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 the reverse path is empty, inspect the HELO-based SPF result and the derived MAIL FROM identity; a separate HELO pass alone does not establish SPF alignment for DMARC.
- Send through the actual ESP workflow, not a generic test from another system.
- Open the raw message and find Return-Path and Authentication-Results.
- Use the domain shown after smtp.mailfrom as the SPF domain.
- Look up the TXT response at that exact domain.
- Confirm whether a passing SPF result aligns 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.
No record versus SPF errors
A missing SPF policy and a broken SPF policy call for different fixes. A domain lookup showing no SPF record corresponds to SPF "none" when a receiver checks that same identity. Duplicate records and excessive DNS lookups require an SPF record to be present, so they do not explain a genuinely absent TXT policy.
|
|
|
|---|---|---|
No SPF record or spf=none | No applicable SPF policy was found for the checked identity. | Check the exact hostname, CNAME target, and authoritative DNS. |
spf=fail or spf=softfail | A policy was found, but the sending IP was not authorized under its stated policy. | Compare the sending IP with the mechanisms in that policy. |
spf=permerror | The policy cannot be evaluated, often because of duplicate SPF records, invalid syntax, or too many DNS-querying terms. | Inspect the record count, syntax, and include chain. |
spf=temperror | The check encountered a temporary DNS error. | Retry and inspect DNS availability for the queried name. |
Different SPF results require different fixes
MXToolbox's SPF lookup can also flag validation problems after it finds a record. Read the specific result rather than treating every warning as "No SPF Record found".
Common causes
When MXToolbox and an ESP disagree about a missing record, check the actual message path first. Then compare the precise DNS name and the public answer.
|
|
|
|---|---|---|
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. | Resolver cache period |
CNAME return-path | The expected alias or its target is missing or wrong. | CNAME owner and target |
TXT without SPF | Verification TXT exists, but no SPF policy. | TXT values |
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 limit of 10 DNS-querying mechanisms and modifiers during one evaluation. Each unnecessary include uses part of that limit and can authorize mail servers that do not need to send for that domain. Exceeding the limit produces SPF permerror, not a missing-record result.
- Keep includes that match current sending paths.
- Remove includes for senders 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 cached answer expires, find the authoritative nameservers for the relevant DNS zone and query them directly. This separates a record that was never published from a stale answer held by a recursive resolver. Use a trace if the return-path subdomain has its own delegation.
Query the delegated and authoritative DNSbash
dig +trace bounce.example.com TXT dig @ns1.example.net bounce.example.com TXT +noall +answer nslookup -type=TXT bounce.example.com ns1.example.net
- If every authoritative nameserver lacks the record, check the active DNS zone, host field, and saved value. Some DNS panels append the zone name, so entering a full hostname can publish at the wrong name.
- If the record is present authoritatively but absent through a recursive resolver, wait for the cached answer to expire. Negative answers use the zone's negative cache TTL, which can differ from the TXT record TTL.
- If authoritative nameservers disagree, fix zone publication or synchronization before retesting.
- If the branded hostname returns a CNAME, follow its 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"
Publish one SPF TXT record at each hostname that needs a policy. If the ESP specifies a CNAME for a branded return-path, publish that alias instead of a TXT record at the same hostname. Multiple quoted strings inside a single TXT record are still one record; two separate SPF TXT records at the same hostname cause permerror. A domain that never uses its own MAIL FROM identity can publish v=spf1 -all after you verify no legitimate sender uses that identity.
Combined SPF record exampledns
example.com. TXT "v=spf1 include:_spf.mailbox-provider.example include:spf.esp.example ~all"
If you need to authorize multiple senders at one name, combine them into one SPF record and test the full include chain after each change. Use SPF flattening carefully when lookup limits are a real problem, because ESP IP ranges change. Suped's hosted SPF workflow manages sender includes and lookup counts without repeated manual DNS edits, while monitoring shows when a sending 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 a MAIL FROM domain that aligns with the visible From domain, or when DKIM passes with an aligned signing domain. Relaxed SPF alignment compares organizational domains; strict alignment requires the domains to match exactly. 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 pass DMARC even when SPF is not aligned. 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.
SPF passes without alignment
The ESP return-path domain has valid SPF, but it does not have alignment with your visible From domain.
- DMARC needs aligned DKIM to pass in this case.
- 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 aligns with the visible From domain under the configured DMARC alignment mode.
- DMARC can pass through SPF alignment.
- Publish the required DNS setup on the branded return-path domain.
The alignment identity remains the branded return-path hostname even when DNS follows its CNAME to an ESP target. The practical goal is to make real messages pass authentication, then monitor DMARC reports to see which sources have SPF alignment, which rely on DKIM, and which fail.
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 the include when a live header shows smtp.mailfrom under your domain or branded bounce subdomain and the ESP requires it there.
- Skip the include when the ESP uses its own return-path domain and aligned DKIM handles DMARC.
- Review vague ESP guidance against the exact return-path behavior in a live message.
- Remove an include when its sender has been retired and no current sending path uses it.
A branded return-path and aligned DKIM give you two ways to pass DMARC when the ESP supports both. The branded hostname needs correct, maintained DNS, and DMARC monitoring confirms how production mail is authenticated.
For teams that do not want to keep editing TXT records by hand, hosted SPF can reduce operational friction. In Suped, hosted SPF ties into monitoring, issue detection, and fix steps, so sender changes and lookup counts remain visible.
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
- Give the exact hostname that needs an SPF TXT record or ESP-required CNAME.
- Include a header line showing smtp.mailfrom or Return-Path.
- Provide the single combined SPF record when TXT is required.
- Identify includes for retired senders that should be removed.
- Plan a real ESP send after the DNS update to validate SPF and DMARC.
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, start with a real email header before editing DNS. If SPF passes against an ESP-owned return-path domain, the lookup is 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 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.
