Defaults.Exposed › Taisymai › Guides

SPF Failing for Your SaaS Tools? Why It Happens and the Fix Order — Europe Edition (2026)

Paskelbta 2026-07-08

Figures as of 2026-06-29 · methodology v7. Aggregate census data across 261 million graded domains. See how we grade.

When a SaaS tool “fails SPF”, your record is usually not the problem: the mail is failing DMARC alignment, or your include chain has blown SPF’s 10-DNS-lookup limit. 2,119,539 of 138,927,207 SPF-publishing domains sit at 9–10 lookups — one SaaS include from the cliff — according to the Defaults.Exposed census of 261,086,232 domains.

Below: how to tell which of the two problems you have, then the fix order — scan first, find the domain the tool really sends from, switch the vendor to custom-domain DKIM, and only add an SPF include where it genuinely helps — plus the specifics for HubSpot, Salesforce, Mailchimp and SendGrid.

Why does mail from a SaaS tool fail SPF?

Three patterns cover almost every case:

Data as of 2026-06-29.

The bolded row is where most people are standing. Adding include: lines for every tool doesn’t touch it — and each line moves you closer to the second row: at least 797,263 domains have already crossed the 10-lookup limit, and their SPF now returns a PermError that protects nothing. Full numbers in the SPF PermError report.

Which domain does SPF actually check?

Not the one in your From header. Receivers evaluate SPF against the Return-Path domain (the RFC5321.MailFrom, also called the bounce or envelope-from address) — the From header your recipient sees plays no part in the SPF check itself.

This single fact explains most “SaaS SPF failures”. Your marketing platform sends with a Return-Path like [email protected]; SPF is checked against vendor.com and passes cleanly. Then DMARC asks whether that SPF-checked domain matches your From domain. It doesn’t, so the SPF leg of DMARC fails and your dashboard says “SPF failing”. Editing your own SPF record cannot fix that — your record was never consulted.

What’s the fix order?

1. Run the free scan first. It tells you in one pass whether your SPF is missing, duplicated, over the lookup limit or fine, and where DMARC stands — before you touch DNS.
2. Find the Return-Path the tool actually uses. Send yourself a test from the tool and read the Return-Path header (and Authentication-Results) in the raw message. That tells you which row of the table above you are in.
3. Turn on the vendor’s custom-domain DKIM. Every serious SaaS tool offers “domain authentication”: a few CNAME records that let it DKIM-sign as your domain. That signature aligns with your From domain, so DMARC passes via DKIM — durably, and even when mail is forwarded. This is the fix that lasts.
4. Add the vendor’s SPF include only if it uses your return-path — you’ve enabled its custom bounce domain, or it genuinely sends with your domain in the envelope. An include for a vendor that bounces via its own domain buys nothing and spends your lookup budget.
5. Count your DNS lookups before saving. The limit is 10 resolved lookups, includes count recursively, and 2,119,539 domains already sit at 9–10 — the census p99 is 9. Near the edge? Remove includes for tools you no longer use first. Just switched email providers? Check for a leftover second record — two SPF records equals a PermError.
6. Re-scan and confirm. SPF pass on the right domain, DKIM aligned, DMARC passing. The full reference lives at how to fix SPF; provider walk-throughs like SPF on GoDaddy and DMARC on IONOS cover the DNS-panel clicks.

What should you do for HubSpot, Salesforce, Mailchimp and SendGrid?

HubSpot. Connect your sending domain in HubSpot’s settings and publish the two DKIM CNAMEs it issues (hs1-… / hs2-…). That aligns DKIM with your From domain. You don’t need a HubSpot SPF include unless you’ve configured HubSpot to use your own bounce domain.

Salesforce. Create a DKIM key in Salesforce Setup and publish the CNAME pair it generates. If Salesforce sends with your organisation’s return-path, add include:_spf.salesforce.com and configure the bounce domain — this is the one big CRM where the SPF include is often genuinely needed.

Mailchimp. Authenticate your domain and publish the k2 / k3 DKIM CNAMEs. Mailchimp alignment is DKIM-only — there is no SPF include to add anymore, and adding one from an old tutorial just wastes lookups.

SendGrid. Complete domain authentication (“automated security”): three CNAMEs handling both DKIM and the return-path on your own subdomain. No SPF include needed. Of the 740,321 domains whose SPF authorises sendgrid.net, only 18.0% have enforcing DMARC (data as of 2026-06-29) — most SendGrid senders stop one step short.

Zendesk and everything else: same pattern. Find the tool’s “domain authentication” page, publish its DKIM CNAMEs, and only touch SPF if the tool documents that it uses your return-path.

Is SPF different for European businesses?

No — SPF, DKIM and DMARC work identically everywhere. What differs in Europe is the context: who’s asking, and what your neighbours have already done.

Your ccTLD sets the local bar. European ccTLDs publish SPF well above .com rates, but the domains that finish the job — an enforcing DMARC policy on top — are the minority everywhere:

Data as of 2026-06-29. France: 13.65% enforcing DMARC; Italy: 5.24%.

Your European host’s default matters. 4,346,526 domains authorise IONOS’s EU mail servers (_spf-eu.ionos.com) in their SPF — and only 0.3% end in strict -all, with 1.0% DMARC-enforced. OVH’s 2,132,049 do better on strictness (43.7%) but only 2.2% enforce DMARC (data as of 2026-06-29). If you never touched your record, you’re standing on those defaults.

Regulators now name this. NIS2 Article 21(2)(j) requires in-scope entities to secure their communications, and Commission Implementing Regulation (EU) 2024/2690 spells out email- and DNS-security measures. Email authentication is the concrete, checkable piece — and, unusually for compliance, free to fix.

On data residency: the Defaults.Exposed scanner and census run in AWS eu-west-1, we publish aggregate figures only, and a scan checks only the domain you ask about.

Frequently asked questions

My SPF checker says “pass” but the tool’s dashboard says SPF is failing — why? The checker tested your record; the receiver tested the Return-Path domain the tool actually used, then DMARC compared it to your From domain. That’s an alignment failure, not a record failure — fixed with the vendor’s custom-domain DKIM, not with SPF edits.

Should I just add the SPF include for every tool we use? No. Each include spends part of SPF’s 10-lookup budget, recursively: 2,119,539 of 138,927,207 SPF-publishing domains sit at 9–10 lookups, and at least 797,263 are over — their SPF returns PermError and protects nothing (data as of 2026-06-29).

Does the include fix DMARC too? Only if the tool sends with your return-path, so SPF passes and aligns. For most SaaS tools it doesn’t — which is why aligned DKIM, not SPF, is the leg that makes DMARC pass for SaaS mail.

Is this a legal requirement in the EU? For entities in NIS2 scope, Article 21(2)(j) and Implementing Regulation (EU) 2024/2690 make email security an obligation. Even outside scope, insurers and customer questionnaires increasingly ask — and as of 2026-06-29, no EU ccTLD gets even a third of its domains to an enforcing DMARC policy (29.43% in .nl at best; 5.24% in .it).

Send the owner the report

Once the CNAMEs are live, re-run the scan and forward the graded report to the business owner or client. It shows, in plain language, what was failing, what you fixed and where the domain now stands — exactly the evidence they need for the insurance renewal or the customer security questionnaire, in writing rather than on your word.

Check your domain free

See exactly which leg of SPF, DKIM and DMARC is failing — privately and owner-only.

Check your domain → · Fix SPF → · SPF PermError: “too many DNS lookups” → · How we grade → · Aggregate data only. Data stored and processed in the EU.