SPF-posten som tyst slutar gälla: tio-uppslagsgränsen och PermError-fällan för växande företag

Leveransen faller för alla mottagare samtidigt, utan förvarning

Det brukar se ut ungefär så här. En vardagsförmiddag, några dagar efter en helt rutinmässig ändring i DNS, slutar plötsligt mejl komma fram. Inte till en enstaka mottagare eller ett enstaka system, utan till Gmail, Outlook och de flesta andra stora leverantörer samtidigt. Inget felmeddelande dyker upp i det egna e-postsystemet. SPF-posten går att slå upp, den ser fullt läsbar ut, och den innehåller inget uppenbart syntaxfel. Ändå studsar mejlen eller hamnar i skräpposten hos mottagaren.

Det mönstret, leverans som faller utan att något i sak har ändrats, är nästan alltid ett tecken på en post som slutat fungera snarare än ett plötsligt försämrat avsändarrykte. Den vanligaste orsaken är samtidigt den minst intuitiva. Posten har inte blivit trasig av ett misstag. Den har blivit trasig av att någon lade till ett korrekt, välmotiverat tillägg för elfte gången.

Mekaniken bakom PermError, förankrad i RFC 7208

SPF (Sender Policy Framework) begränsar hur många DNS-uppslag en mottagande server får göra när den validerar en avsändardomän. Gränsen är satt till tio, och den finns beskriven i RFC 7208, avsnitt 4.6.4, standarddokumentet som definierar SPF:

"SPF implementations MUST limit the total number of those terms to 10 during SPF evaluation, to avoid unreasonable load on the DNS. If this limit is exceeded, the implementation MUST return 'permerror'."

Det centrala ordet är MUST. Det är inte en rekommendation utan ett krav på implementationen. Överskrids taket ska mottagarens SPF-motor returnera permerror, ett permanent fel som säger åt den mottagande servern att behandla hela domänens SPF-post som om den inte fanns. Inte "svagare skydd", inte "delvis giltig". Hela posten upphör att gälla för alla avsändare under domänen, oavsett hur korrekt just deras del av posten är.

Vilka mekanismer som räknas mot taket på tio är avgörande att förstå, eftersom det inte är alla rader i en SPF-post som kostar ett uppslag. Termerna include, a, mx, ptr och exists räknas, liksom modifieraren redirect. Däremot kostar ip4, ip6, all och exp ingenting, eftersom de inte kräver ett eget DNS-uppslag för att tolkas. Det gör att en post med tio råa IP-adresser är helt riskfri, medan en post med tre include-rader kan vara långt farligare, särskilt om någon av dem i sin tur nästlar ytterligare include-rader. Nästlingen är kumulativ. Ett tillägg som ser ut som en enda rad i den egna posten kan dra med sig flera dolda uppslag hos leverantören bakom den.

Utöver taket på tio finns en mindre känd, separat gräns för så kallade void lookups, DNS-uppslag som inte ger något svar alls:

"SPF implementations SHOULD limit 'void lookups' to two. ... Exceeding the limit produces a 'permerror' result."

I praktiken innebär det att en post även kan fällas av döda includes, alltså rester som pekar mot domäner eller poster som inte längre svarar. Två sådana räcker.

Varför felet gömmer sig och pekas fel

PermError är särskilt lömskt eftersom felet aldrig syns hos avsändaren. Det finns ingen varning i det egna e-postsystemet, ingen logg att titta i, ingen bekräftelse som säger "din post är för lång". Felet uppstår enbart hos mottagaren, som en rad i autentiseringsresultatet (Authentication-Results-huvudet), och den raden når sällan tillbaka till avsändaren om denne inte aktivt letar efter den.

Symptomet förstärker dessutom missförstånd, eftersom leveransproblem sällan slår av som en strömbrytare. Vissa mottagare greylistar, andra sänker successivt avsändarens rykte, en tredje grupp levererar ändå men till skräpposten. Den gradvisa nedgången pekar felsökningen mot precis fel håll, mot IP-rykte, mot innehållet i mejlen, mot spamfilter hos mottagaren, snarare än mot den DNS-post som faktiskt orsakar problemet. Samma diagnostiska förvirring uppstår för övrigt när WordPress-installationer plötsligt tappar mejl i skräpposten, där felsökningen ofta börjar i fel ände av kedjan.

Den svenska webbhotellsstacken ärver en baslinje innan kunden lägger till något

Tio-gränsen är extra relevant för svenska företag av en anledning som lätt missas. Den börjar sällan räknas från noll. Ett webbhotells egen SPF-include, den som pekar mot hostens utgående mejlservrar, är redan en del av kundens post från dag ett. Kunden ärver den baslinjen, och lägger sedan sina egna tjänster ovanpå.

Så här ser det ut i de offentliga DNS-posterna för tre svenska webbhotell, kontrollerade den 8 augusti 2026. Samtliga poster nedan är korrekt formaterade och avslutas med -all, det här är ingen granskning av hostarnas kvalitet. Poängen är hur stor del av taket på tio som redan är förbrukad innan kunden gjort ett enda eget tillägg.

