Defaults.Exposed › Rapporter

Varför misslyckas mitt SPF? 10-uppslagsproblemet med SaaS för brittiska och EU-avsändare (2026)

Publicerad 2026-07-09

Siffror per 2026-06-29 · metodik v7. Aggregerade censusdata för 261 miljoner graderade domäner. Se hur vi betygsätter.

När SPF misslyckas för ett företag som använder SaaS-verktyg i Storbritannien eller EU beror det troligtvis på en enda RFC-regel du aldrig behövt tänka på: efter 10 DNS-uppslag returnerar SPF inte “fail” — det returnerar PermError, vilket innebär att posten behandlas som om den inte existerar. Minst 797,263 domäner har redan korsat den gränsen. Ytterligare 2,119,539 befinner sig på exakt 9–10 uppslag — ett nytt verktyg bort från samma stup.

Varför slutar SPF fungera när du lägger till ett SaaS-verktyg?

SPF fungerar genom att lista de e-postservrar som är behöriga att skicka på uppdrag av din domän. Moderna företag driver inte egna e-postservrar — de använder Google Workspace för intern e-post, Mailchimp för kampanjer, HubSpot för säljsekvenser och Pipedrive för CRM-utskick. Varje plattform ger dig en include:-rad att klistra in i din DNS.

Problemet: varje include: är i sig ett DNS-uppslag. Och varje post inuti det inkluderandet kan utlösa fler uppslag rekursivt. RFC 7208 §4.6.4 sätter ett hårt tak på tio. Efter tio slutar den mottagande e-postservern att utvärdera och returnerar PermError — och ett PermError är inte ett mjukt misslyckande som hamnar i skräppost. Det innebär att din SPF-post behandlas som frånvarande. E-postautentisering misslyckas på SPF-delen.

Du kommer inte se detta i din DNS-panel. Räknaren aktiveras bara vid live-utvärdering. Du kan ha tre include:-rader i din synliga post och ändå vara tolv uppslag djupt, eftersom varje leverantörs SPF-post drar in egna sub-inkluderanden.

Hur många domäner är redan över gränsen?

Minst 797,263. Det är antalet efter att vi löst upp varje SPF include:-mål som refereras 100 eller fler gånger — 10,842 distinkta mål som täcker 95.2% av alla include-referenser — och prissatt varje domäns fullständiga kedja. Ytantalet (vad du hittar genom att bara räkna synliga rader i en post) hittar ungefär 7,958. Det kedjeprisade siffran är 100 gånger större, eftersom nästan all skadan är osynlig inuti include-mål.

Det scenario som troligtvis drabbar ett europeiskt företag:

Europeiska hostingleverantörer och svaga SPF-standarder

Vilken hostingleverantör du startade med spelar roll — eftersom vissa sätter SPF-standarder som redan förbrukar flera av dina tio uppslag innan du kopplar ett enda SaaS-verktyg.

Bland de största hostingleverantörerna som används av europeiska domäner i vår census:

IONOS utmärker sig: 1.0% av IONOS-hostade domäner har verkställande DMARC, vilket innebär att den överväldigande majoriteten saknar meningsfull avsändarautentisering överhuvudtaget. OVH-domäner presterar bättre på SPF-striktinställningen (43.7%) men faller till 2.2% på DMARC-verkställande — SPF ensamt, utan DMARC för att knyta det till From:-headern, skyddar bara kuvertet, inte vad mottagaren ser.

Microsoft 365 är undantaget på ett bra sätt: 85.0% av Microsoft-hostade domäner använder strikt SPF, till stor del för att Microsofts e-postflödesguide sätter -all som standard. Google Workspace sätter ~all (softfail) som standard, vilket lämnar 92% av dess domäner utan strikt skydd.

Så diagnostiserar du ditt SPF-misslyckande på under 60 sekunder

Den snabbaste kontrollen är ett gratis verktyg som utvärderar hela uppslags­kedjan — inte bara den synliga posten. Kör nslookup -type=TXT dindomän.com i kommandoraden och räkna varje include: du ser. Slå sedan upp var och en av dessa poster och räkna deras. Om du tar slut på fingrar innan du tar slut på inkluderanden befinner du dig i farozonen.

En mer tillförlitlig metod: kontrollera din domän här — skannern utvärderar hela den lösta kedjan, flaggar PermError och visar dig vilka mekanismer som förbrukar din uppslags­budget.

Tre diagnostiska utfall:

• PermError — du är redan över tio. Varje e-post du skickar misslyckas med SPF-kontrollen hos mottagaren.
• Vid 9–10 uppslag — du är på stupet. Nästa SaaS-integration välter dig över.
• Softfail (~all) istället för hardfail (-all) — du är under gränsen men posten är satt för tillåtande för att ge verkligt skydd. Se SPF-felkonfigurationsrapporten för hela bilden om -all kontra ~all.

Hur man åtgärdar SPF när man använder flera SaaS-verktyg

Det finns tre metoder, i ordning av beständighet:

