Defaults.Exposed › Rettelser › Guides

SPF PermError: Sådan løser du "for mange DNS-opslag" uden at ødelægge din e-mail (2026)

Udgivet 2026-07-08

Tal fra 2026-06-29 · metodologi v7. Aggregerede censusdata på tværs af 261 millioner graderede domæner. Se hvordan vi graderer.

Mindst 797,263 domæner overskrider SPFs grænse på 10 DNS-opslag, ifølge Defaults.Exposed-census over 261,086,232 domæner — ud af 139 millioner SPF-udgivere. Efter ti opslag stopper en modtager og returnerer PermError: din SPF er ugyldig, og DMARC tæller en PermError som et fejl.

Løsningen har en fast rækkefølge, og de fleste vejledninger vender den om. Tæl dine reelle, opløste opslag; slet døde og ubrugte includes — det alene løser de fleste poster; flyt masseudsendere til underdomæner med eget SPF-budget; flatten kun som en sidste udvej og kun med automatiseret re-flattening, fordi statisk flattening forrådner og lydløst ødelægger levering.

Hvad betyder “SPF PermError: for mange DNS-opslag”?

RFC 7208 §4.6.4 begrænser enhver SPF-kontrol til 10 DNS-opslag. Overskrides ti, stopper modtageren og returnerer PermError — hele posten behandles som defekt, ikke kun den del, der er over budget. Samme afsnit tilføjer et mindre kendt andet loft: højst 2 “tomme opslag” (forespørgsler, der returnerer intet svar eller NXDOMAIN), så et par døde include:-poster til annullerede tjenester alene kan ugyldiggøre din SPF.

Konsekvensen er værre end “ingen SPF”: DMARC behandler en PermError som et SPF-fejl, så et domæne, der ødelægger sin egen SPF, er ugodkendt på SPF-benet i enhver DMARC-evaluering. Hvis DKIM heller ikke er sat op eller bryder under transit, fejler mailen DMARC helt igennem.

Ét censustal viser, hvor hårdt denne fejlmåde er: 112,215 domæner udgiver en streng -all-post, der er ugyldig på grund af opslags-overløb — ud af de 54,655,923 domæner, der overhovedet udgiver -all. Deres ejere har gjort det svære — valgt den strenge afslutning — og ét include for meget har slukket for hele posten. De ser strenge ud; de er i stykker. Se SPF PermError-rapporten for det fulde databillede.

Hvorfor brød min SPF, da jeg ikke ændrede noget?

Fordi budgettet for det meste bruges op af andres poster. Enhver include: evalueres rekursivt, og enhver opslags-mekanisme inden i den tæller mod dine ti. Én linje i dit DNS-panel kan koste fire eller fem opslag, når den er opløst. En udbyder tilføjer endnu ét include, og din SPF dør uden en eneste ændring i din zone.

De store platforme er ikke problemet: Google og Microsoft har begge flattenet deres egne SPF — _spf.google.com og spf.protection.outlook.com udvides til rene IP-lister, der koster nul interne opslag (verificeret mod live DNS, juli 2026). Virkelige overløb kommer fra hosting-panel include-kæder med adskillige niveauer af nesting og fra ærlig SaaS-stabling — postkasse plus nyhedsbrev plus CRM plus helpdesk, hvert “bare ét include”. Ingen tilføjer det ellevte opslag med vilje; det ankommer som summen af fornuftige beslutninger. Det er derfor klippekanten er så overfyldt: 2,119,539 domæner befinder sig præcis på 9–10 opløste opslag — omtrent 1 ud af 66 af alle SPF-udgivere, fint i dag, ugyldig den dag, nogen sætter endnu ét include ind. Percentilens SPF-post opløser allerede til 9 opslag. Har du mange SaaS-tjenester, dækker vejledningen om SPF-fejl for SaaS-værktøjer den udbyder-for-udbyder-udgave.

Hvilke dele af en SPF-post tæller som DNS-opslag?

Tæl den opløste total, ikke de synlige linjer. Fire includes kan være fire opslag eller fjorten.

Hvordan løser jeg “for mange DNS-opslag” uden at ødelægge e-mailen?