Oderlands post landar på fem uppslag redan i grundutförandet, eftersom a räknas som ett uppslag och en av de tre includes (mailrelay/rrpproxy) i sin tur nästlar ytterligare en. Inleeds post innehåller fem includes i toppnivån, varav en nästlar ytterligare ett steg, vilket ger sex uppslag totalt. Loopias post däremot håller sig mager, bara mx plus råa IP-adresser, vilket kostar ett enda uppslag. Grundnivån varierar alltså kraftigt mellan hostar, och det är den nivån kunden bygger vidare på, sällan medveten om att den redan finns där.

Ovanpå den baslinjen lägger en växande svensk verksamhet i praktiken flera tjänster efter hand. Vanliga tillägg är webbhotellets egen e-post, Google Workspace eller Microsoft 365 för den centrala mejlen, en nyhetsbrevstjänst som Get a Newsletter, MailerLite eller Mailchimp, ordermejl från e-handelsplattformen, samt ett boknings- eller CRM-system som skickar bekräftelser. Var och en av dessa tillägg är i sig korrekt. Get a Newsletters egen rekommenderade post, v=spf1 a mx include:spf.gansend.com include:_spf.google.com -all, är själv flera uppslag djup innan den ens läggs till hos kunden. Det är sällan det tionde eller elfte tillägget som är felaktigt skrivet, det råkar bara fälla helheten.

Standardrådet, inklusive vårt eget i FAQ:n om SPF, DKIM och DMARC, brukar formuleras som "lägg till varje tjänsts servrar i SPF-posten" utan att samtidigt varna för taket på tio. Rådet är korrekt ända fram till den dag det plötsligt inte längre är det, och övergången sker utan varning för den som följer det.

Att räkna uppslagen är enda sättet att upptäcka problemet i förväg

Att bara läsa SPF-posten och konstatera att den "ser rimlig ut" avslöjar ingenting om hur nära taket domänen befinner sig. Det som krävs är en genomgång som räknar rekursivt, det vill säga som går in i varje include, räknar dess a-, mx-, ptr- och exists-termer, går vidare in i eventuella nästlade include-rader, och summerar hela vägen mot taket på tio. En post som visuellt är kort kan ändå ligga farligt nära gränsen om den innehåller en eller två includes som i sin tur är djupa. Principen är enkel att beskriva men lätt att missa i praktiken, eftersom ingenting i själva DNS-svaret varnar för att räkningen börjar närma sig taket. Vår e-postkollare gör just den rekursiva genomgången: den följer varje include-rad ett steg i taget, räknar termerna mot RFC-taket på tio och flaggar posten som permerror, varning eller ok, så att en post som ligger farligt nära gränsen syns innan den tippar över.

Två vägar att fixa problemet, bara en av dem håller över tid

När taket väl är nått finns i grunden två typer av åtgärder, och de skiljer sig kraftigt i hur hållbara de är.

Den hållbara vägen handlar om att städa och strukturera om. Obsoleta includes, alltså poster för tjänster verksamheten slutat använda för länge sedan men aldrig tog bort ur SPF-posten, bör rensas bort först. Därefter går det att avlasta genom att dela upp avsändande domäner på subdomäner (så att exempelvis nyhetsbrev skickas från en egen subdomän med sin egen, kortare SPF-post) och genom att undvika onödiga a-, mx- och ptr-mekanismer där de inte faktiskt behövs.

Den tyst-havererande vägen kallas ofta SPF-flattening. Metoden går ut på att byta ut varje include mot de råa IP-adresser som just då ligger bakom den, eftersom IP-adresser som sagt inte räknas mot taket. Det sänker uppslagsräkningen omedelbart, men löser inte problemet, utan skjuter det bara framåt i tiden. Google och Microsoft, liksom svenska tjänster som Get a Newsletter, ändrar sina utgående IP-block då och då, utan att meddela varje kund som flattenat sin post. En flattenad post glider därför tyst bort från verkligheten. Antingen slutar den auktorisera IP-adresser som fortfarande är i bruk, vilket ger nya leveransproblem, eller så fortsätter den auktorisera adresser som tjänsten inte längre använder, vilket är en säkerhetslucka snarare än ett leveransproblem. Att poster faktiskt ändras över tid går att belägga konkret. Oderlands egen SPF-post läste annorlunda tidigare samma dygn som kontrollen ovan gjordes, och hade redan hunnit ändras vid en senare avstämning. Om en hosts egen post kan skifta inom ett dygn, är en flattenad kopia av den dömd att bli inaktuell förr eller senare.

Samma resonemang gäller vid ett hostbyte. Den som flyttar e-post till ett nytt webbhotell byter samtidigt ut hela den ärvda SPF-baslinjen, vilket är ett naturligt tillfälle att räkna om hela posten från grunden snarare än att bara byta ut en include och anta att resten fortfarande stämmer.

SPF kräver löpande underhåll, ingen post man konfigurerar en gång för alla

En SPF-post är inte en engångskonfiguration utan en levande del av företagets DNS, som bör ses över varje gång en tjänst tillkommer eller försvinner. Det gäller särskilt i takt med att fler mottagare skärper sina krav på e-postautentisering, en utveckling som även syns i hur Outlook successivt kräver DMARC för att mejl över huvud taget ska nå fram. En post som aldrig städas växer sig till slut förbi taket på tio, tyst, utan felmeddelande, och utan att något i posten någonsin såg trasigt ut.