E-postkoll: SPF, DKIM och DMARC
Kontrollera om en domän har korrekt e-postautentisering. Vi slår upp SPF, DMARC, DKIM (vanliga selektorer) och MX-poster, det som avgör om dina mejl når fram.
Så tolkar du resultatet
Verktyget slår upp fyra typer av DNS-poster och visar dig exakt vad som ligger publicerat för domänen. Det är samma information som mottagande mejlservrar (Gmail, Outlook, ditt eget webbhotells mejlserver) läser av varje gång ett mejl anländer. Problemet är att posterna i sig är kryptiska. En rad som "v=spf1 +a +mx include:_spf.exempel.se ~all" säger ingenting om den är bra eller dålig förrän du vet vad varje del betyder.
SPF-posten (Sender Policy Framework) listar vilka servrar som får skicka e-post i domänens namn. Tänk på den som en förteckning över godkända avsändare. Står webbhotellets mejlserver eller ert nyhetsbrevsverktyg inte med i listan, kan mottagaren misstänka förfalskning även om mejlet i övrigt ser helt legitimt ut.
DKIM (DomainKeys Identified Mail) fungerar annorlunda. Där SPF pekar ut avsändande servrar lägger DKIM istället en kryptografisk signatur i varje utgående mejl, kopplad till en publik nyckel som ligger i DNS. Mottagaren kan då bevisa att innehållet inte manipulerats på vägen och att det faktiskt skickades av den domän som anges i signaturen.
DMARC bygger vidare på de två andra. Den är domänägarens egen instruktion till mottagaren om vad som ska hända när ett mejl misslyckas med SPF eller DKIM. Ska det avvisas direkt, hamna i skräpposten, eller ska mottagaren bara notera felet och släppa igenom mejlet ändå. Utan en DMARC-post finns ingen sådan instruktion alls, och mottagaren avgör själv efter eget gottfinnande. Vill du ha grundförklaringen i mer detalj finns den i vår FAQ om SPF, DKIM och DMARC.
MX-posterna (Mail Exchanger) är enklare. De talar om vart inkommande e-post till domänen ska levereras, det vill säga vilken server som faktiskt tar emot mejlen. Pekar de på webbhotellets egna mejlservrar hanteras posten där. Pekar de istället på Google eller Microsofts adresser ligger e-posten hos Google Workspace eller Microsoft 365, oavsett var själva webbplatsen driftas.
Vanliga utfall och vad de faktiskt betyder
Samma DNS-svar tolkas ofta fel. Här är fem utfall som regelbundet misstolkas.
| Vad du ser i resultatet | Vad det betyder i praktiken |
|---|---|
| SPF-posten slutar på ~all | Mjukt fall (soft fail). Mottagaren bör flagga mejl från servrar utanför listan som misstänkta, men behöver inte avvisa dem. Ett vanligt mellanläge, ofta medvetet valt under en övergångsperiod. |
| SPF-posten slutar på -all | Hårt fall (hard fail). Mottagaren uppmanas att avvisa mejl från servrar som inte finns med. Strängare, men kräver att listan faktiskt är komplett, annars stoppas legitima mejl. |
| Domänen har DMARC med p=none | Endast mätning. DMARC-posten samlar in rapporter om vad som händer, men ger ingen faktisk instruktion om avvisning. Många domäner fastnar här permanent, vilket ger noll skydd mot förfalskning trots att posten finns. |
| Flera SPF-poster på samma domän | Ogiltigt enligt SPF-specifikationen. En domän får bara ha en enda SPF-post. Finns det två kan hela kontrollen fallera, och resultatet blir ofta värre än att inte ha någon SPF-post alls. |
| Ingen DKIM-träff på de vanliga selektorerna | Betyder inte automatiskt att DKIM saknas. Verktyget testar ett antal vanliga selektornamn som leverantörer brukar använda. En del webbhotell och e-postsystem väljer en egen, unik selektor som inte finns med i den listan. Ett negativt resultat här är alltså en indikation, inte ett definitivt facit. |
När du byter webbhotell eller flyttar e-post
Här uppstår ett av de vanligaste misstagen. SPF, DKIM och DMARC-posterna följer inte med automatiskt när e-posten flyttas till en ny leverantör eller när webbplatsen bytt webbhotell. Posterna ligger kvar och pekar mot den gamla mejlservern tills någon aktivt uppdaterar dem hos den nya. Resultatet blir att mejl som skickas från det nya systemet plötsligt saknar godkänd SPF-träff, trots att allt annat fungerar som väntat.
Det är särskilt vanligt vid byte av mejlserver för WordPress-installationer, där formulärutskick och transaktionsmejl helt plötsligt börjar hamna i mottagarens skräppost efter en flytt. Vi går igenom just det scenariot i artikeln om varför WordPress-mejl fastnar i spam.
Kraven har dessutom skärpts på senare år. Gmail och Outlook (Microsoft) ställer numera egna minimikrav på avsändarautentisering för att över huvud taget ta emot e-post från en domän utan att flagga eller avvisa den. Skickar du större volymer, till exempel nyhetsbrev eller transaktionsmejl från en webbutik, är korrekt SPF, DKIM och en fungerande DMARC-post i praktiken inte längre valfritt. Vi beskriver de skärpta kraven närmare i Outlooks nya DMARC-krav. Vill du förstå spamfiltrering mer allmänt finns bakgrunden i varför e-post hamnar i skräpposten.
Vad verktyget inte kan se
Vi läser uteslutande publika DNS-poster, samma information som vem som helst kan slå upp. Det ger en korrekt bild av vad domänen publicerar, men inte av hur ett enskilt mejl faktiskt behandlades hos en specifik mottagare. Gmail, Outlook och andra tillämpar egna regler ovanpå SPF, DKIM och DMARC, bland annat baserat på avsändarens historik och innehållet i mejlet. En korrekt konfigurerad domän är en förutsättning för god leverans, men ingen garanti i sig. Den fullständiga tekniska specifikationen för DMARC finns för den som vill gå på djupet i RFC 7489.
Vad gör du nu
Ser resultatet ovan ofullständigt ut går det inte att fixa i själva e-postprogrammet. SPF, DKIM och DMARC är alla DNS-poster, och de ändras hos den som hanterar domänens namnservrar. I de flesta fall är det webbhotellet eller registraren där domänen ligger. Har du flyttat webbplatsen men inte e-posten (eller tvärtom) är det första du bör kontrollera vem som faktiskt äger DNS-hanteringen just nu, eftersom det avgör var ändringen ska göras.