SPF PermError: for mange DNS-oppslag – slik fikser du det

2026-09-26 · 9 min lesetid · Av MailWatch-teamet

SPF-feilen PermError: too many DNS lookups betyr at SPF-posten din krever mer enn 10 DNS-oppslag for å bli evaluert, som er grensen i SPF-standarden (RFC 7208). Mottakeren gir da opp og behandler SPF som ugyldig for all e-post fra domenet. Løsningen er å redusere antall oppslag: fjern tjenester du ikke bruker, flytt markedsførings- og systemutsendelser til egne subdomener, og bruk IP-adresser direkte der det er trygt.

Kort fortalt:

SPF har en hard grense på 10 DNS-oppslag. include, a, mx, ptr, exists og redirect teller – ip4, ip6 og all gjør det ikke.
Nestede include-er teller også: én include kan koste flere oppslag.
I tillegg er det maks 2 «void lookups» (oppslag som ikke gir svar) før du får PermError.
Den beste løsningen er som regel opprydding og subdomener per tjeneste – ikke flattening.

Hva betyr SPF PermError egentlig?

SPF (Sender Policy Framework) er en TXT-post i DNS som lister hvilke servere som får sende e-post på vegne av domenet ditt. Er du usikker på grunnprinsippene, kan du lese vår innføring i hva SPF er først.

Når en mottakende server sjekker SPF, må den ofte gjøre flere DNS-oppslag for å finne alle IP-adressene som er tillatt. For å hindre at SPF blir misbrukt til å belaste DNS-servere, setter RFC 7208 (seksjon 4.6.4) en grense: evalueringen skal ikke bruke mer enn 10 mekanismer og modifikatorer som krever DNS-oppslag. Blir grensen overskredet, skal resultatet være permerror – en permanent feil som ikke går over av seg selv.

Konsekvensen er at SPF ikke lenger gir pass for noen av avsenderne dine. Med DMARC betyr det at du bare står igjen med DKIM som mulig vei til DMARC-pass. Mangler DKIM hos en av tjenestene, eller er signaturen ikke alignet, feiler DMARC – og med p=quarantine eller p=reject havner e-posten i søppelpost eller blir avvist.

Viktig: Noen mottakere er tolerante og evaluerer likevel, andre stopper nøyaktig ved oppslag nummer 11. Gmail og Microsoft følger grensen. At det «fungerer hos deg» er derfor ingen garanti for at det fungerer hos kundene dine.

Slik teller du DNS-oppslag i SPF

Det er ikke antall ord i SPF-posten som teller, men antall oppslag mottakeren må gjøre. Reglene er:

Mekanisme / modifikator	Teller som oppslag?	Kommentar
`include:`	Ja, 1 + alt inni	Alle oppslag i den inkluderte posten teller også
`a` / `a:`	Ja, 1	Slår opp A/AAAA for domenet
`mx` / `mx:`	Ja, 1	I tillegg maks 10 MX-navn som slås opp
`ptr`	Ja, 1	Frarådet i RFC 7208 – bør fjernes
`exists:`	Ja, 1	Brukes bl.a. av Salesforce
`redirect=`	Ja, 1 + alt inni	Som include, men erstatter hele posten
`ip4:` / `ip6:`	Nei	Ingen DNS-oppslag
`all`	Nei	Ingen DNS-oppslag

Et typisk eksempel

Her er en SPF-post vi ofte ser hos norske bedrifter som har vokst med nye verktøy over tid:

firma.no. TXT "v=spf1 a mx include:spf.protection.outlook.com
  include:_spf.google.com include:servers.mcsv.net
  include:sendgrid.net include:mail.zendesk.com
  include:_spf.salesforce.com include:spf.webhotell.no
  include:spf.regnskapssystem.no ~all"

Tell opp: a (1) + mx (1) + åtte include-er (8) = 10 allerede før vi har sett inni noen av dem. Inkluderer sendgrid.net en ny include (det gjør den), og webhotellets post inneholder en a og en mx, er du fort oppe i 13–14. Resultat: PermError.

Leverandørene endrer også sine egne SPF-poster uten å varsle deg. En post som var på 9 oppslag i fjor, kan være på 11 i dag uten at du har rørt den. Derfor bør du både telle manuelt og overvåke løpende.

Slik sjekker du selv

Hent SPF-posten: dig +short TXT firma.no (eller nslookup -type=txt firma.no på Windows).
For hver include og redirect: slå opp den posten og tell oppslagene inni, rekursivt.
Legg til 1 for hver a, mx, ptr og exists.
Noter også oppslag som returnerer NXDOMAIN eller tomt svar – de er «void lookups».