1. Granska och rensa. Börja med att lista varje include: i din nuvarande post. Ta bort alla plattformar du inte längre använder — gamla ESP:er, CRM-verktyg från tidigare kontrakt, plattformar du testade men övergav. Det är gratis och återvinner ofta flera uppslag. Varje borttagen include: kan eliminera 1–3 sub-uppslag.

2. Platta ut din SPF-post. SPF-flattening löser upp alla include:-mål till deras underliggande IP-intervall och skriver dem direkt i din post som ip4:- och ip6:-mekanismer. IP-mekanismer utlöser inte uppslag, så en tillplattad post kan lista dussintals avsändningskällor och ändå ligga på noll uppslag. Nackdelen: du behöver platta ut igen när en leverantör uppdaterar sina sändande IP-adresser, vilket sker utan förvarning. De flesta organisationer använder en betald SPF-flattening-tjänst (PowerDMARC, EasyDMARC, Dmarcian och andra erbjuder detta) eller bygger ett övervakningsarbetsflöde.

3. Använd SPF-makron. RFC 7208-makron låter dig bygga poster som utför ett enda DNS-uppslag per kontroll och svarar dynamiskt, istället för en kedja av inkluderanden. Makron kräver stöd från DNS-hosting och viss implementeringsinsats, men de är den arkitektoniskt rena lösningen för organisationer med många SaaS-avsändare.

Efter att ha åtgärdat SPF, para det med DMARC-verkställande — SPF utan DMARC autentiserar bara kuvertavsändaren, inte header-From:-adressen som mottagare ser.

Vanliga frågor

Varför klarar min SPF-post mitt DNS-verktyg men misslyckas ändå i e-posthuvuden? De flesta DNS-uppslagsverktyg räknar bara mekanismerna som syns i din egen post, inte de sub-uppslag dessa mekanismer utlöser. Du kan ha två include:-rader och ändå vara över gränsen om varje leverantörs post innehåller flera till. Bara ett kedjeprisande verktyg (eller en mottagande e-postserver) räknar hela djupet. Kontrollera din domän för att se det verkliga kedjantalet.

Innebär SPF-misslyckande att mina e-postmeddelanden hamnar i skräppost? PermError (för många uppslag) innebär att SPF-delen av autentiseringen returnerar ett icke-resultat — faktiskt frånvarande. DMARC utvärderar både SPF och DKIM; om DKIM klarar sig kan DMARC ändå klara sig trots SPF PermError. Om ingendera klarar sig misslyckas DMARC, och utfallet beror på din DMARC-policy. Vid p=none levereras e-post fortfarande men felet loggas. Vid p=quarantine eller p=reject filtreras eller studsar e-post. Åtgärda SPF så att du inte förlitar dig enbart på DKIM.

Hur många uppslag använder en typisk SaaS-stack? P99 SPF-posten i vår census befinner sig redan på 9 uppslag — precis vid gränsen — innan något läggs till. En Google Workspace-post lägger till 3–4 uppslag; Mailchimp lägger till 1–2; HubSpot lägger till 1–3 beroende på deras aktuella konfiguration. Tre vanliga verktyg plus din hostingleverantörs standard räcker ofta för att tippa över tio.

Är SPF-flattening säkert? Ja, förutsatt att du håller det aktuellt. Flattening konverterar include:-kedjor till statiska IP-intervall — om en leverantör roterar sina sändande IP-adresser och du inte plattar ut igen börjar du avvisa deras e-post. De flesta organisationer använder en hanterad flattening-tjänst som övervakar IP-förändringar istället för att underhålla det manuellt.

Mitt SPF har fungerat så här i flera år — varför misslyckas det plötsligt? Eftersom dina leverantörer uppdaterade sina SPF-poster, inte dina. Varje gång en SaaS-plattform lägger till ett nytt sändande IP-intervall eller nästlar ett annat inkluderande stiger din kedjekostnad utan någon förändring från din sida. 10-uppslags­gränsen utvärderas live vid meddelandemottagning, så en leverantörsändring en tisdagsmorgon kan bryta ditt SPF till tisdagseftermiddagen.

Förbättrar rättning av SPF e-postleveransen? Det tar bort en källa till autentiseringsmisslyckande, vilket är en förutsättning för konsekvent leverans — särskilt sedan Google och Yahoo nu verkställer DMARC-anpassning för massavsändare. SPF ensamt är inte hela bilden: para det med DKIM och DMARC för fullständig e-postautentisering.

Kontrollera ditt SPF gratis

Om du är osäker på om din SPF-post är över uppslags­gränsen — eller är satt för svagt för att skydda din domän — gör en gratis kontroll. Den utvärderar hela den lösta kedjan och visar dig exakt var budgeten förbrukas.

Kontrollera din domän → · Åtgärda SPF → · SPF PermError-rapporten → · SPF-felkonfigurationsrapporten → · SPF-adoptionsmognadmodellen → · Åtgärda DMARC → · Enbart aggregerade data. Data lagras och behandlas inom EU.