SPF-fejlen „too many DNS lookups“ – tæl og slank din record

Kort svar: SPF-standarden tillader højst 10 DNS-opslag pr. tjek. Hver include:, a, mx, ptr, exists og redirect 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, erstat a/mx med faste ip4:-adresser, flyt bulkmail til et underdomæne – og hav aldrig mere end én SPF-record.

Fagligt gennemgået: 2. oktober 2026

“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.

Hvorfor findes grænsen?

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 (RFC 7208) 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 eller blive afvist, hvis DKIM heller ikke består.

Hvad tæller – og hvad er gratis?

Mekanisme	Koster DNS-opslag?	Bemærkning
include:	Ja, 1 + alt hvad den inkluderede record selv slår op	Den typiske synder
a	Ja, 1	Slår domænets A/AAAA-record op
mx	Ja, 1 + opslag af MX-navnene	Højst 10 MX-navne pr. mx-mekanisme
ptr	Ja	Frarådet i standarden – brug den ikke
exists:	Ja, 1	Sjælden, bruges af enkelte tjenester
redirect=	Ja, 1	Erstatter hele recorden med en anden
ip4: / ip6:	Nej	Gratis – nøglen til at slanke recorden
all	Nej	Afslutningen, fx ~all eller -all

Der er to mindre kendte grænser oveni. Standarden anbefaler, at modtagere højst accepterer to “void lookups” – opslag, der returnerer intet svar eller et ikke-eksisterende navn. En include til en nedlagt tjeneste kan derfor give permerror, selv om totalen er under 10. Og en mx– eller ptr-mekanisme må højst føre til 10 navne, der skal slås op.

Før du ændrer noget: Kopiér den nuværende SPF-record ordret ind i et dokument, før du retter. Notér, hvilke systemer der sender mail som domænet – webshop, nyhedsbrev, CRM, faktura, helpdesk og din mailudbyder. Sænk gerne TTL på recorden et døgn før, så en eventuel rettelse slår hurtigt igennem.

1. Tæl dine opslag

Hent recorden, og følg hver include ét niveau ned – så ser du både totalen og hvem, der koster mest:

dig +short TXT ditdomæne.dk | grep "v=spf1"
dig +short TXT _spf.nyhedsbrevstjeneste.example | grep "v=spf1"

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. Tæl selv efter på papir første gang: hver linje i træet, der indeholder include, a, mx, exists eller redirect, giver ét opslag.

2. Ryd op i recorden

• Fjern døde includes: nyhedsbrevssystemet, I skiftede væk fra, det gamle CRM, kampagneværktøjet ingen bruger. Hver include skal kunne forsvares med “vi sender stadig mail herfra”.
• Saml til én record: to TXT-records, der begge starter med v=spf1, er i sig selv en fejl (permerror). Flet dem til én.
• Tjek for dubletter: samme tjeneste inkluderet både direkte og via en anden include – typisk efter udbyderskift.
• Afslut korrekt: recorden bør ende på ~all (softfail) eller -all (hardfail) – aldrig +all, som gør hele øvelsen meningsløs.

3. Slank de tunge mekanismer

Er totalen stadig over 10 efter oprydningen, skal mekanismerne gøres billigere: erstat a og mx (1 opslag hver plus eventuelle MX-navne) med serverens faste ip4:-adresse (0 opslag) – spørg hostingudbyderen om den korrekte IP, hvis du er i tvivl. Gør det kun for servere, hvis IP du ved er stabil; skifter IP’en, skal recorden opdateres samtidig.

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.

4. Et eksempel før og efter

Her er en anonymiseret record, hvor webserverens a og mx stadig står, og et gammelt CRM aldrig blev fjernet (IP-adressen er en dokumentationsadresse):

Før:
v=spf1 a mx include:_spf.mailudbyder.example include:spf.nyhedsbrev.example include:spf.gammeltcrm.example include:spf.helpdesk.example ~all

Efter:
v=spf1 ip4:192.0.2.10 include:_spf.mailudbyder.example include:spf.helpdesk.example ~all

Webserverens a og mx er erstattet af én ip4:, det gamle CRM er fjernet, og nyhedsbrevet sender nu fra nyhedsbrev.ditdomæne.dk med sin egen SPF-record. Hvor mange opslag der spares, afhænger af, hvad de inkluderede records selv indeholder – tæl efter igen med en validator.

Underdomæner, alignment og DMARC

SPF tjekker den adresse, der står i envelope-afsenderen (Return-Path), ikke nødvendigvis den, modtageren ser i Fra-feltet. DMARC kræver, at mindst én af SPF eller DKIM både består og passer til Fra-domænet. Mange nyhedsbrevs- og CRM-tjenester bruger deres eget Return-Path-domæne, og så hjælper din include ikke på DMARC alligevel – det er DKIM-signaturen med dit domæne, der bærer.

Derfor er et eget underdomæne til bulkmail ofte den bedste arkitektur: hoveddomænets SPF forbliver kort, nyhedsbrevets omdømme holdes adskilt fra den daglige mail, og det bliver lettere at stramme DMARC senere – se guiden om spoofing og DMARC-stramning. Grundbegreberne står i SPF, DKIM og DMARC forklaret.

Verifikation

Rettelsen er dokumenteret, når en SPF-validator tæller 10 eller færre opslag uden fejl og uden void lookups, 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 svar kan hænge i cachen til TTL’en udløber). Send også en testmail fra hvert af de systemer, der står i recorden.

Notér i én linje, hvad hver mekanisme i recorden dækker – så er næste oprydning en femminutters opgave. Tjek totalen igen, hver gang I tager en ny mailtjeneste i brug. Og er du på Hostious mail-hosting, hjælper supporten gerne med at gennemgå recorden.

Læs også

• Hub: Mail: fejl og fejlfinding
• SPF, DKIM og DMARC forklaret
• DMARC-rapporten siger fail
• Gmail afviser din mail
• SMTP-porte 25, 465 og 587
• Email hosting hos Hostious – IMAP, SMTP og webmail med spam- og virusfilter

Ofte stillede spørgsmål om SPF-opslag

Tæller ip4- og ip6-mekanismer med i de 10?

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.

Hvorfor kom fejlen pludselig – vi har intet ændret?

Fordi en af jeres tjenester ændrede deres SPF-include, så den nu koster flere opslag, eller fordi en inkluderet record er forsvundet og giver void lookups. Jeres record er den samme – træet under den ændrede sig. Derfor bør totalen tjekkes efter hver ny mailtjeneste og et par gange om året.

Er „flattening“ af SPF en god løsning?

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 og underdomæner den holdbare vej.

Skal jeg bruge ptr i min SPF-record?

Nej. Standarden fraråder ptr, fordi den er langsom og upålidelig og koster opslag. Nogle modtagere ignorerer den. Erstat den med ip4- og ip6-adresser eller en include fra den tjeneste, der sender.