Defaults.Exposed › Fikser › Guides

SPF PermError: Hvordan fikse «for mange DNS-oppslag» uten å ødelegge e-posten din (2026)

Publisert 2026-07-08

Tall per 2026-06-29 · metodikk v7. Samlet sensusdata for 261 millioner graderte domener. Se hvordan vi graderer.

Minst 797,263 domener bryter SPFs 10-DNS-oppslagsgrense, ifølge Defaults.Exposed-sensus over 261,086,232 domener — av 139 millioner SPF-publisister. Over ti oppslag stopper en mottaker og returnerer PermError: SPF er ugyldig, og DMARC teller en PermError som feil.

Fiksen har en streng rekkefølge, og de fleste veiledninger tar den baklengs. Tell de reelle, løste oppslagene; slett døde og ubrukte includes — det alene fikser de fleste poster; flytt bulkavsendere til subdomener med eget SPF-budsjett; flatten bare som siste utvei, og bare med automatisert re-flattening, fordi statisk flattening råtner og stille ødelegger levering.

Hva betyr «SPF PermError: for mange DNS-oppslag»?

RFC 7208 §4.6.4 begrenser enhver SPF-sjekk til 10 DNS-oppslag. Over ti stopper mottakeren og returnerer PermError — hele posten behandles som ødelagt, ikke bare delen som er over budsjettet. Det samme avsnittet legger til en mindre kjent annen grense: maks 2 «tomme oppslag» (spørringer som returnerer ingen svar eller NXDOMAIN), så et par døde include:-oppføringer for kansellerte tjenester kan i seg selv ugyldiggjøre SPF.

Konsekvensen er verre enn «ingen SPF»: DMARC behandler en PermError som en SPF-feil, så et domene som ødelegger sin egen SPF er uautentisert på SPF-beinet i enhver DMARC-evaluering. Hvis DKIM ikke er satt opp eller brytes under transport, feiler den e-posten nå DMARC fullstendig.

Ett sensusnummer viser hvor grusom denne feilen er: 112,215 domener publiserer en streng -all-post som er ugyldig på grunn av oppslagsoverflyt — av de 54,655,923 domenene som publiserer -all i det hele tatt. Eierne deres gjorde den vanskelige delen — valgte den strenge avslutningen — og én include for mange slo av hele posten. De ser strenge ut; de er ødelagte. For det fullstendige databildet, se SPF PermError-rapporten.

Hvorfor gikk SPF i stykker når jeg ikke endret noe?

Fordi budsjettet for det meste brukes av andres poster. Alle include: evalueres rekursivt, og enhver oppslagsmekanisme inni den teller mot dine ti. Én linje i DNS-panelet kan koste fire eller fem oppslag når den er løst opp. En leverandør nester én include til, og SPF dør uten én eneste endring i sonen din.

De store plattformene er ikke problemet: Google og Microsoft har begge flattet sin egen SPF — _spf.google.com og spf.protection.outlook.com utvides til rene IP-lister som koster null interne oppslag (bekreftet mot live DNS, juli 2026). Virkelige overbudsjetter kommer fra vertspanel-include-kjeder nestet flere lag dypt, og fra ærlig SaaS-stabling — postkasse pluss nyhetsbrev pluss CRM pluss helpdesk, alle «bare én include». Ingen legger til det ellevte oppslaget med vilje; det ankommer som summen av fornuftige beslutninger. Det er derfor klippe-kanten er så overfylt: 2,119,539 domener sitter på nøyaktig 9–10 løste oppslag — omtrent 1 av 66 av alle SPF-publisister, fint i dag, ugyldig den dagen noen limer inn én include til. Den 99. prosentilens SPF-post løses allerede til 9 oppslag. Hvis stakken din er SaaS-tung, dekker veiledningen for SPF som feiler for SaaS-verktøy leverandør-for-leverandør-versjonen.

Hvilke deler av en SPF-post teller som DNS-oppslag?

Tell det løste totalet, ikke de synlige linjene. Fire includes kan være fire oppslag eller fjorten.

Hvordan fikser jeg «for mange DNS-oppslag» uten å ødelegge e-post?

