Defaults.Exposed

SPF failing for a SaaS sender in Europe: alignment or the lookup cliff

Your CRM or marketing platform is bouncing mail to European recipients, the bounce or the vendor’s dashboard says SPF failed, and you’ve been handed the DNS login because nobody else owns the record. Before you add an include, send one test message from the tool to a mailbox you control and open the raw source. The Return-Path line and the Authentication-Results line, read together, tell you which of two different problems you have. More often than not, the record you were about to edit wasn’t the one being checked.

Read two headers before you touch DNS

Receivers evaluate SPF against the domain in the Return-Path, which is the RFC5321.MailFrom, also called the envelope-from or the bounce address. Your recipient sees the From header, and the SPF check ignores it. DMARC then asks a second question: does the domain SPF checked align with the domain in the From header? A pass on the wrong domain fails that test.

So the diagnostic is one test send and two lines. In the raw message you’ll find something shaped like this:

Return-Path: <[email protected]>
Authentication-Results: mx.receiver.example;
  spf=pass smtp.mailfrom=em.crmvendor.example;
  dkim=pass header.d=em.crmvendor.example;
  dmarc=fail header.from=yourcompany.example

Read the spf= token and the smtp.mailfrom domain beside it. If SPF passed and the domain is the vendor’s, you’re in the first branch below. If the token is permerror, you’re in the second. If it’s softfail or fail and the domain beside it is your own, you’re in the third, and it’s the only one where an include belongs.

Branch one: SPF passed, on the vendor’s domain

The tool sends with a Return-Path on a bounce subdomain the vendor owns. SPF is checked against that subdomain and passes cleanly, because the vendor publishes a correct record for it. DMARC then compares that subdomain with the From domain your customer sees, which is yours. They don’t match, so the SPF leg of DMARC fails, and the dashboard reports it as “SPF failing”.

Editing your own SPF record can’t fix this, because your record was never consulted. Adding the vendor’s include spends a lookup on a check that isn’t running against you, and each include added on that theory moves you closer to the second branch.

The durable fix is the vendor’s custom-domain DKIM. Any serious platform has a domain authentication page that issues a few CNAME records; publish them and the vendor signs as your domain. That signature aligns with the From domain, so DMARC passes on the DKIM leg, and it keeps passing when a recipient forwards the message, which an SPF pass wouldn’t survive. The DKIM guide covers what the CNAMEs point at and how to confirm the signature is live.

Branch two: permerror and the ten-lookup cliff

SPF allows 10 resolved DNS lookups per evaluation. Each include counts, and so does everything nested inside it: an include that itself contains three includes costs you four. The a, mx, ptr and exists mechanisms and the redirect modifier count too; ip4 and ip6 don’t. Past ten the receiver returns permerror, and at that point the record stops authorising anything, whichever tool sent the message and wherever it landed.

In the September 2026 census, 7,408 of the 150,103,209 domains publishing an SPF record had crossed that limit. Behind them sits the cohort at nine or ten resolved lookups, one vendor include from the cliff; the census doesn’t publish a count for it, and the fix order below assumes you may be in it.

Two records produce the same result. If you switched mail providers this year and the old provider’s TXT record is still there, you have two records starting v=spf1 on one domain, and that’s a permerror before a single lookup is counted. Merge them into one or delete the stale one.

Branch three: a fail or softfail on your own domain

If Authentication-Results shows spf=softfail or spf=fail with smtp.mailfrom on your own domain, the tool does send with your domain in the envelope, and your record doesn’t list its servers. Here the include earns its lookups, or the vendor’s custom bounce domain does the same job on a subdomain you delegate to it.

Softfail is the common form because ~all is the common ending. Of the 316,600,902 domains the September 2026 census graded, dead domains included, 84,153,064 (26.6%) end their SPF record in ~all. For DMARC the tilde changes nothing; DMARC treats softfail as a failed SPF leg, and the qualifier only decides what a receiver without DMARC does with the message. The SPF guide walks through the record syntax if you’re building the include by hand.

The free scan reads your live record and tells you in one pass whether SPF is missing, duplicated, over the lookup limit or fine, and where DMARC stands, before you change anything.

The fix order

  1. Find the Return-Path the tool uses. One test send, two header lines, as above. This places you in a branch and stops you editing a record that wasn’t in play.
  2. Turn on the vendor’s custom-domain DKIM. Publish the CNAMEs from its domain authentication page and wait for the vendor’s console to show them verified. This is the fix that lasts, and for most SaaS mail it’s the whole fix.
  3. Add the vendor’s SPF include only if the tool uses your return-path. That means you’ve switched on its custom bounce domain, or the header check showed your own domain in smtp.mailfrom. If the vendor bounces through its own domain, you can leave the include out.
  4. Count your lookups before saving. Remove includes for tools you no longer use first; a record that lists a departed newsletter platform is still paying for it. Then look for a leftover second record from an old provider.
  5. Send the test again and re-scan. You’re looking for spf=pass on the right domain, dkim=pass with header.d= on your domain, and dmarc=pass. When the CNAMEs are live, forward the graded report to whoever owns the domain so they have the fix on file.

What each platform issues

Connect a sending domain in HubSpot’s settings and it hands you two DKIM CNAMEs, prefixed hs1- and hs2-. Once both are published, DKIM aligns with your From domain, and you don’t need a HubSpot SPF include unless you’ve also configured HubSpot to use your own bounce domain.

Salesforce generates a DKIM key in Setup and gives you a CNAME pair to publish. It’s the one big CRM where the SPF include is often needed, because it can send with your organisation’s return-path; if it does, add the include it documents and configure the bounce domain alongside it.

Mailchimp goes the other way from Salesforce: when you authenticate a domain it gives you k2 and k3 DKIM CNAMEs and aligns on DKIM only, so there’s no SPF include to add. If an old tutorial had you add one, it’s only using up lookups.

SendGrid’s domain authentication issues three CNAMEs that cover DKIM and the return-path on a subdomain of your own. Once they resolve, SPF passes and aligns on that subdomain and no include is needed in your root record.

Zendesk and the rest follow the same pattern. Find the tool’s domain authentication page, publish its DKIM CNAMEs, and touch SPF only if the vendor’s documentation says it sends with your return-path.

Why the bounces look European

SPF, DKIM and DMARC behave identically in every country; a receiver in Frankfurt runs the same checks as one in Denver, though each one decides for itself what to do with a failure. Some reject a DMARC failure outright and others quarantine it, so the same misaligned message bounces from one mailbox and lands in spam at another. So which recipients bounced says more about their policies than about where the fault is.

In Europe the question tends to arrive with a regulation attached. NIS2 Article 21(2)(j) requires in-scope entities to secure their communications, and Commission Implementing Regulation (EU) 2024/2690 spells out the email and DNS security measures behind it. Email authentication is the concrete, checkable piece of that, and unusually for compliance work it’s free to fix. If the question reached you as a customer’s security questionnaire, the questionnaire guide covers what the assessor wants to see in the answer.

Publish the CNAMEs today, send the test tomorrow when they’ve propagated, and re-scan. Once DKIM aligns the bounces stop, and the SPF record can stay as it is.

Figures as of 5 September 2026, from the September 2026 edition of the defaults.exposed census. Census numbers move every month; the current values are on the census data page.