Hvorfor feiler SPF-en min? 10-oppslagsproblemet med SaaS for britiske og EU-avsendere (2026)

Publisert 2026-07-09

Tall per 2026-06-29 · metodologi v7. Aggregerte censusdata på tvers av 261 millioner graderte domener. Se hvordan vi bedømmer.

Når SPF feiler for en bedrift som bruker SaaS-verktøy i Storbritannia eller EU, er den mest sannsynlige årsaken en enkelt RFC-regel du aldri har trengt å tenke på: etter 10 DNS-oppslag returnerer SPF ikke “fail” — det returnerer PermError, noe som betyr at posten behandles som om den ikke eksisterer. Minst 797,263 domener har allerede krysset den grensen. Ytterligere 2,119,539 befinner seg på nøyaktig 9–10 oppslag — ett nytt verktøy unna det samme stupet.

Hvorfor slutter SPF å fungere når du legger til et SaaS-verktøy?

SPF fungerer ved å liste e-postserverne som er autorisert til å sende på vegne av domenet ditt. Moderne bedrifter driver ikke egne e-postservere — de bruker Google Workspace til intern e-post, Mailchimp til kampanjer, HubSpot til salgssekvenser og Pipedrive til CRM-utsendelse. Hver plattform gir deg en include:-linje som skal limes inn i DNS-en din.

Problemet: hvert include: er i seg selv et DNS-oppslag. Og hver post inne i det includet kan utløse flere oppslag rekursivt. RFC 7208 §4.6.4 setter et hardt tak på ti. Etter ti stopper den mottakende e-postserveren å evaluere og returnerer PermError — og et PermError er ikke en myk feil som havner i søppelpost. Det betyr at SPF-posten din behandles som fraværende. E-postgodkjenning feiler på SPF-delen.

Du vil ikke se dette i DNS-panelet ditt. Telleren utløses bare ved live-evaluering. Du kan ha tre include:-linjer i den synlige posten din og likevel være tolv oppslag dypt, fordi hver leverandørs SPF-post trekker inn sine egne sub-includes.

Hvor mange domener er allerede over grensen?

Minst 797,263. Det er antallet etter at vi løste opp hvert SPF include:-mål som refereres 100 eller flere ganger — 10,842 distinkte mål som dekker 95.2% av alle include-referanser — og prissatte hver domens fulle kjede. Overflateantallet (det du ville funnet ved å telle bare de synlige linjene i en post) finner omtrent 7,958. Det kjedeprissatte tallet er 100 ganger større, fordi nesten all skaden er usynlig inne i include-mål.

Situasjonen som oftest rammer en europeisk bedrift:

Scenario	Hva skjer
Google Workspace + Mailchimp + HubSpot + én til	Sannsynligvis på eller over 10 oppslag
IONOS-hosting + tre SaaS-verktøy	Høy risiko: IONOS’ eget SPF-mål legger til flere hopp
OVH-hosting + to transaksjonsverktøy + et CRM	Risiko avhenger av OVH SPF-dybde ved evalueringstidspunktet
Microsoft 365 alene	Lav risiko: Microsofts SPF er kompakt og godt vedlikeholdt

Europeiske hostingleverandører og svake SPF-standarder

Hvilken hostingleverandør du startet med, spiller en rolle — fordi noen setter SPF-standarder som allerede bruker opp flere av dine ti oppslag før du kobler til ett eneste SaaS-verktøy.

Blant de største hostingleverandørene brukt av europeiske domener i vår census:

Leverandør	Domener som bruker den	SPF streng (-all)	DMARC håndhevet
IONOS (EU)	4,346,526	0.3%	1.0%
OVH	2,132,049	43.7%	2.2%
Microsoft 365	10,205,070	85.0%	21.7%
Google Workspace	12,145,313	8.0%	18.5%

IONOS skiller seg ut: 1.0% av IONOS-hostede domener har håndhevende DMARC, noe som betyr at det store flertallet ikke har meningsfull avsendergodkjenning i det hele tatt. OVH-domener gjør det bedre på SPF-strenginnstillingen (43.7%) men faller til 2.2% på DMARC-håndhevelse — SPF alene, uten DMARC for å knytte det til From:-headeren, beskytter bare konvolutten, ikke det mottakeren ser.

Microsoft 365 er unntaket på en god måte: 85.0% av Microsoft-hostede domener bruker streng SPF, i stor grad fordi Microsofts e-postflytveiviser setter -all som standard. Google Workspace setter ~all (softfail) som standard, noe som etterlater 92% av domenene uten streng beskyttelse.

Slik diagnostiserer du SPF-feilen din på under 60 sekunder

Den raskeste kontrollen er et gratis verktøy som evaluerer hele oppslagskjeden — ikke bare den synlige posten. Kjør nslookup -type=TXT dittdomene.com på kommandolinjen og tell hvert include: du ser. Slå deretter opp hver av disse postene og tell deres. Hvis du går tom for fingre før du går tom for includes, er du i faresonen.

En mer pålitelig tilnærming: sjekk domenet ditt her — skanneren evaluerer hele den løste kjeden, markerer PermError og viser deg hvilke mekanismer som bruker opp oppslagsbudsjettet ditt.

Tre diagnostiske utfall:

