Defaults.Exposed › Rapporter

SPF PermError-rapporten: 100× flere domæner overskrider 10-opslagsgrænsen, end overfladetal viser (2026)

Udgivet 2026-07-03

Tal pr. 2026-06-29 · metodologi v7, plus en kædeprisning kørt 2026-07-03. Ud fra censussen med 261 millioner graderede domæner opløste vi hvert SPF-include:-mål, der refereres 100 gange eller mere — 10,842 mål, der dækker 95.2% af alle include-referencer — og prissatte hvert domænes bevarede kæde mod det kort. Uopløste hale-mål tælles som nul, og kædeindholdet afspejler opløsningsdagen, så overskriften er en konservativ, gulv-forskudt tilnærmelse: vi siger “mindst”. Kun aggregeret; aldrig en enkelt virksomheds record. Se hvordan vi graderer.

Hvor mange domæner overskrider SPF’s 10-opslagsgrænse?

Mindst 797,263 — fordi SPF har en selvdestruktion indbygget i standarden, og udløseren gemmer sig, hvor ejere ikke kan se den. RFC 7208 §4.6.4 sætter et loft på 10 DNS-opslag for en SPF-kontrol; efter ti stopper modtageren og returnerer PermError, og en PermError-record beskytter ingenting. Tæl kun de opslag, der er synlige i selve recorden — som de fleste værktøjer gør, og som vores egen census gjorde indtil denne rapport — og du finder omkring 8.000 syndere (7,958, helt præcist). Prissæt de include:-kæder, som disse records rent faktisk trækker ind, og tallet når 797,263: cirka 100 gange større.

Hvorfor kan ejere ikke se det komme?

Fordi budgettet bruges af andres records. include:onetool.example.com læses som én linje i dit DNS-panel — men modtageren skal også hente den record og tælle hver opslagsmekanisme, den indeholder, rekursivt. En record med tre includes kan koste elleve. Intet i din egen zone ændrede sig den dag, du gik over grænsen; en udbyder nestede endnu et include, og din SPF døde uden varsel.

Værre endnu: DMARC behandler en PermError som en fejl på SPF-benet — så et domæne, der brød sin SPF på denne måde, dumper nu halvdelen af sin egen autentificering.

Hvad kædeprisningen fandt

To historier i den tabel — den tredje, kanten af afgrunden, får sit eget afsnit nedenfor:

• Overfladetal overser ~99% af bruddet. Optællingen af synlige mekanismer finder 7,958; prissætning af kæderne finder 797,263. Næsten al skaden er arvet fra det, includes inkluderer.
• 112,215 af de brudte records ender i -all. Deres ejere gjorde alt rigtigt — klatrede op ad muren, valgte den strikte afslutning — og ét include for meget ophævede det hele. Strikt-udseende og brudt er den hårdeste fejltilstand i email-sikkerhed.

2.1 millioner domæner er ét værktøj fra afgrunden

Tallet, der bør bekymre læsere, der lige nu er OK: 2,119,539 domæner opløses til præcis 9 eller 10 opslag — under grænsen i dag, døde den dag nogen tilslutter endnu en platform. Det er cirka 1 ud af 66 af alle SPF-udgivere, og det passer med fordelingens form: den 99. percentil-SPF-record sidder allerede på 9 opslag. Tilmeld dig ét marketingværktøj mere, indsæt dets “tilføj bare dette include”-linje, og en record, der var under grænsen ved morgenmaden, er ophævet ved frokosttid.

Hvis skyld er det? I stigende grad stakkens

De største udbydere har stille og roligt fladet deres SPF ud — Googles _spf.google.com og Microsofts spf.protection.outlook.com ekspanderer nu til rene IP-lister, der koster nul interne opslag (vi verificerede begge mod live DNS under denne analyse). Sprængningerne kommer andetstedsfra: hosting-panel-kæder, der nester tre lag dybt, regionale udbydere, hvis include i sig selv koster 7–10 opslag, og den ærlige ophobning af SaaS — postkasse plus nyhedsbrev plus CRM plus helpdesk, hver især “bare ét include”. Næsten ingen tilføjer det ellevte opslag med vilje. Det ankommer som summen af rimelige beslutninger.

Sådan tjekker og retter du din — gratis

1. Tæl dit reelle total — vores gratis kontrol opløser din kæde, eller brug en hvilken som helst SPF-opslagstæller.
2. Beskær dødvægt: værktøjer du er holdt op med at bruge, duplikerede includes, og den forældede ptr-mekanisme.
3. Flad kun ud, hvad du selv styrer. At erstatte et dybt include med dets IP-blokke virker for din egen infrastruktur; tredjeparts-IP’er ændrer sig uden varsel.
4. Giv masseafsendere et subdomæne. Nyhedsbreve fra news.yourdomain.com får deres egen record og deres eget 10-opslagsbudget.

Ofte stillede spørgsmål

Hvad er SPF’s grænse på 10 DNS-opslag? RFC 7208 §4.6.4 tillader højst 10 DNS-opslag til at evaluere én SPF-record — inklusive opslagene inde i hvert include: rekursivt. Overskrides den, returneres PermError: recorden behandles som ugyldig og giver ingen beskyttelse.

Hvad betyder SPF PermError? En permanent evalueringsfejl — modtageren kunne ikke behandle din record (for mange opslag, flere records eller brudt syntaks) og behandler dit domæne, som om det ingen brugbar SPF har. DMARC tæller det som en fejl på SPF-benet.

Hvor mange domæner overskrider SPF-opslagsgrænsen? Mindst 797,263 af 139 millioner SPF-udgivere, ifølge vores kædeprisning — cirka 100× de 7,958, der er synlige uden at opløse kæder. Yderligere 2,119,539 sidder på 9–10 opslag, ét include fra grænsen.

Stopper en PermError min email fra at blive leveret? Som regel ikke — modtagere fortsætter uden SPF, og din post rider på DKIM og omdømme. Det, der holder op med at virke, er beskyttelsen: forfalskere afvises ikke længere, og hver DMARC-kontrol af din post mister sit SPF-ben. Det er usynligt, indtil det bliver dyrt.

Hvordan reducerer jeg mit SPF-opslagstal? Fjern ubrugte includes og ptr, flad din egen infrastruktur ud til ip4:/ip6:, flyt masseafsendere til subdomæner, og tæl om efter hvert nyt værktøj. Rettevejledningen fører dig igennem det.

Find ud af dit reelle tal

De mekanismer, du kan se, er ikke dit opslagstal — det opløste tal er det, modtagere beregner, og det er en 30-sekunders kontrol.

Tjek dit domæne → · Ret SPF → · SPF-modenhedsmodellen → · To SPF-records = ingen → · ptr-fælden → · Kun aggregeret data. Data lagres og behandles i EU.