Det er tungvint å gjøre for hånd. Du kan sjekke domenet ditt gratis med MailWatch, som teller alle oppslag rekursivt og viser hvilke include-er som koster mest.

MailWatch SPF-verktøy som viser mekanismene i SPF-posten og totalt antall DNS-oppslag — SPF-verktøyet i MailWatch viser hver mekanisme, hvor mange oppslag den koster, og om du er over grensen på 10.

Void lookups: den andre grensen

RFC 7208 har en mindre kjent grense i tillegg: maks 2 void lookups. Et void lookup er et DNS-oppslag som gir NXDOMAIN (domenet finnes ikke) eller et tomt svar. Typiske årsaker:

En include til en tjeneste du har sagt opp, der leverandøren har fjernet SPF-posten sin.
Skrivefeil, for eksempel include:spf.protection.outlok.com.
a: eller mx: som peker på et vertsnavn som ikke lenger eksisterer.

Tre slike oppslag gir PermError, selv om totalen er godt under 10. Void lookups er dessuten et tegn på at posten ikke er vedlikeholdt, så rydd dem bort uansett.

Steg 1: Fjern det du ikke bruker

Den raskeste gevinsten er nesten alltid opprydding. Gå gjennom hver mekanisme og spør: sender denne tjenesten faktisk e-post med vårt domene i avsenderadressen (Return-Path/envelope-from) i dag?

Gamle tjenester: Nyhetsbrevverktøy, CRM-er og webhoteller dere har sluttet å bruke. Fjern dem.
a og mx: Sender webserveren eller MX-serveren din faktisk e-post? Hvis du bruker Microsoft 365 eller Google Workspace, er MX-ene deres allerede dekket av leverandørens include. mx er ofte ren sløsing.
ptr: Frarådet i standarden, tregt og upålitelig. Fjern.
Tjenester som bruker eget Return-Path-domene: Mange moderne tjenester (f.eks. SendGrid, Mailchimp/Mandrill, HubSpot) bruker sitt eget eller et eget subdomene i envelope-from og oppnår DMARC via DKIM. Da trenger de ikke stå i SPF-posten på hoveddomenet i det hele tatt. Sjekk leverandørens dokumentasjon.

Tips: Usikker på hvem som faktisk sender? DMARC-aggregatrapporter viser alle IP-er som har sendt e-post med domenet ditt de siste dagene. Se slik leser du DMARC-rapporter – det er den sikreste måten å finne ut hva som trygt kan fjernes.

Steg 2: Bruk subdomener for e-posttjenester

Den mest robuste løsningen for bedrifter med mange avsendere er å gi hver type utsendelse sitt eget subdomene. SPF evalueres mot domenet i envelope-from (Return-Path), og hvert subdomene har sin egen SPF-post med sin egen grense på 10 oppslag.

; Hoveddomenet: kun ansattes e-post
firma.no.             TXT "v=spf1 include:spf.protection.outlook.com -all"

; Nyhetsbrev
nyhet.firma.no.       TXT "v=spf1 include:servers.mcsv.net -all"

; Kundeservice / helpdesk
support.firma.no.     TXT "v=spf1 include:mail.zendesk.com -all"

; Fakturaer og systemvarsler fra nettbutikken
varsel.firma.no.      TXT "v=spf1 include:sendgrid.net -all"

Fordelene er flere enn bare færre oppslag:

Omdømmet skilles: Får et nyhetsbrev mange spamklager, rammer det i mindre grad e-posten fra ansatte.
Enklere feilsøking: Du ser i DMARC-rapportene hvilken tjeneste som sender hva.
DMARC fungerer fortsatt: Med standard «relaxed alignment» i DMARC godtas nyhet.firma.no som alignet med firma.no i From-adressen. Kunden ser fortsatt post@firma.no som avsender hvis du vil.

Hvordan du setter opp subdomene varierer: hos de fleste ESP-er heter det «custom return-path», «bounce domain» eller «domain authentication». Husk å sette opp DKIM for subdomenet samtidig. Planlegger du å stramme inn DMARC, er guiden fra p=none til p=reject nyttig.

Steg 3: Bruk ip4/ip6 for egne servere

Har du egne servere med faste IP-adresser – en ERP-server, en skanner/multifunksjonsmaskin som sender via egen relé, eller en VPS for nettbutikken – er det bedre å oppgi IP-en direkte enn å bruke a:server.firma.no. ip4: og ip6: koster ingen oppslag.

firma.no. TXT "v=spf1 ip4:203.0.113.25 include:spf.protection.outlook.com -all"

Dette er trygt for adresser du selv kontrollerer. Husk å oppdatere SPF hvis serveren bytter IP.

