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

Key findings

• Domain discrepancy: Many ESPs manage SPF records on their own sending domains (return-path or Mail From), not necessarily on your primary From domain, which is what MXToolbox usually checks.
• Header inspection: To verify which domain SPF is being validated against, examine the email headers (e.g., in Gmail's 'Show Original' view) for the authentication-results section.
• DNS issues: Sometimes, the problem is a DNS configuration error, where the SPF TXT record for your domain isn't correctly published or propagated.
• Return-path vs. From: SPF is checked against the return-path domain (RFC 5321.MailFrom), not the visible From address (RFC 5322.From). Understanding this distinction is key.
• ESP recommendations: While some ESPs handle SPF automatically, they may still advise adding an SPF record to your own domain as a best practice for your benefit, even if it's not strictly necessary for their default sending methods.

Key considerations

• Verify SPF record on your domain: Ensure your DNS includes a TXT record with the v=spf1 tag, including all legitimate sending sources (e.g., your ESP's include: mechanisms and your own inbox provider like Google Workspace or Microsoft 365).
• Understand ESP's SPF handling: If your ESP handles SPF on their domain, your emails may still pass DMARC via DKIM alignment, but having SPF on your own domain (especially if you control the return-path) provides better control and transparency. Learn more about DMARC, SPF, and DKIM.
• Check return-path: Always check the SPF record for the return-path domain (also known as envelope from or smtp.mailfrom) when troubleshooting SPF issues, as this is the domain SPF actually authenticates against. An ultimate guide to SPF records can provide more context.
• Avoid unnecessary includes: Do not add SPF includes for ESPs that handle SPF on their own return-path domain, as it can waste lookups (SPF has a 10-lookup limit) and potentially expose your domain to security risks. More on why SPF resolution fails.

Key opinions

• ESP-managed SPF: Many ESPs claim to handle SPF automatically, meaning they use their own domain in the email's return-path, which SPF validates against. This can lead to the belief that no action is needed from the marketer's side for their own domain.
• Best practice vs. necessity: ESPs often suggest adding an SPF record for your own domain as a best practice, even if their systems pass SPF automatically via their own domains. This creates ambiguity for marketers.
• Confusion with tools: Marketers are often confused when tools like MXToolbox don't show an SPF record for their domain, even when their ESP assures them everything is set up. This stems from the tools checking the main domain, not the ESP's bounce domain.
• Impact on deliverability: Some marketers believe that even if DMARC passes via DKIM, an SPF failure (or lack of an SPF record on their primary domain) can still negatively impact deliverability.

Key considerations

• Verify your own domain's SPF: Despite ESP assurances, it is often beneficial to have a correct SPF record for your own sending domain, especially if you also send emails directly from your Google Workspace or Microsoft 365 inbox.
• Check email headers: Always review the authentication-results in raw email headers to understand which domain SPF (and DKIM) is being evaluated against for each specific email send. This can help troubleshoot why emails aren't appearing in the inbox.
• Align SPF for your benefit: While ESPs set up SPF for their benefit (to authorize their servers), you should also ensure your SPF record includes all senders that use your domain in the From address. This practice is detailed in guides on SPF record basics.
• Review old records: Periodically check and clean up your SPF records, removing any includes for ESPs or services you no longer use, like old Mailchimp entries that are no longer needed for SPF. More on why you shouldn't add Mailchimp to your SPF record.

Key opinions

• Return-path domain matters: Experts consistently point out that SPF is checked against the return-path (RFC 5321.MailFrom) domain, not the human-readable From address. If the ESP uses its own domain for the return-path, MXToolbox querying your primary domain will show no SPF.
• DNS records: A common reason for SPF not showing up is an actual absence or misconfiguration of the TXT record in DNS for the domain being queried.
• Unnecessary includes: Adding SPF includes for ESPs that manage their own return-path domain is often considered unnecessary, as it wastes lookups and could pose security risks.
• Best practice for control: While an ESP might handle SPF, having your own domain in the return-path and its corresponding SPF record is considered a best practice for greater control over your sender reputation.

Key considerations

• Prioritize DKIM alignment: For ESPs that use their own return-path domains (like Mailchimp), DKIM authentication with your domain in the d= tag is crucial for DMARC alignment, making SPF less relevant for your primary domain in such cases. This concept is explored in detail on Spam Resource.
• Check live DNS: Use tools like host -tTXT [domain] or dnsviz.net to confirm the presence and correct formatting of your SPF record directly from DNS, as external tools may sometimes cache old results or query different servers. You can learn more about why MXToolbox SPF scores differ.
• Review DMARC implications: If SPF fails but DKIM passes and aligns, DMARC will still pass. However, a consistent SPF failure (even with passing DKIM) can still be a signal to receiving servers. Understand why Google Postmaster Tools might show lower DMARC percentages.
• Consider security risks: Adding unnecessary SPF includes can increase your domain's attack surface. If an included ESP's infrastructure is compromised, attackers could potentially send emails purporting to be from your domain. This is an important consideration for SPF lookup limits and security.

Key findings

• SPF record format: SPF records are published as TXT records in DNS, starting with v=spf1, specifying authorized sending IP addresses and domains via mechanisms like a, mx, ip4, ip6, and include mechanisms.
• Authentication target: SPF primarily authenticates the domain found in the email's Mail From address (also known as Return-Path or envelope sender, RFC 5321). This is distinct from the human-visible Header From domain (RFC 5322).
• DNS lookup limit: RFC 7208 (which updates RFC 4408 for SPF) specifies a maximum of 10 DNS lookups when evaluating an SPF record. Exceeding this limit results in a PermError (permanent error), which can cause emails to be rejected or marked as spam.
• Depreciated record type: While RFC 4408 initially allowed SPF records as a dedicated SPF record type, RFC 7208 depreciated this, stating that SPF records MUST be published as TXT records only.

Key considerations

• Correct DNS entry: Ensure your SPF record is published as a TXT record, not a deprecated SPF record type, to ensure compatibility with modern mail servers and verification tools. Mailgun's guide on SPF records can assist.
• DNS propagation time: After setting up or updating an SPF record, allow for DNS propagation time (typically a few hours, but can be up to 48 hours) before expecting tools to show the updated record. This is a common factor in perceived setup issues.
• Consolidate SPF records: If using multiple ESPs, consolidate all include mechanisms into a single SPF TXT record to avoid exceeding the 10-lookup limit. For specific guidance, see SPF alignment best practices.
• Distinguish RFC 5321 from RFC 5322: Understand that SPF validates the RFC 5321 Mail From domain. If your ESP uses its own domain here, your Header From domain's SPF record won't be checked for that specific email. This is crucial for what RFC 5322 says versus what actually works.