Why does MXToolbox not show my SPF record even though my ESP says it is set up?

Email marketer from Email Deliverability Blog shares while not directly related, DMARC policies rely on SPF and DKIM. If your DMARC policy is set to `p=reject` or `p=quarantine`, emails failing SPF checks might be blocked or sent to spam, even if your ESP says SPF is configured. In which case MXToolbox will not display the record.

Email marketer from Email Geeks explains that since the user uses Google, they should also have include:<http://_spf.google.com|_spf.google.com> in the SPF record. They suggest copying the record from the old domain, removing anything not currently used, adding the google record, and putting in the new domain.

Email marketer from Quora responds that it could be a propagation issue. DNS changes can take up to 48 hours to fully propagate across the internet. Wait a bit, then try again.

Email marketer from LinuxAdmin Forum shares some DNS providers have a very high TTL (Time To Live) set for DNS records. If the TTL is high, changes to your SPF record may take a long time to show up in tools like MXToolbox.

Email marketer from Reddit shares if you're using a shared IP address with your ESP, the SPF record might be managed by the ESP on their domain, not yours. Therefore, MXToolbox wouldn't show an SPF record for your specific domain.

Email marketer from Email Geeks explains that the ESP is likely controlling the SPF domain to be one of their own, instead of using the domain the user checked on MX Toolbox.

Email marketer from Email Geeks suggests checking headers for smtp mail.from to see what domain and to see what domain(s) are dkim signing look for d= and there might be more than one signature and to add the Google include to get your org domain spf record started.

Email marketer from Email Marketing Forum responds that the SPF check happens on the return-path (also known as MAIL FROM or envelope sender), not the visible From: address. Your ESP might be using a different domain for the return-path, which is why you don't see the SPF record when checking your From: domain.

Email marketer from Email Geeks shares the DNS record for the new domain shows no SPF record.

Email marketer from StackExchange answers that you should ensure you're checking the correct domain. It's possible you're checking the wrong domain name or subdomain in MXToolbox. Double-check the domain you're querying against the one your ESP is using.

Email marketer from Email Marketing Tips Blog responds to ensure your SPF record is at the root domain and not a subdomain. While subdomains can have their own SPF records, email is often sent from the root domain, so the SPF record needs to be there.

Email marketer from Webmaster Forum explains that make sure the SPF record is a TXT record. Some systems incorrectly create it as an SPF record (which is now deprecated). MXToolbox specifically looks for TXT records.

Email marketer from Email Geeks shares if the ESP says SPF is okay, but MXToolbox says you don't have one, that ESP is referencing their domain instead of yours. They suggest reviewing DNS records for the v=spf1 record and validating the correct SPF "include:" record is set up for the ESP, and provides the Pardot SPF record: include:<http://aspmx.pardot.com|aspmx.pardot.com>.

Email marketer from Email Geeks advises that if the ESP handles SPF, you don't need to manually add it to your DNS. It's generally not advised to add extra includes that will never be checked against to your SPF because you're wasting lookups and you're potentially allowing IPs you have no control over to send emails as you.

Email marketer from Email Geeks shares that "Best practice" is to have your own domain in the return=path where the SPF is checked to lower the amount of data points that go into the virtual reputation measure of each email you send.

Email marketer from SuperUser explains that if your ESP is handling the return path you would not need to have the SPF record on your domain, so that may be why it is not displayed on MXToolbox.

Email marketer from Cloudflare Community mentions you should never have multiple SPF records for the same domain. This is invalid and can cause issues with SPF validation. Combine them into a single record.

Expert from Word to the Wise explains that the SPF record that matters is the one associated with the Return-Path domain, also known as the envelope sender. It's possible your ESP is setting the Return-Path to a domain they control, and that's where the SPF record exists, not on your sending domain. So check the SPF record of the return-path not the from domain.

Expert from Spam Resource explains to check that there are no typos or other DNS configuration errors for the domain in question. Many times ESPs provide guidance, but the final configuration step is still on you and there can be mistakes that are hard to catch without digging in.

Documentation from Microsoft explains for Office 365, you need to authorize Microsoft's servers using `include:spf.protection.outlook.com`. If this is missing, MXToolbox might not recognize your SPF setup as valid for Office 365 sending.

Documentation from IETF explains that you should check if your SPF record exceeds the 10 DNS lookup limit. MXToolbox will generally not validate if it finds an error in the SPF record. You can avoid issues by simplifying your SPF record.

Documentation from Google explains that for Google Workspace, you need to add Google's SPF record (`_spf.google.com`) to your domain's SPF record. If you don't, MXToolbox will not find it because it's not properly configured to authorize Google's servers to send email on your behalf.

Documentation from MXToolbox Support explains that one of the common reasons MXToolbox doesn't display an SPF record is a syntax error in the record itself. Even a small typo can prevent the record from being recognized. Ensure you check for spaces, extra characters and semi colons.