1. Kør den gratis scanning inden du rører DNS. Den opløser din fulde include-kæde og viser dit reelle opslags-antal, så du retter det faktiske problem — ikke posten, som den fremstår i dit panel. (Siger den, at du slet ingen SPF har, er det en anden fejl — se “SPF-post ikke fundet”.)
2. Slet døde og ubrugte includes først. Det værktøj, du droppede i 2023, det gamle hosts include, der overlevede en migrering, dubletter og enhver ptr-mekanisme. Døde includes er dobbelt giftige: de bruger opslagsbudget og er den sædvanlige kilde til tomme opslag. De fleste over-budget-poster kommer under 10 i dette trin alene. Har din post stadig mekanismer fra en tidligere udbyder, kan du følge migreringsrydningsvejledningen.
3. Kontrollér, om hvert tilbageværende include faktisk gør noget. Modtagere evaluerer SPF mod Return-Path (RFC5321.MailFrom)-domænet, ikke Fra-headeren — og mange SaaS-værktøjer placerer deres egne bounce-domæner i Return-Path, så deres include i din post ikke gør andet end at bruge budgettet. Behold kun includes til tjenester, der bruger dit domæne som Return-Path; aktivér i stedet leverandørens tilpassede-domæne DKIM for resten.
4. Flyt masseudsendere til underdomæner. Nyhedsbreve fra nyheder.ditdomæne.dk, transaktionelle mails fra mail.ditdomæne.dk. Hvert underdomæne får sin egen SPF-post med et frisk budget på 10 opslag, og et problem i én strøm holder op med at blødige over i de andre.
5. Overvej derefter kun flattening — og kun automatiseret flattening. Se nedenfor.
6. Scan igen for at bekræfte, at du er behageligt under 10 — sigt efter råderum, ikke præcis 10, ellers har du blot genoptaget din plads blandt de 2.1 millioner domæner på klippekanten. Arbejd derefter videre med alt andet, scanningen markerer, på siden ret SPF.

Bør jeg flatten min SPF-post?

Flattening erstatter includes med deres underliggende ip4:/ip6:-blokke, der koster nul opslag. Det virker — og gjort manuelt er det en forsinket postkatastrofe.

Udbydere roterer afsender-IP’er rutinemæssigt og annoncerer det til ingen. En statisk IP-liste er korrekt den dag, du indsætter den, og lydløst forkert inden for måneder — og fordi fejlen viser sig som, at andre ikke modtager din mail, opdager du det sent. Hvis beskæring og underdomæner bringer dig under grænsen, så stop der; indsæt aldrig en tredjeparts IP-blokke i din post som en permanent løsning.

Ofte stillede spørgsmål

Betyder en SPF PermError, at min e-mail holder op med at blive leveret? Ikke øjeblikkeligt — det er det, der gør den farlig. DMARC tæller en PermError som et SPF-fejl, så levering hviler udelukkende på DKIM; er DKIM manglende eller bryder under transit, fejler du DMARC. Af 139 millioner SPF-udgivere i vores census (pr. 2026-06-29) er mindst 797,263 i denne tilstand — de fleste uden at vide det.

Min post har kun fire includes — hvordan kan den overstige 10 opslag? Includes tælles rekursivt: alt inden i hvert include (og inden i dets includes) belastes dit budget, så fire synlige linjer kan opløses til fjorten opslag. Tæl med et opløsende værktøj, ikke med øjet — opløsning af kæderne er det, der afslørede ~100× flere ødelagte domæner i vores PermError-rapport sammenlignet med simple optællinger.

Jeg afslutter min post med -all — er jeg ikke beskyttet? Kun hvis posten evalueres. Vores census (pr. 2026-06-29) fandt 112,215 domæner, hvis strenge -all-poster er ugyldige på grund af opslags-overløb. En streng kvalifikator på en PermError-post beskytter ingenting.

Er grænsen 10 opslag pr. include eller for hele posten? For hele evalueringen: RFC 7208 §4.6.4 begrænser den samlede kontrol til 10, plus højst 2 tomme opslag. Hvert underdomæne har sin egen post og sit eget budget — det er grunden til, at trin 4 virker.

Tæller ip4- og ip6-poster mod grænsen? Nej — IP-mekanismer koster ingenting, og det er præcis grunden til, at flattening reducerer antallet.

Send ejeren rapporten

Retter du dette for en klient eller din arbejdsgiver, så afslut jobbet med dokumentation. Kør den gratis scanning igen efter dine ændringer og videresend den graderede rapport til virksomhedsejeren: klart sprog, dateret, PermError væk. Det er det artefakt, de skal bruge til fornyelse af cyberforsikring og det næste leverandørs sikkerhedsspørgeskema — forskellen mellem “jeg ændrede nogle DNS-poster” og en dokumenteret før-og-efter.

Kontrollér dit domæne gratis

Se dit reelle, opløste opslags-antal — og alt andet om SPF, DKIM og DMARC — privat og kun for ejeren.

Kontrollér dit domæne → · Ret SPF → · SPF fejler for SaaS-værktøjer → · Opsæt SPF på GoDaddy → · Sådan graderer vi → · Kun aggregerede data. Data opbevares og behandles i EU.