Steg 4: SPF-flattening – fordeler og ulemper

«Flattening» betyr å erstatte include-er med IP-adressene de peker på, slik at hele posten består av ip4/ip6 og nesten ikke krever oppslag. Det løser grensen umiddelbart, men har reelle ulemper:

Fordeler	Ulemper
Løser 10-oppslagsgrensen med én gang	Leverandører endrer IP-ene sine uten varsel – statisk flattening blir utdatert og legitim e-post feiler
Raskere evaluering hos mottaker	Posten kan bli for lang (TXT-strenger på maks 255 tegn, og svar over 512 byte kan kreve TCP)
Du ser nøyaktig hvilke IP-er som er tillatt	Store leverandører har mange nettverk – du risikerer å godkjenne store IP-områder unødvendig
	Makro-baserte poster (som Salesforce sin `exists:%{i}...`) kan ikke flates ut

Vil du flate ut, bør det gjøres med en tjeneste som oppdaterer posten automatisk når leverandøren endrer seg – og kun for de include-ene som er nødvendige. Manuell, engangs flattening er en av de vanligste årsakene til at e-post plutselig begynner å feile måneder senere. Vår anbefaling: rydd opp og bruk subdomener først. Flattening er siste utvei.

Andre vanlige SPF-feil å sjekke samtidig

To SPF-poster: Et domene skal ha nøyaktig én TXT-post som starter med v=spf1. To poster gir også PermError. Slå dem sammen.
+all: Godkjenner hele internett. Bruk ~all eller -all.
Syntaksfeil: Mellomrom etter kolon (include: spf...), manglende v=spf1 eller feil anførselstegn.
SPF-posten er for lang: Del lange poster i flere strenger innenfor samme TXT-post, maks 255 tegn per streng.

Ofte stilte spørsmål

Hvor mange DNS-oppslag kan en SPF-post ha?

En SPF-post kan maksimalt utløse 10 DNS-oppslag under evaluering, ifølge RFC 7208. Mekanismene include, a, mx, ptr, exists og modifikatoren redirect teller, inkludert alle oppslag i nestede include-er. ip4, ip6 og all teller ikke.

Hva skjer hvis SPF har mer enn 10 oppslag?

Mottakeren returnerer SPF-resultatet PermError, og SPF gir ikke pass for noe e-post fra domenet. Da må DMARC bestå via DKIM alene. Tjenester uten korrekt DKIM-signatur vil feile DMARC, og med en streng DMARC-policy blir e-posten lagt i søppelpost eller avvist.

Hva er et void lookup i SPF?

Et void lookup er et DNS-oppslag under SPF-evalueringen som gir NXDOMAIN eller et tomt svar, for eksempel en include til en tjeneste som ikke lenger finnes. RFC 7208 tillater maks 2 slike. Ved det tredje blir resultatet PermError, uavhengig av totalt antall oppslag.

Er SPF-flattening en god idé?

Flattening løser oppslagsgrensen, men statiske IP-lister blir utdaterte når leverandørene endrer nettverkene sine, og da feiler legitim e-post. Det bør bare brukes med automatisk oppdatering, og etter at du har ryddet bort ubrukte include-er og flyttet tjenester til subdomener.

Hjelper det å bruke subdomener for nyhetsbrev og systemvarsler?

Ja. Hvert subdomene har sin egen SPF-post og sin egen grense på 10 oppslag, så hoveddomenet slipper å inkludere alle tjenestene. I tillegg skilles omdømmet mellom markedsføring og vanlig e-post, og DMARC fungerer fortsatt med relaxed alignment.

Hvorfor fikk jeg PermError selv om jeg ikke har endret SPF-posten?

Leverandørene du inkluderer kan ha endret sine egne SPF-poster, for eksempel lagt til en ny nestet include. Da øker antall oppslag hos deg uten at du har rørt noe. Løpende overvåking av SPF fanger opp slike endringer før de rammer e-postleveransen.

Oppsummering

SPF PermError på grunn av for mange DNS-oppslag er en av de vanligste – og mest unødvendige – årsakene til at e-post feiler autentisering. Tell oppslagene rekursivt, fjern tjenester du ikke bruker, flytt utsendelsestjenester til egne subdomener og bruk ip4/ip6 for egne servere. Fordi leverandører endrer postene sine over tid, lønner det seg å overvåke SPF løpende. MailWatch teller oppslagene dine automatisk og varsler deg på e-post, SMS eller Pushover hvis grensen overskrides. Du kan prøve gratis i 30 dager uten kredittkort.

Prøv MailWatch gratis i 30 dager · Sjekk domenet ditt gratis