Defaults.Exposed › Rapporter

Hvorfor fejler mit SPF? 10-opslags-problemet med SaaS for britiske og EU-afsendere (2026)

Udgivet 2026-07-09

Tal pr. 2026-06-29 · metodologi v7. Aggregerede censusdata på tværs af 261 millioner graderede domæner. Se hvordan vi bedømmer.

Når SPF fejler for en virksomhed, der bruger SaaS-værktøjer i UK eller EU, er den mest sandsynlige årsag en enkelt RFC-regel, du aldrig har behøvet at tænke på: efter 10 DNS-opslag returnerer SPF ikke “fail” — det returnerer PermError, hvilket betyder, at posten behandles som om den ikke eksisterer. Mindst 797,263 domæner har allerede krydset den grænse. Yderligere 2,119,539 befinder sig på præcis 9–10 opslag — ét nyt værktøj fra den samme klippe.

Hvorfor holder SPF op med at virke, når du tilføjer et SaaS-værktøj?

SPF fungerer ved at liste de mailservere, der er autoriserede til at sende på vegne af dit domæne. Moderne virksomheder driver ikke egne mailservere — de bruger Google Workspace til intern e-mail, Mailchimp til kampagner, HubSpot til salgssekvenser og Pipedrive til CRM-udsendelse. Hver platform giver dig en include:-linje til at indsætte i din DNS.

Problemet: hvert include: er i sig selv et DNS-opslag. Og hver post inden i det include kan udløse flere opslag rekursivt. RFC 7208 §4.6.4 sætter et hårdt loft på ti. Efter ti stopper den modtagende mailserver med at evaluere og returnerer PermError — og et PermError er ikke en blød fejl, der ender i spam. Det betyder, at din SPF-post behandles som fraværende. E-mail-godkendelse fejler på SPF-benet.

Du vil ikke se dette i dit DNS-panel. Tælleren udløses kun ved live-evaluering. Du kan have tre include:-linjer i din synlige post og stadig være tolv opslag dybt, fordi hver leverandørs SPF-post trækker sine egne sub-includes ind.

Hvor mange domæner er allerede over grænsen?

Mindst 797,263. Det er antallet efter at vi løste hvert SPF include:-mål, der refereres 100 eller flere gange — 10,842 distinkte mål der dækker 95.2% af alle include-referencer — og prissatte hvert domænes fulde kæde. Overfladeantallet (hvad du ville finde ved kun at tælle de synlige linjer i en post) finder omtrent 7,958. Det kædeprissatte tal er 100 gange større, fordi næsten al skaden er usynlig inde i include-mål.

Den situation der med størst sandsynlighed rammer en europæisk virksomhed:

Europæiske hostingudbydere og svage SPF-standarder

Den hostingudbyder du startede med, er vigtig — fordi nogle sætter SPF-standarder, der allerede bruger flere af dine ti opslag, inden du forbinder et eneste SaaS-værktøj.

Blandt de største hostingudbydere brugt af europæiske domæner i vores census:

IONOS skiller sig ud: 1.0% af IONOS-hostede domæner har håndhævende DMARC, hvilket betyder at det overvældende flertal slet ikke har meningsfuld afsendergodkendelse. OVH-domæner klarer sig bedre på SPF-strengindstillingen (43.7%) men falder til 2.2% på DMARC-håndhævelse — SPF alene, uden DMARC til at knytte det til From:-headeren, beskytter kun kuverten, ikke hvad modtageren ser.

Microsoft 365 er undtagelsen i positiv forstand: 85.0% af Microsoft-hostede domæner bruger streng SPF, primært fordi Microsofts mailflow-guide sætter -all som standard. Google Workspace sætter ~all (softfail) som standard, hvilket efterlader 92% af dets domæner uden streng beskyttelse.

Sådan diagnosticerer du din SPF-fejl på under 60 sekunder

Den hurtigste kontrol er et gratis værktøj, der evaluerer hele opslagskæden — ikke kun den synlige post. Kør nslookup -type=TXT ditdomæne.com på kommandolinjen og tæl hvert include: du ser. Slå derefter hvert af disse poster op og tæl deres. Hvis du løber tør for fingre, før du løber tør for includes, er du i farezonen.

En mere pålidelig fremgangsmåde: tjek dit domæne her — scanneren evaluerer hele den løste kæde, markerer PermError og viser dig, hvilke mekanismer der bruger dit opslags­budget.

Tre diagnostiske udfald:

• PermError — du er allerede over ti. Hver e-mail du sender fejler SPF-kontrollen hos modtageren.
• Ved 9–10 opslag — du er på kanten. Den næste SaaS-integration tipper dig over.
• Softfail (~all) i stedet for hardfail (-all) — du er under grænsen, men posten er sat for tilladeligt til at yde reel beskyttelse. Se SPF-fejlkonfigurationsrapporten for det fulde billede af -all vs. ~all.

Sådan fikser du SPF, når du bruger flere SaaS-værktøjer

Der er tre tilgange, i rækkefølge af varighed:

