Defaults.Exposed › Rapporter
SPF PermError-rapporten: 100× flere domener bryter 10-oppslagsgrensen enn overflatetellinger viser (2026)
Publisert 2026-07-03
Tall per 2026-06-29 · metodikk v7, pluss en kjedeprisings-gjennomgang kjørt 2026-07-03. Fra folketellingen på 261 millioner graderte domener resolverte vi hvert SPF
include:-mål som ble referert 100 ganger eller mer — 10,842 mål som dekker 95.2% av alle include-referanser — og priset hvert domenes beholdte kjede mot det kartet. Uresolverte halemål telte som null, og kjedeinnholdet gjenspeiler resolveringsdagen, så overskriften er en konservativ, gulv-vektet tilnærming: vi sier «minst». Kun aggregert; aldri en enkeltvirksomhets oppføring. Se hvordan vi graderer.
Hvor mange domener bryter SPFs 10-oppslagsgrense?
Minst 797,263 — fordi SPF har en selvdestruksjon innebygd i standarden, og utløseren gjemmer seg der eierne ikke kan se den. RFC 7208 §4.6.4 begrenser en SPF-sjekk til 10 DNS-oppslag; forbi ti stopper mottakeren og returnerer PermError, og en PermError-oppføring beskytter ingenting. Tell bare oppslagene som er synlige i selve oppføringen — slik de fleste verktøy gjør, og slik vår egen folketelling gjorde inntil denne rapporten — og du finner rundt 8 000 overtredere (7,958, for å være presis). Pris include:-kjedene de oppføringene faktisk trekker inn, og tallet når 797,263: omtrent 100 ganger større.
Hvorfor kan ikke eierne se det komme?
Fordi budsjettet brukes opp av andre folks oppføringer. include:onetool.example.com leses som én linje i DNS-panelet ditt — men mottakeren må hente den oppføringen også, og telle hver oppslagsmekanisme den inneholder, rekursivt. En oppføring med tre includes kan koste elleve. Ingenting i din egen sone endret seg den dagen du gikk over; en leverandør nøstet inn én include til, og din SPF døde uten forvarsel.
Verre er det at DMARC behandler en PermError som en fail på SPF-benet — så et domene som brøt sin SPF på denne måten feiler nå halvparten av sin egen autentisering.
Hva kjedeprisingen fant
| Funn | Domener |
|---|---|
| Over 10-oppslagsgrensen, kjeder priset | 797,263 |
| Over grensen når man bare teller synlige mekanismer | 7,958 |
Over grensen mens de ender i streng -all | 112,215 |
| På nøyaktig 9–10 oppslag — stupkanten | 2,119,539 |
To historier i den tabellen — den tredje, stupkanten, får sin egen seksjon nedenfor:
- Overflatetellinger går glipp av ~99% av bruddet. Tellingen av synlige mekanismer finner 7,958; prising av kjedene finner 797,263. Nesten all skaden er arvet fra det includene inkluderer.
- 112,215 av de ødelagte oppføringene ender i
-all. Eierne deres gjorde alt riktig — klatret over muren, valgte den strenge avslutningen — og én include for mye ugyldiggjorde det hele. Streng-utseende og ødelagt er den hardeste feilmodusen i e-postsikkerhet.
2.1 millioner domener er ett verktøy unna stupkanten
Tallet som bør bekymre lesere som for øyeblikket har det bra: 2,119,539 domener resolverer til nøyaktig 9 eller 10 oppslag — under grensen i dag, døde den dagen noen kobler til én plattform til. Det er omtrent 1 av 66 av alle SPF-publisister, og det stemmer med formen på fordelingen: SPF-oppføringen i 99-persentilen ligger allerede på 9 oppslag. Meld deg på ett markedsføringsverktøy til, lim inn linjen «bare legg til denne include», og en oppføring som var under grensen ved frokost er ugyldig ved lunsj.
Hvem sin feil er det? I økende grad, stackens
De største leverandørene har stille flatet ut sin SPF — Googles _spf.google.com og Microsofts spf.protection.outlook.com ekspanderer nå til rene IP-lister som koster null interne oppslag (vi verifiserte begge mot live DNS under denne analysen). Sprekkene kommer fra andre steder: hosting-panel-kjeder som nøster tre nivåer dypt, regionale leverandører hvis include koster 7–10 oppslag alene, og den ærlige akkumuleringen av SaaS — postkasse pluss nyhetsbrev pluss CRM pluss helpdesk, hver «bare én include». Nesten ingen legger til det ellevte oppslaget med vilje. Det ankommer som summen av rimelige beslutninger.
Hvordan sjekke og fikse din — gratis
- Tell ditt reelle totale antall — vår gratis sjekk resolverer kjeden din, eller bruk hvilken som helst SPF-oppslagsteller.
- Beskjær dødvekt: verktøy du sluttet å bruke, dupliserte includes, og den utdaterte
ptr-mekanismen. - Flat kun ut det du kontrollerer. Å erstatte en dyp include med dens IP-blokker fungerer for din egen infrastruktur; tredjeparts-IP-er endres uten varsel.
- Gi masseavsendere et subdomene. Nyhetsbrev fra
news.yourdomain.comfår sin egen oppføring og sitt eget 10-oppslagsbudsjett.
Ofte stilte spørsmål
Hva er SPFs grense på 10 DNS-oppslag?
RFC 7208 §4.6.4 tillater maksimalt 10 DNS-oppslag for å evaluere én SPF-oppføring — inkludert oppslagene inne i hver include: rekursivt. Å overskride den returnerer PermError: oppføringen behandles som ugyldig og gir ingen beskyttelse.
Hva betyr SPF PermError? En permanent evalueringsfeil — mottakeren kunne ikke behandle oppføringen din (for mange oppslag, flere oppføringer, eller ødelagt syntaks) og behandler domenet ditt som om det ikke har brukbar SPF. DMARC teller det som en fail på SPF-benet.
Hvor mange domener overskrider SPF-oppslagsgrensen? Minst 797,263 av 139 millioner SPF-publisister, ifølge vår kjedeprisings-gjennomgang — omtrent 100× de 7,958 som er synlige uten å resolvere kjeder. Ytterligere 2,119,539 ligger på 9–10 oppslag, én include fra grensen.
Stopper en PermError e-posten min fra å bli levert? Vanligvis ikke — mottakere fortsetter uten SPF, og posten din rir på DKIM og omdømme. Det som slutter å fungere er beskyttelsen: forfalskere avvises ikke lenger, og hver DMARC-sjekk av posten din mister SPF-benet sitt. Det er usynlig helt til det blir kostbart.
Hvordan reduserer jeg SPF-oppslagstallet mitt?
Fjern ubrukte includes og ptr, flat ut din egen infrastruktur til ip4:/ip6:, flytt masseavsendere til subdomener, og tell på nytt etter hvert nye verktøy. Fikseguiden går gjennom det.
Finn ut ditt reelle tall
Mekanismene du kan se er ikke ditt oppslagstall — det resolverte tallet er det mottakere beregner, og det er en 30-sekunders sjekk.
Sjekk domenet ditt → · Fiks SPF → · SPF-modenhetsmodellen → · To SPF-oppføringer = ingen → · ptr-fellen → · Kun aggregerte data. Data lagret og behandlet i EU.