Defaults.Exposed › Rapporter

SPF PermError-rapporten: 100× fler domäner spränger 10-uppslagsgränsen än ytliga räkningar visar (2026)

Publicerad 2026-07-03

Siffror per 2026-06-29 · metodik v7, plus en kedjeprissättningskörning gjord 2026-07-03. Från censusen över 261 miljoner graderade domäner resolverade vi varje SPF-include:-mål som refereras 100 gånger eller mer — 10,842 mål som täcker 95.2% av alla include-referenser — och prissatte varje domäns behållna kedja mot den kartan. Oresolverade svansmål räknades som noll och kedjornas innehåll speglar resolveringsdagen, så rubriken är en konservativ, golv-partisk approximation: vi säger “minst”. Endast aggregerat; aldrig en enskild verksamhets uppgift. Se hur vi graderar.

Hur många domäner spränger SPF:s 10-uppslagsgräns?

Minst 797,263 — eftersom SPF har en självförstörelse inbyggd i standarden, och avtryckaren göms där ägarna inte kan se den. RFC 7208 §4.6.4 begränsar en SPF-kontroll till 10 DNS-uppslag; efter tio stannar mottagaren och returnerar PermError, och en PermError-post skyddar ingenting. Räkna bara de uppslag som syns i själva posten — som de flesta verktyg gör, och som vår egen census gjorde fram till den här rapporten — så hittar du omkring 8 000 syndare (7,958, för att vara exakt). Prissätt de include:-kedjor som posterna faktiskt drar in, så når antalet 797,263: ungefär 100 gånger så stort.

Varför kan ägarna inte se det komma?

Eftersom budgeten spenderas av andras poster. include:onetool.example.com läses som en rad i din DNS-panel — men mottagaren måste hämta även den posten, och räkna varje uppslagsmekanism den innehåller, rekursivt. En post med tre includes kan kosta elva. Ingenting i din egen zon ändrades den dag du gick över gränsen; en leverantör nästlade in ytterligare en include, och din SPF dog utan förvarning.

Värre än så: DMARC behandlar en PermError som ett underkännande på SPF-benet — så en domän som gick sönder sin SPF på det här sättet underkänner nu hälften av sin egen autentisering.

Vad kedjeprissättningen fann

Två berättelser i den tabellen — den tredje, stupkanten, får sitt eget avsnitt nedan:

• Ytliga räkningar missar ~99% av felen. Den synliga mekanismräkningen hittar 7,958; att prissätta kedjorna hittar 797,263. Nästan all skada ärvs från vad includen inkluderar.
• 112,215 av de trasiga posterna slutar med -all. Deras ägare gjorde allt rätt — klättrade uppför muren, valde det strikta avslutet — och en include för mycket upphävde alltihop. Strikt utseende och trasig är det bistraste felläget inom e-postsäkerhet.

2.1 miljoner domäner är ett verktyg från stupkanten

Siffran som borde oroa läsare som är helt okej just nu: 2,119,539 domäner resolverar till exakt 9 eller 10 uppslag — under gränsen idag, döda den dag någon kopplar in ytterligare en plattform. Det är ungefär 1 av 66 av alla SPF-publicerare, och det matchar fördelningens form: den 99:e percentilens SPF-post ligger redan på 9 uppslag. Registrera dig för ytterligare ett marknadsföringsverktyg, klistra in dess “lägg bara till den här includen”-rad, och en post som låg under gränsen vid frukosten är ogiltig vid lunch.

Vems fel är det? Alltmer är det stackens

De största leverantörerna har i tysthet plattat ut sin SPF — Googles _spf.google.com och Microsofts spf.protection.outlook.com expanderar nu till rena IP-listor som kostar noll interna uppslag (vi verifierade båda mot live-DNS under den här analysen). Sprängningarna kommer från annat håll: hostingpanelkedjor som nästlas tre nivåer djupt, regionala leverantörer vars include kostar 7–10 uppslag av sig själv, och den ärliga ansamlingen av SaaS — brevlåda plus nyhetsbrev plus CRM plus helpdesk, var och en “bara en include”. Nästan ingen lägger till det elfte uppslaget med flit. Det anländer som summan av rimliga beslut.

Hur du kontrollerar och fixar din — gratis

1. Räkna din verkliga summa — vår gratiskontroll resolverar din kedja, eller använd valfri SPF-uppslagsräknare.
2. Rensa dödvikt: verktyg du slutat använda, dubblettincludes och den föråldrade ptr-mekanismen.
3. Platta bara ut det du kontrollerar själv. Att ersätta en djup include med dess IP-block fungerar för din egen infrastruktur; tredjeparts-IP:n ändras utan förvarning.
4. Ge massutskickare en subdomän. Nyhetsbrev från news.dindomän.com får sin egen post och sin egen 10-uppslagsbudget.

Vanliga frågor

Vad är SPF:s gräns på 10 DNS-uppslag? RFC 7208 §4.6.4 tillåter högst 10 DNS-uppslag för att utvärdera en SPF-post — där uppslagen inuti varje include: räknas rekursivt. Att överskrida den returnerar PermError: posten behandlas som ogiltig och ger inget skydd.

Vad betyder SPF PermError? Ett permanent utvärderingsfel — mottagaren kunde inte bearbeta din post (för många uppslag, flera poster eller trasig syntax) och behandlar din domän som om den saknar användbar SPF. DMARC räknar det som ett underkännande på SPF-benet.

Hur många domäner överskrider SPF-uppslagsgränsen? Minst 797,263 av 139 miljoner SPF-publicerare, enligt vår kedjeprissättningskörning — ungefär 100× de 7,958 som syns utan att resolvera kedjorna. Ytterligare 2,119,539 ligger på 9–10 uppslag, en include från gränsen.

Stoppar en PermError min e-post från att levereras? Vanligtvis inte — mottagare fortsätter utan SPF, och din post rider på DKIM och rykte. Det som slutar fungera är skyddet: förfalskare avvisas inte längre, och varje DMARC-kontroll av din post förlorar sitt SPF-ben. Det är osynligt tills det blir dyrt.

Hur minskar jag mitt SPF-uppslagsantal? Ta bort oanvända includes och ptr, platta ut din egen infrastruktur till ip4:/ip6:, flytta massutskickare till subdomäner och räkna om efter varje nytt verktyg. Fixguiden går igenom det.

Ta reda på ditt verkliga tal

Mekanismerna du kan se är inte ditt uppslagsantal — det resolverade talet är det som mottagare beräknar, och det är en 30-sekunderskontroll.

Kontrollera din domän → · Fixa SPF → · SPF-mognadsmodellen → · Två SPF-poster = ingen → · ptr-fällan → · Endast aggregerad data. Data lagras och behandlas i EU.