1. Gennemgå og beskær. Start med at liste hvert include: i din nuværende post. Fjern enhver platform du ikke længere bruger — gamle ESP’er, CRM-værktøjer fra tidligere kontrakter, platforme du testede men opgav. Det er gratis og genvinder ofte flere opslag. Hvert fjernet include: kan eliminere 1–3 sub-opslag.

2. Flat din SPF-post ud. SPF-flattening løser alle include:-mål op til deres underliggende IP-intervaller og skriver dem direkte ind i din post som ip4:- og ip6:-mekanismer. IP-mekanismer udløser ikke opslag, så en flattet post kan liste snesevis af afsendelseskilder og stadig ligge på nul opslag. Ulempen: du skal re-flatte, hver gang en leverandør opdaterer deres afsende-IP’er, hvilket sker uden varsel. De fleste virksomheder bruger en betalt SPF-flattening-tjeneste (PowerDMARC, EasyDMARC, Dmarcian og andre tilbyder dette) eller bygger et overvågningsworkflow.

3. Brug SPF-makroer. RFC 7208-makroer lader dig bygge poster, der udfører et enkelt DNS-opslag pr. kontrol og svarer dynamisk, frem for en kæde af includes. Makroer kræver DNS-hosting-support og en vis implementeringsindsats, men de er den arkitektonisk rene løsning for organisationer med mange SaaS-afsendere.

Efter at have fikset SPF, par det med DMARC-håndhævelse — SPF uden DMARC godkender kun kuvertafsender, ikke header-From:-adressen som modtagere ser.

Ofte stillede spørgsmål

Hvorfor består min SPF-post mit DNS-værktøj, men fejler stadig i e-mail-headere? De fleste DNS-opslagsværktøjer tæller kun mekanismerne synlige i din egen post, ikke de sub-opslag disse mekanismer udløser. Du kan have to include:-linjer og stadig være over grænsen, hvis hver leverandørs post indeholder flere. Kun et kædeprissætningsværktøj (eller en modtagende mailserver) tæller hele dybden. Tjek dit domæne for at se det rigtige kædeantal.

Betyder SPF-fejl, at mine e-mails havner i spam? PermError (for mange opslag) betyder, at SPF-benet af godkendelsen returnerer et ikke-resultat — faktisk fraværende. DMARC evaluerer både SPF og DKIM; hvis DKIM består, kan DMARC stadig bestå på trods af SPF PermError. Hvis ingen af dem består, fejler DMARC, og resultatet afhænger af din DMARC-politik. Ved p=none leveres e-mail stadig, men fejlen logges. Ved p=quarantine eller p=reject filtreres eller returneres e-mail. Fiks SPF, så du ikke udelukkende er afhængig af DKIM.

Hvor mange opslag bruger en typisk SaaS-stak? P99 SPF-posten i vores census befinder sig allerede på 9 opslag — lige ved grænsen — inden noget tilføjes. En Google Workspace-post tilføjer 3–4 opslag; Mailchimp tilføjer 1–2; HubSpot tilføjer 1–3 afhængigt af deres nuværende konfiguration. Tre almindelige værktøjer plus din hostingudbyders standard er ofte nok til at tippe over ti.

Er SPF-flattening sikkert? Ja, forudsat at du holder det opdateret. Flattening konverterer include:-kæder til statiske IP-intervaller — hvis en leverandør roterer sine afsende-IP’er og du ikke re-flatter, begynder du at afvise deres mails. De fleste organisationer bruger en administreret flattening-tjeneste, der overvåger IP-ændringer frem for at vedligeholde det manuelt.

Mit SPF har været sådan her i årevis — hvorfor fejler det pludselig? Fordi dine leverandører opdaterede deres SPF-poster, ikke dine. Hver gang en SaaS-platform tilføjer et nyt afsende-IP-interval eller nester et andet include, stiger din kædeomkostning uden nogen ændring fra din side. 10-opslagsgrænsen evalueres live ved modtagelse af beskeder, så en leverandørændring en tirsdag morgen kan bryde dit SPF inden tirsdagseftermiddag.

Forbedrer rettelse af SPF e-mail-leveringsevnen? Det fjerner en kilde til godkendelsesfejl, som er en forudsætning for konsistent levering — især siden Google og Yahoo nu håndhæver DMARC-alignment for masseafsendere. SPF alene er ikke det fulde billede: par det med DKIM og DMARC for fuld e-mail-godkendelse.

Tjek dit SPF gratis

Hvis du ikke er sikker på, om din SPF-post er over opslagsgrænsen — eller er sat for svagt til at beskytte dit domæne — kør en gratis kontrol. Den evaluerer hele den løste kæde og viser dig præcis, hvor budgettet bruges.

Tjek dit domæne → · Fiks SPF → · SPF PermError-rapporten → · SPF-fejlkonfigurationsrapporten → · SPF-adoptionsmodellen → · Fiks DMARC → · Kun aggregerede data. Data opbevares og behandles i EU.