SPF: vem får skicka e-post i din domäns namn?

Modul 4: Poster för e-post · Lästid: 10 minuter

Lärandemål: Efter den här lektionen kan du läsa en SPF-post, lägga till en tjänst korrekt och undvika de tre vanligaste SPF-felen: två poster, +all och fler än tio uppslagningar.

Nyckelbegrepp: SPF, v=spf1, mekanism (a, mx, ip4, ip6, include), kvalifikator (+ - ~ ?), all, en enda SPF-post, gräns på 10 DNS-uppslagningar, envelope-avsändare (Return-Path)

Problemet: vem som helst kan använda ditt namn

E-post uppfanns på 1980-talet för ett litet, vänligt internet. Vilken mailserver som helst kan skicka ett mejl med avsändaren info@example.com, även om den servern inte har något som helst med example.com att göra. Bedragare utnyttjar det gärna.

SPF (Sender Policy Framework, RFC 7208) är ett första steg för att förhindra det. I en SPF-post anger du vilka servrar som får skicka e-post i din domäns namn. En mottagande mailserver kontrollerar vid varje inkommande mejl: kommer det här mejlet från en server som finns på listan?

Se det som en gästlista vid en dörr. Dörrvakten (den mottagande mailservern) hämtar listan från din domän och kontrollerar om besökaren (den sändande servern) står på den.

Hur ser en SPF-post ut?

En SPF-post är en TXT-post på ditt domännamn som börjar med v=spf1:

example.com.  3600  IN  TXT  "v=spf1 mx ip4:192.0.2.25 include:spf.mailer.example ~all"

Du läser den från vänster till höger. Mottagaren går igenom delarna en i taget och stannar vid den första som stämmer.

Slutet: ~all, -all, ?all eller +all

Framför varje del kan det stå ett tecken som anger vad som händer om det stämmer. Vid all (som alltid stämmer) gör det tecknet all skillnad:

Står det inget tecken gäller +. mx betyder alltså +mx.

Vilken väljer du? ~all är ett säkert standardval. -all är strängare och bra om du är helt säker på att alla dina avsändare finns med i posten. Använder du DMARC (lektion 4.5) avgör DMARC-policyn i slutändan vad som händer; många administratörer väljer då ~all.

Fel 1: två SPF-poster

Det får bara finnas en SPF-post per domän. Hittar mottagaren två blir resultatet ett fel (permerror) och din SPF räknas inte alls. Det är värre än ingen SPF.

Det här går ofta fel i praktiken. En nyhetsbrevstjänst eller Microsoft 365 säger "lägg till den här SPF-posten", och plötsligt finns det en andra v=spf1-post vid sidan av den gamla. Lösningen: lägg till den nya tjänsten i den befintliga posten.

Fel:

"v=spf1 mx include:spf.oldhost.example ~all"
"v=spf1 include:spf.protection.outlook.com -all"

Rätt:

"v=spf1 mx include:spf.oldhost.example include:spf.protection.outlook.com ~all"

Tänk på att inte ta bort servrar du fortfarande använder när du slår ihop poster. Skickar din webbplats e-post via ditt webbhotells server måste den finnas kvar, även om din vanliga e-post går till Microsoft 365. Ett webbhotellspaket har ofta redan en standard-SPF med en include för webbhotellet (hos WebOké är det till exempel include:webawere.nl); låt den stå kvar så länge din webbplats eller formulär skickar e-post via den servern.

Fel 2: +all eller en alltför vid post

+all i slutet, eller ett enormt intervall som ip4:0.0.0.0/0, betyder att alla får skicka. Då skyddar din SPF ingenting längre, och spamfilter ser det som ett dåligt tecken.

Fel 3: fler än tio uppslagningar

För att kontrollera en SPF-post måste mottagaren ibland ställa extra DNS-frågor. Varje include, a, mx, exists, ptr och redirect kostar en uppslagning, och en include räknar också alla uppslagningar i posten den pekar på. Enligt RFC 7208 får totalen inte överstiga tio. Går den över blir resultatet permerror och SPF misslyckas.

ip4 och ip6 kostar ingen uppslagning. all inte heller.

