Du har sat SPF op korrekt - syntaksen er rigtig, recorden er publiceret, og alligevel ender dine mails i spam eller bliver afvist. Årsagen er muligvis den fejl, de færreste kender til: 10-lookup-grænsen. Den rammer især virksomheder, der bruger flere cloud-tjenester til email, og den er fuldstændig usynlig, indtil den begynder at skabe problemer.
Hvad SPF-specifikationen siger om DNS-lookups
SPF-records virker ved at modtagerens mailserver slår dit domænes SPF-record op i DNS og verificerer, om den afsendende IP-adresse er godkendt. Det lyder enkelt - men SPF-specifikationen i RFC 7208 sætter en hård grænse: en SPF-evaluering må maksimalt udføre 10 DNS-lookups. Det gælder den samlede kæde af lookups, inklusive alle indlejrede include-mekanismer.
Overskrider din SPF-record denne grænse, returnerer modtagerens mailserver resultatet permerror - en permanent fejl. Det betyder i praksis, at din SPF-record behandles som ugyldig, og afsendelse fra dit domæne kan fejle autentificering. Kombineret med en DMARC-politik på reject eller quarantine betyder det direkte afvisning eller spamplacering.
Hvorfor grænsen eksisterer
Grænsen er ikke vilkårlig. Når en modtager-mailserver evaluerer SPF, skal den udføre DNS-opslag i realtid - for hvert enkelt include, hvert a-opslag, hvert mx-opslag. Uden en grænse kunne en SPF-record med mange indlejrede includes tvinge modtagerens DNS-resolver til at udføre snesevis af opslag per email. Det ville udgøre en potentiel angrebsflade mod DNS-infrastrukturen og skabe unødig belastning på navneservere verden over. 10 lookups er et kompromis mellem fleksibilitet og ressourcebeskyttelse.
Hvad der tæller som et lookup - og hvad der ikke gør
Mange fejlkonfigurationer opstår, fordi man ikke ved præcis, hvad der tæller med i de 10 tilladte lookups. Her er forskellen:
Tæller med i lookup-grænsen:
include: Hvert
include:-direktiv koster ét lookup - og hvis det inkluderede domæne selv harinclude-direktiver, tæller de også med i din samlede kvote.a: Slår A- eller AAAA-records op for et domæne. Koster ét lookup per forekomst.
mx: Slår MX-records op for et domæne. Koster ét lookup mod den samlede grænse. De efterfølgende A/AAAA-opslag for hvert MX-hostname tæller ikke mod de 10 - de er underlagt en separat grænse på maks. 10 adresseopslag per MX-record.
ptr: Reverse DNS-opslag. Frarådes i RFC 7208 og koster dyrt i lookups.
exists: Udfører et A-opslag på et konstrueret domænenavn. Ét lookup per forekomst.
Tæller ikke med i lookup-grænsen:
ip4: og ip6: Direkte IP-adresser eller CIDR-ranges kræver ingen DNS-opslag og tæller ikke.
all: Afslutningsmekanismen
~all,-alleller?allkræver intet opslag.redirect= Koster ét lookup og tæller med i den samlede grænse på 10 - ligesom include og de øvrige DNS-forespørgsler.
Selve TXT-opslaget på dit eget domæne tæller ikke med i de 10.
Det typiske scenarie der sprænger grænsen
En mellemstor virksomhed bruger i dag sjældent kun én emailudbyder. Et typisk setup ser sådan ud:
Microsoft 365 til intern email:
include:spf.protection.outlook.com- dette inkluderer selv yderligere records og koster typisk 2-3 lookups.Google Workspace til en sekundær konto eller G Suite-integration: include:_spf.google.com - koster typisk 1 lookup (Google forenklede sin SPF-record i december 2025 fra 4 til 1 lookup).
HubSpot til marketing-emails:
include:_spf.hubspot.com- 1-2 lookups.Mailchimp til nyhedsbreve:
include:servers.mcsv.net- 1-2 lookups.Webhostens SMTP til transaktionelle mails: endnu et
include:- 1-2 lookups.
Læg dem sammen, og du er allerede på 10-14 lookups. Grænsen er overskredet, og det sker uden at du har gjort noget forkert i selve konfigurationen - du bruger bare de services, du har brug for.
Sådan identificerer du problemet
Det første skridt er at få et præcist overblik over, hvor mange lookups din SPF-record faktisk bruger. DNSinfos SPF-analyse gennemgår din records fulde lookup-kæde og viser dig det samlede antal DNS-opslag - inklusive alle indlejrede includes. Hvis antallet overstiger 10, markeres det som en fejl.
Analysen er særlig nyttig, fordi den afslører den fulde kæde: hvis include:spf.protection.outlook.com selv inkluderer to yderligere domæner, vises alle tre som separate lookups i din kvote. Det er præcis den type skjult kompleksitet, der gør fejlen svær at opdage manuelt.
Kør analysen på dit primære afsenderdomæne og notér det samlede lookup-antal samt hvilke include-direktiver der bidrager mest.
Løsningsmetoder
Fjern unødvendige includes
Gennemgå din SPF-record kritisk. Bruger du faktisk alle de services, der er listet? Det er ikke ualmindeligt at finde includes fra tidligere emailudbydere, der for længst er skiftet ud, eller fra services, der aldrig sender email på dit domænes vegne. Hvert include, du fjerner, frigiver et lookup i kvoten.
Brug IP-ranges direkte
Nogle emailtjenester offentliggør deres IP-ranges som statiske lister. I stedet for et include:-direktiv, der kræver et DNS-opslag, kan du indsætte IP-adresserne direkte med ip4: eller ip6:. Disse tæller ikke mod lookup-grænsen. Ulempen er, at du manuelt skal opdatere din SPF-record, hvis udbyderen ændrer sine IP-adresser - det kræver vedligeholdelse.
SPF flattening
SPF flattening er den teknik, der løser problemet mest effektivt, men som også kræver mest vedligeholdelse på sigt. Princippet er enkelt: i stedet for at have en SPF-record med mange include-direktiver, opløser du alle includes til de underliggende IP-adresser og indsætter dem direkte i din record med ip4: og ip6:. Resultatet er en flad SPF-record, der bruger nul eller meget få DNS-lookups.
En flattened record kan se sådan ud:
v=spf1 ip4:40.92.0.0/15 ip4:40.107.0.0/16 ip4:52.100.0.0/14 ip4:104.47.0.0/17 ip4:209.85.128.0/17 ip4:66.102.0.0/20 ~allAlle de store IP-blokke er indsat direkte, og recorden kræver ingen yderligere lookups.
Vedligeholdelse er den kritiske faktor ved flattening
SPF flattening løser lookup-problemet - men skaber et nyt: når en emailudbyder ændrer sine IP-adresser, opdaterer de deres egne SPF-records. Bruger du include:, følger din record automatisk med. Bruger du flattening, gør den ikke. Din flattened record bliver forældet, og emails fra den nye IP-adresse vil fejle SPF-validering.
Det er ikke et hypotetisk problem. Microsoft, Google og andre store udbydere justerer løbende deres IP-infrastruktur. En flattened record, der ikke vedligeholdes, kan gå fra at virke perfekt til at skabe leveringsproblemer uden nogen advarsel.
Løsningen er løbende overvågning. Brug DNS-opslag til regelmæssigt at tjekke, om dine emailudbyderes SPF-records har ændret sig, og opdater din flattened record tilsvarende. En god tommelfingerregel er at gennemgå din flattened record minimum hver tredje måned - eller hver gang du ved, at en udbyder har ændret sin infrastruktur.
Vil du have hjælp til at holde øje med DNS-ændringer generelt, kan navneserver-statustjekket bruges til at verificere, at dine nameservere svarer korrekt, og at dine records propagerer som forventet efter en opdatering.
Byg en ren SPF-record der holder sig inden for grænsen
Når du har kortlagt, hvilke services du faktisk sender email fra, og besluttet dig for, om du vil bruge direkte IP-ranges, reducerede includes eller flattening, er næste skridt at bygge en ny, korrekt SPF-record fra bunden.
DNSinfos SPF-generator guider dig igennem processen trin for trin: du vælger dine emailtjenester, angiver eventuelle IP-ranges, og generatoren producerer en korrekt formateret SPF-record. Brug den i kombination med SPF-analysen til at verificere, at den færdige record holder sig under 10 lookups.
Husk at en korrekt SPF-record er kun én del af et komplet emailautentificeringssætup. For at emails ikke afvises eller havner i spam, bør SPF suppleres med DKIM og DMARC. DMARC-guiden beskriver, hvordan du implementerer alle tre lag i sammenhæng.
10-lookup-grænsen er en af de mest underrapporterede årsager til SPF-fejl - men den er fuldt ud løselig. En velvedligeholdt, flattened SPF-record med direkte IP-ranges giver dig kontrol over leveringsevnen og holder dig under grænsen, uanset hvor mange emailtjenester du bruger.
