Kort svar: SPF-standarden tillæder højst 10 DNS-opslag pr. tjek. Hver
include:,a– ogmx-mekanisme koster opslag – og includes kan indeholde nye includes. Rammer din record over 10, svarer modtagere “permerror”, og SPF-beskyttelsen falder reelt bort. Løsningen: tæl opslagene, fjern includes for tjenester, I ikke længere sender fra, erstata/mxmedip4:-adresser – og saml aldrig flere SPF-records: der må kun være én.
“Too many DNS lookups” er en af de mest forræderiske mailfejl: alt ser rigtigt ud – SPF-recorden findes, tjenesterne er inkluderet – men fordi tælleren stille er kravlet over 10, evaluerer modtagerne aldrig recorden færdig. Resultatet er færre leverede mails og DMARC-rapporter fulde af permerror. Fejlen opstår næsten altid gradvist: et nyhedsbrevssystem her, et CRM dér – og en dag tipper læsset.
Kontrolramme: Vejledningen er skrevet pr. 30. august 2026. Terminaleksemplet er genskabt med et anonymiseret domæne – det er ikke data fra hostious.io.
Når en modtagende mailserver tjekker SPF, skal den slå alle mekanismer op i DNS – og hver include: kan pege videre på flere opslag. Uden en grænse kunne en ondsindet record tvinge modtagere ud i endeløse opslagskæder, så standarden satte loftet ved 10. Overskrides det, er svaret permerror – en permanent fejl, som DMARC tæller som fejlet SPF. Konsekvensen afhænger af modtageren: nogle behandler mailen som uden SPF, andre skærper spamvurderingen – og med en stram DMARC-politik kan mails ende direkte i karantæne.
Hent recorden, og følg hver include ét niveau ned – så ser du både totalen og hvem, der koster mest:
Online SPF-validatorer tæller hele træet automatisk og viser præcis, hvor opslagene går hen – brug gerne sådan én til totalen, og terminalen til at forstå detaljerne. Bemærk, at ip4:/ip6: ikke koster opslag – det er nøglen til trin 3.
v=spf1, er i sig selv en fejl (permerror hos mange modtagere). Flet dem til én.~all (softfail) eller -all (hardfail) – aldrig +all, som gør hele øvelsen meningsløs.Er totalen stadig over 10 efter oprydningen, skal mekanismerne gøres billigere: erstat a og mx (1 opslag hver) med serverens faste ip4:-adresse (0 opslag) – spørg hosting-udbyderen om den korrekte IP, hvis du er i tvivl. Send færre steder fra: jo færre systemer, der sender som dit domæne, jo kortere record – overvej om nyhedsbrevssystemet i stedet kan sende fra sit eget underdomæne (fx nyhedsbrev.ditdomæne.dk med sin egen SPF), så hoveddomænets record forbliver slank. Det er også den rigtige arkitektur for DMARC-stramning senere.
Rettelsen er dokumenteret, når en SPF-validator tæller 10 eller færre opslag uden fejl, en testmail til Gmail viser spf=pass under “Vis original”, og DMARC-rapporterne holder op med at melde permerror i dagene efter (husk DNS-propagering – gamle opslag kan hænge i cachen). Notér i én linje, hvad hver mekanisme i recorden dækker – så er næste oprydning en femminutters opgave. Og er du på Hostious mail-hosting, hjælper supporten gerne med at gennemgå recorden.
Nej – IP-mekanismer kræver ingen DNS-opslag og er derfor gratis. Det er include, a, mx, ptr, exists og redirect, der tæller – inklusive alt, hvad deres includes selv slår op.
Fordi en af jeres tjenester ændrede deres SPF-include, så den nu koster flere opslag. Jeres record er den samme – træet under den voksede. Derfor bør totalen tjekkes efter hver ny mailtjeneste og et par gange om året.
Flattening (at erstatte includes med deres rå IP-adresser) får tælleren i bund – men IP-listerne ændrer sig hos tjenesterne, så en håndflad record forvitrer stille. Brug det kun med et værktøj, der vedligeholder listen automatisk; ellers er oprydning + underdomæner den holdbare vej.