Dessutom får högst två uppslagningar komma tillbaka "tomma" (ett namn som inte finns eller inget svar). En include till en tjänst du inte längre använder och som har tagit bort sin post kan alltså också orsaka problem.

Använder du många tjänster, räkna då efter med ett SPF-kontrollverktyg (lektion 8.3) och ta bort tjänster du inte längre använder.

Vad SPF inte gör

SPF kontrollerar envelope-avsändaren: den tekniska avsändaradressen (Return-Path) som mailservrar använder sinsemellan. Det är inte alltid samma adress som "Från:"-adressen du ser i ditt e-postprogram. En nyhetsbrevstjänst skickar ofta med en egen Return-Path. SPF ensamt stoppar alltså inte varje förfalskad avsändare. Det är DKIM (lektion 4.4) och DMARC (lektion 4.5) till för.

SPF går också sönder vid vidarebefordran: skickar du mejl automatiskt vidare till en annan adress kommer mejlet fram till slutmottagaren från en server som inte finns i din SPF.

Varför det spelar roll

Stora e-postleverantörer har blivit strängare. Sedan februari 2024 kräver Gmail och Yahoo att alla som skickar e-post minst har SPF eller DKIM, och att den som skickar mycket e-post (fler än cirka 5 000 per dag) har SPF, DKIM och DMARC. Microsoft ställer samma krav för Outlook.com, Hotmail och Live.com sedan maj 2025. Även om du skickar lite e-post hjälper en bra SPF-post mot att hamna i skräppostmappen.

I praktiken: så ser det ut i en panel

I det här exemplet använder vi DirectAdmin. I DNS-administration klickar du på pennan bakom TXT-posten som börjar med v=spf1. DirectAdmin öppnar en SPF-hjälp: vid Inkludera domän fyller du i tjänstens domän (utan include:), vid Läge väljer du SoftFail (~all) eller Neka (-all). Längst ner ser du hela posten. Mitt WebOké har en liknande SPF-hjälp på fliken DNS.

Andra paneler har inte alltid en sådan hjälp. Då redigerar du TXT-posten som vanlig text; innehållet är precis detsamma.

Sammanfattning

• SPF är en TXT-post med v=spf1 som anger vilka servrar som får skicka e-post i din domäns namn.
• Exakt en SPF-post per domän. Ny tjänst? Fyll på den befintliga posten.
• Avsluta med ~all eller -all, aldrig med +all.
• Högst tio DNS-uppslagningar (include, a, mx, exists, ptr, redirect), ip4/ip6 räknas inte med.
• SPF tittar på envelope-avsändaren; för verkligt skydd behöver du även DKIM och DMARC.

Quiz

Uppgift

Uppgift Z4.3: Slå upp SPF. Slå upp SPF-posten för google.com (eller för ditt eget domän). Klistra in hela posten, och fyll i vad den slutar med (~all, -all, ?all eller +all). För ditt eget domän kontrollerar uppgiften också om du har exakt en SPF-post.

Uppgift O4.3: Ställa in själv i din övningszon. I övningszonen använder du en fejktjänst; för ditt riktiga domän använder du den riktiga include som din e-postleverantör anger (till exempel include:_spf.google.com). Skapa i din övningszon <code>.dnspractice.eu en SPF-post som tillåter: zonens MX-servrar (mx), adressen 192.0.2.25 och övningstjänsten _spf.mailsuite-demo.dnspractice.eu. Andra servrar är misstänkta eller inte tillåtna, så posten slutar på ~all eller -all.

Läs mer

Stegen i de här artiklarna gäller för WebOkés paneler; i andra paneler fungerar det på liknande sätt.

• DirectAdmin-guide 5.7: SPF ställa in och komplettera
• Hur fungerar SPF-posten i DNS:en?
• Lägg till eller ändra en SPF-post i DirectAdmin
• WebOké manual 5.5: DNS-hjälpare: MX, SPF, DMARC, CAA och SRV
• RFC 7208 (SPF), särskilt avsnitt 4.6.4 (gräns på tio uppslagningar och två tomma uppslagningar)