1. Kjør den gratis skanningen før du rører DNS. Den løser opp hele include-kjeden din og viser det reelle oppslagstallet ditt, slik at du fikser det faktiske problemet — ikke posten slik den ser ut i panelet. (Hvis den sier at du ikke har noen SPF i det hele tatt, er det en annen feil — se «SPF-post ikke funnet».)
2. Slett døde og ubrukte includes først. Verktøyet du droppet i 2023, den gamle vertens include som overlevde en migrering, duplikater, enhver ptr-mekanisme. Døde includes er dobbelt giftige: de brenner oppslagsbudsjett og er den vanlige kilden til tomme oppslag. De fleste overbudsjett-poster kommer under 10 i dette steget alene. Hvis posten din fortsatt bærer en tidligere leverandørs mekanismer, følg migreringsoppryddingsveiledningen.
3. Sjekk om hver gjenværende include gjør noe. Mottakere evaluerer SPF mot Return-Path (RFC5321.MailFrom)-domenet, ikke Fra-overskriften — og mange SaaS-verktøy legger sitt eget sprett-domene på Return-Path, så includes i posten din gjør ingenting annet enn å bruke budsjettet. Behold includes bare for tjenester som bruker domenet ditt som Return-Path; for resten, aktiver leverandørens egendefinerte-domene-DKIM i stedet.
4. Flytt bulkavsendere til subdomener. Nyhetsbrev fra news.dittdomene.com, transaksjons-e-post fra mail.dittdomene.com. Hvert subdomene får sin egen SPF-post med et nytt 10-oppslagsbudsjett, og et problem i én strøm slutter å blø inn i de andre.
5. Bare da bør du vurdere flattening — og bare automatisert flattening. Se nedenfor.
6. Skann på nytt for å bekrefte at du er komfortabelt under 10 — sikt mot margen, ikke 10 nøyaktig, ellers har du nettopp gjenopprettet deg i de 2.1 millioner domenene på klippe-kanten. Deretter arbeider du gjennom alt annet skanningen flaggerer på siden fiks SPF.

Bør jeg flatte SPF-posten min?

Flattening erstatter includes med de underliggende ip4:/ip6:-blokkene, som koster null oppslag. Det fungerer — og gjort for hånd er det et forsinket leveransebrudd.

Leverandører roterer sendende IP-er rutinmessig og kunngjør det til ingen. En statisk IP-liste er korrekt den dagen du limer den inn og stille feil innen måneder — og fordi feilen vises som at andre ikke mottar e-posten din, finner du ut om det sent. Hvis beskjæring og subdomener bringer deg under grensen, stopp der; lim aldri en tredjeparts IP-blokker manuelt inn i posten din som en permanent løsning.

Ofte stilte spørsmål

Betyr en SPF PermError at e-postleveransen min stopper? Ikke umiddelbart — det er det som gjør det farlig. DMARC teller en PermError som en SPF-feil, så levering lener seg helt på DKIM; hvis DKIM mangler eller brytes under transport, feiler du DMARC. Av 139 millioner SPF-publisister i sensus (per 2026-06-29), er minst 797,263 i denne tilstanden — de fleste uten å vite det.

Posten min har bare fire includes — hvordan kan den ha over 10 oppslag? Includes telles rekursivt: alt inni hver include (og inni dens includes) belastes budsjettet ditt, så fire synlige linjer kan løses til fjorten oppslag. Tell med et løsningsverktøy, ikke visuelt — å løse kjedene er slik PermError-rapporten vår fant ~100× flere ødelagte domener enn overflate-tellinger viser.

Jeg avslutter posten med -all — er jeg da ikke beskyttet? Bare hvis posten evaluerer. Sensus (per 2026-06-29) fant 112,215 domener hvis strenge -all-poster er ugyldige fra oppslagsoverflyt. En streng kvalifikator på en PermError-post beskytter ingenting.

Er grensen 10 oppslag per include eller for hele posten? For hele evalueringen: RFC 7208 §4.6.4 begrenser den komplette sjekken til 10, pluss maks 2 tomme oppslag. Hvert subdomene har sin egen post og budsjett — det er grunnen til at trinn 4 fungerer.

Teller ip4- og ip6-oppføringer mot grensen? Nei — IP-mekanismer koster ingenting, noe som er nøyaktig grunnen til at flattening reduserer tellingen.

Send eieren rapporten

Hvis du fikser dette for en klient eller arbeidsgiveren din, avslutt jobben med bevis. Kjør den gratis skanningen etter endringene dine og videresend den graderte rapporten til bedriftseieren: enkelt norsk, datert, PermError borte. Det er artefakten de vil trenge til fornyelse av cyberforsikring og neste kundes sikkerhets-spørreskjema — forskjellen mellom «Jeg endret noe DNS-poster» og dokumentert før-og-etter.

Sjekk domenet ditt gratis

Se det reelle, løste oppslagstallet ditt — og alt annet om SPF, DKIM og DMARC — privat og kun for eieren.

Sjekk domenet ditt → · Fiks SPF → · SPF feiler for SaaS-verktøy → · Sett opp SPF på GoDaddy → · Hvordan vi graderer → · Kun aggregerte data. Data lagret og behandlet i EU.