SPF i praktiken: kartlägg alla avsändare

Modul 4: Leveransbarhet: SPF, DKIM och DMARC i praktiken · Lästid: 12 minuter

Lärandemål: Efter den här lektionen kan du spåra alla tjänster som mejlar i din domäns namn, samla dem i en enda SPF-post, räkna uppslagningarna rekursivt fram till gränsen på tio, och medvetet välja mellan ~all och -all.

Nyckelbegrepp: inventering av avsändare, envelope sender (Return-Path), en enda SPF-post, include, redirect, gräns på 10 DNS-uppslagningar (RFC 7208 avsnitt 4.6.4), tomma uppslagningar (void lookups, max 2), rekursiv räkning, permerror, flattening, SPF för subdomäner, SPF på en domän som inte mejlar, ~all och -all

Kort repetition

En SPF-post är en TXT-post på din domän som börjar med v=spf1 och räknar upp vilka servrar som får mejla i din domäns namn. Uppbyggnaden, tecknen + - ~ ? och de tre vanligaste felen (två poster, +all, fler än tio uppslagningar) finns i DNS-kursen, lektion 4.3. Läs den först om SPF är nytt för dig. Den här lektionen handlar om den svåra delen: i praktiken vet nästan ingen exakt vilka som mejlar i deras domäns namn.

Steg 1: inventeringen

SPF fungerar bara om alla avsändare finns med. Glömmer du en, hamnar det mejlet i skräpposten eller avvisas så fort du skärper din DMARC-policy. Gå därför igenom den här listan. Hos ett genomsnittligt litet företag hittar du snabbt fem eller sex:

Två bra sätt att hitta dem på:

1. Läsa rubrikrader. Skicka ett testmejl från varje system till dig själv (en faktura, en lösenordsåterställning, ett testnyhetsbrev) och titta i rubrikraderna på Return-Path och Authentication-Results (lektion 1.5). Där ser du via vilken domän och vilken server det kom.
2. DMARC-rapporter. Ställ in DMARC på p=none med en rapportadress (lektion 4.4). Efter några veckor ser du i rapporterna (lektion 4.5) varje server som mejlat i din domäns namn, även de du glömt. Det är den mest tillförlitliga inventeringen.

Inte alla tjänster hör hemma i din SPF

Här blir det ofta fel. SPF tittar på envelope sender (Return-Path), inte på Från-adressen. Många nyhetsbrevs- och utskickstjänster skickar med ett Return-Path på sin egen domän, till exempel bounce-123@mail.mailer.example. Mottagaren kontrollerar då SPF-posten för mailer.example, inte din. En include av den tjänsten i din post gör då ingenting, förutom att kosta en uppslagning.

Det den tjänsten faktiskt behöver för att klara DMARC är en DKIM-signatur med din domän (lektion 4.3), eller en egen Return-Path-subdomän från dig (till exempel bounce.example.com som CNAME till tjänsten). Läs alltså i tjänstens dokumentation vad den kräver. Säger den "lägg till include: i din SPF", gör det. Säger den bara "skapa dessa CNAME-poster för DKIM och bounce-domänen", behöver inget läggas till i din huvudpost. Modul 7 går djupare in på detta.

Steg 2: en post, och räkna rätt

Alla avsändare samlas i en post. Säg att din inventering ger: mejlservern hos ditt webbhotell, Microsoft 365 för några medarbetare, ditt bokföringsprogram och en helpdesk. Då blir posten till exempel:

example.com.  3600  IN  TXT  "v=spf1 a mx include:spf.hosting.example include:spf.protection.outlook.com include:_spf.boekhoud.example include:mail.helpdesk.example ~all"

Hur många uppslagningar är det? Räkna varje a, mx, include, exists, ptr och redirect, och räkna sedan också allt som finns i posterna bakom varje include:

Vid 11 ger mottagaren ett permerror: hela SPF-posten räknas då inte, för ingen avsändare alls. Mejlet från din egen mejlserver bedöms alltså sämre bara för att helpdesken kostar tre uppslagningar. Och det lurigaste är: din post kan vara 9 idag och 11 imorgon, utan att du ändrar något, eftersom en tjänst utökar sin egen post.

Dessutom: högst två tomma uppslagningar

RFC 7208 nämner också void lookups: uppslagningar som inte ger något resultat (namnet finns inte, eller saknar SPF- eller adresspost). Fler än två av dessa leder också till permerror. Det händer oftast med gamla include-poster från tjänster du inte längre använder och som tagit bort sin post, eller med en a: mot en server som inte längre finns. Städa alltså upp.

Steg 3: tillbaka under tio

Ligger du över tio finns det fyra lösningar, från bäst till minst bra:

1. Ta bort det som inte behövs. Tjänster du inte längre använder. Tjänster som skickar med eget Return-Path (se ovan) och därför inte hör hemma i din SPF. a om din webbplats själv inte skickar mejl. mx om din MX pekar mot en tjänst som redan finns som include i din post.
2. Använd en subdomän. Låt en tjänst skicka från nieuws.example.com eller factuur.example.com. Den subdomänen får en egen SPF-post med bara den tjänsten, och räknas inte in i de tio för din huvuddomän. Uppriktning i DMARC (lektion 4.4) fungerar som standard även för subdomäner.
3. Använd ip4: och ip6: för dina egna fasta servrar. De kostar ingen uppslagning. Gör det bara för adresser som du själv förvaltar och som inte ändras.
4. Flattening (ersätta alla includes med de IP-adresser som ligger bakom dem just nu). Det tar ner antalet till 0, men posten stämmer inte längre så fort en tjänst ändrar sina adresser, och stora tjänster gör det regelbundet. Gör det bara med ett verktyg som uppdaterar det automatiskt, och helst inte alls.

redirect eller include?

redirect= säger: använd SPF-posten för den andra domänen istället för den här posten. Det kostar en uppslagning, precis som en include. Det är praktiskt om du har många domäner som ska ha exakt samma policy: v=spf1 redirect=_spf.example.com på varje domän, och den riktiga posten på ett enda ställe. En post med redirect= får inte ha någon all, för då ignoreras redirecten. Gmail använder det själv: gmail.com har v=spf1 redirect=_spf.google.com.

Steg 4: ~all eller -all?

Den här kursens rekommendation, samma som i DNS-kursen:

• Börja med ~all (softfail). Mejl från en server som inte finns i din post ses som misstänkt, men avvisas oftast inte direkt. Glömmer du en avsändare, blir skadan begränsad.
• Gå över till -all (fail) när du är säker på att alla avsändare finns med, till exempel efter att du granskat DMARC-rapporter i några veckor och inte hittat några okända källor längre.

Med DMARC på plats är skillnaden mindre än vad man ofta tror. DMARC bestämmer utifrån "SPF eller DKIM godkänt och uppriktat". En softfail räknas för DMARC helt enkelt som "inte godkänt". Det verkliga skyddet kommer alltså från en strikt DMARC-policy, inte från -all. Vissa mottagare avvisar redan vid -all, innan DMARC-bedömningen görs; det är en anledning att vänta med -all tills din post verkligen är komplett.

En domän som aldrig mejlar

Har du domäner som aldrig skickar mejl (ett gammalt varumärke, en felstavningsdomän)? Skydda dem mot missbruk med:

example.org.         IN  TXT  "v=spf1 -all"
_dmarc.example.org.  IN  TXT  "v=DMARC1; p=reject"
example.org.         IN  MX   0 .

Här är -all rätt direkt: ingen får mejla. Den sista raden är en null MX (RFC 7505): "den här domänen tar inte emot mejl". example.com själv är inställd precis så.

I praktiken: så ser det ut i ett kontrollpanel

I ett webbhotellpaket från WebOké står som standard v=spf1 a mx include:webawere.nl ~all. Lägger du till en tjänst justerar du den posten (i DirectAdmin: DNS Management, pennan bakom SPF-posten, fältet Inkludera domän; i Mitt WebOké: SPF-hjälpen på fliken DNS). Låt include:webawere.nl stå kvar så länge din mejl eller webbplats går via de servrarna. Hos andra leverantörer heter standardincluden annorlunda, men principen är densamma: komplettera, inte skapa en andra post.

Sammanfattning

• Gör först en inventering av alla avsändare; DMARC-rapporter och rubrikrader hjälper till med det.
• En tjänst med eget Return-Path hör inte hemma i din SPF; den behöver DKIM med din domän.
• Räkna rekursivt: varje include, a, mx, exists, ptr och redirect, även inuti includes. Över tio, eller fler än två tomma uppslagningar, ger permerror.
• Kom tillbaka under tio genom att städa upp och använda subdomäner; flattening bara med automatiskt underhåll.
• Börja med ~all, gå till -all när du är säker. Domäner som aldrig mejlar: -all, DMARC reject och null MX.

Quiz

Uppgift

Uppgift Z4.2: Räkna SPF för din domän rekursivt. Fyll i din egen domän (eller sidn.nl om du inte har en egen domän). Räkna själv först hur många DNS-uppslagningar SPF-posten kostar, inklusive allt inuti includes, och fyll i siffran, tillsammans med slutet av posten (~all, -all, ?all eller +all). Programmet räknar live efteråt, inklusive tomma uppslagningar, och visar trädet.

Uppgift O4.2: Din avsändarinventering. Gör med tabellen från den här lektionen en lista över alla system som skickar mejl i din domäns namn. Ange för varje: via vilken server eller tjänst, om den ska finnas i din SPF (eget Return-Path eller inte), och om den signerar DKIM med din domän. Skicka ett testmejl till dig själv från minst två system och notera från rubrikraderna Return-Path-domänen och DKIM-domänen (d=).

Läs mer

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

• Gratis DNS-kurs 4.3: SPF: vem får skicka e-post i din domäns namn?
• 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), avsnitt 4.6.4 (gränser) och 6.1 (redirect); RFC 7505 (null MX)
• Gmail och Outlook.com med din egen domän 2.4: SPF och DKIM när du skickar via Gmail