PermError — du er allerede over ti. Hver e-post du sender feiler SPF-kontrollen hos mottakeren.
Ved 9–10 oppslag — du er på kanten. Neste SaaS-integrasjon velter deg over.
Softfail (~all) i stedet for hardfail (-all) — du er under grensen men posten er satt for tillatelsesfull til å gi reell beskyttelse. Se SPF-feilkonfigurasjonsrapporten for det fulle bildet av -all vs. ~all.

Slik fikser du SPF når du bruker flere SaaS-verktøy

Det er tre tilnærminger, i rekkefølge etter varighet:

1. Gjennomgå og rensk. Begynn med å liste hvert include: i den nåværende posten din. Fjern alle plattformer du ikke lenger bruker — gamle ESP-er, CRM-verktøy fra tidligere kontrakter, plattformer du testet men forlot. Det er gratis og gjenoppretter ofte flere oppslag. Hvert fjernede include: kan eliminere 1–3 sub-oppslag.

2. Flat ut SPF-posten din. SPF-flattening løser opp alle include:-mål til de underliggende IP-intervallene og skriver dem direkte inn i posten din som ip4:- og ip6:-mekanismer. IP-mekanismer utløser ikke oppslag, så en flattet post kan liste opp dusinvis av sendingskilder og likevel ligge på null oppslag. Ulempen: du må re-flatte hver gang en leverandør oppdaterer sine sendende IP-adresser, noe som skjer uten forvarsel. De fleste organisasjoner bruker en betalt SPF-flattening-tjeneste (PowerDMARC, EasyDMARC, Dmarcian og andre tilbyr dette) eller bygger en overvåkningsarbeidsflyt.

3. Bruk SPF-makroer. RFC 7208-makroer lar deg bygge poster som utfører ett enkelt DNS-oppslag per kontroll og svarer dynamisk, i stedet for en kjede av includes. Makroer krever støtte fra DNS-hosting og noe implementeringsinnsats, men de er den arkitektonisk rene løsningen for organisasjoner med mange SaaS-avsendere.

Etter å ha fikset SPF, kombiner det med DMARC-håndhevelse — SPF uten DMARC godkjenner bare konvolutt-avsender, ikke header-From:-adressen som mottakere ser.

Vanlige spørsmål

Hvorfor består SPF-posten min DNS-verktøyet mitt, men feiler likevel i e-posthoder? De fleste DNS-oppslagsverktøy teller bare mekanismene som er synlige i din egen post, ikke sub-oppslagene disse mekanismene utløser. Du kan ha to include:-linjer og likevel være over grensen hvis hver leverandørs post inneholder flere. Bare et kjedeprissettingsverktøy (eller en mottakende e-postserver) teller hele dybden. Sjekk domenet ditt for å se det faktiske kjedentallet.

Betyr SPF-feil at e-postene mine havner i søppelpost? PermError (for mange oppslag) betyr at SPF-delen av godkjenningen returnerer et ikke-resultat — faktisk fraværende. DMARC evaluerer både SPF og DKIM; hvis DKIM består, kan DMARC likevel bestå til tross for SPF PermError. Hvis ingen av dem består, feiler DMARC, og utfallet avhenger av DMARC-policyen din. Ved p=none leveres e-post fortsatt, men feilen logges. Ved p=quarantine eller p=reject filtreres eller returneres e-post. Fiks SPF slik at du ikke er avhengig av DKIM alene.

Hvor mange oppslag bruker en typisk SaaS-stabel? P99 SPF-posten i vår census befinner seg allerede på 9 oppslag — rett ved grensen — før noe legges til. En Google Workspace-post legger til 3–4 oppslag; Mailchimp legger til 1–2; HubSpot legger til 1–3 avhengig av deres nåværende konfigurasjon. Tre vanlige verktøy pluss hostingleverandørens standard er ofte nok til å tippe over ti.

Er SPF-flattening trygt? Ja, forutsatt at du holder det oppdatert. Flattening konverterer include:-kjeder til statiske IP-intervaller — hvis en leverandør roterer sine sendende IP-adresser og du ikke re-flatter, begynner du å avvise e-postene deres. De fleste organisasjoner bruker en administrert flattening-tjeneste som overvåker IP-endringer i stedet for å vedlikeholde det manuelt.

SPF-en min har vært slik i årevis — hvorfor feiler den plutselig? Fordi leverandørene dine oppdaterte SPF-postene sine, ikke dine. Hver gang en SaaS-plattform legger til et nytt sendende IP-intervall eller nøster et annet include, stiger kjedekostnaden din uten noen endring fra din side. 10-oppslagsgrensen evalueres live ved meldingsmottak, så en leverandørendring tirsdag morgen kan bryte SPF-en din tirsdag ettermiddag.

Forbedrer fiks av SPF e-postleveransen? Det fjerner en kilde til godkjenningsfeil, som er en forutsetning for konsekvent levering — særlig siden Google og Yahoo nå håndhever DMARC-samsvar for masseavsendere. SPF alene er ikke hele bildet: kombiner det med DKIM og DMARC for fullstendig e-postgodkjenning.

Sjekk SPF-en din gratis

Hvis du er usikker på om SPF-posten din er over oppslagsgrensen — eller er satt for svakt til å beskytte domenet ditt — kjør en gratis sjekk. Den evaluerer hele den løste kjeden og viser deg nøyaktig hvor budsjettet brukes.

Sjekk domenet ditt → · Fiks SPF → · SPF PermError-rapporten → · SPF-feilkonfigurasjonsrapporten → · SPF-adopsjonsmodellen → · Fiks DMARC → · Kun aggregerte data. Data lagres og behandles i EU.