SPF-posten, förklarad

SPF är den äldsta av de tre e-postposterna som skyddar en domän mot förfalskning, och den som oftast publiceras och sedan glöms bort. En SPF-post kan finnas, se rimlig ut och ändå godkänna hela internet, sluta fungera i tysthet när en leverantör lägger till en server, eller godkännas utan att göra någon nytta för DMARC. Den här guiden förklarar hur posten läses, så att ni kan se vad som gäller för er.

Exemplen använder example.com. Byt ut den mot er egen domän.

Vad en SPF-post är

Med Sender Policy Framework (RFC 7208) listar en domän vilka servrar som får skicka e-post med domänen som kuvertavsändare, alltså adressen i SMTP-kommandot MAIL FROM. Mottagaren ser den senare som Return-Path. SPF-posten är en enda TXT-post direkt på domännamnet:

example.com.  3600  IN  TXT  "v=spf1 ip4:192.0.2.10 include:_spf.google.com ~all"

Den mottagande servern tar IP-adressen som meddelandet kom från och går igenom posten från vänster till höger. Den första delen som matchar avgör resultatet. Matchar ingenting, avgör all i slutet.

Två regler ställer ofta till det:

• En post per namn. En domän med två TXT-poster som börjar med v=spf1 har en ogiltig SPF. Enligt RFC 7208 ska mottagaren då ge resultatet permerror, och de flesta bortser sedan från SPF för domänen. Det brukar hända när en ny leverantörs instruktion säger ”lägg till den här SPF-posten” och någon gör just det, bredvid den som redan fanns. Slå ihop dem till en.
• Inget arv. SPF slås upp för exakt den domän som står i kuvertavsändaren. news.example.com ärver inte posten på example.com. Varje namn ni skickar från, eller tar emot studsar på, behöver en egen post.

Postens delar

Varje mekanism kan ha en kvalificerare framför sig. + betyder godkänd och är standard, så ip4:192.0.2.10 och +ip4:192.0.2.10 betyder samma sak. - betyder underkänd (fail), ~ betyder mjukt underkänd (softfail) och ? betyder neutral. I praktiken är det kvalificeraren på all som spelar roll.

Hur posten slutar: ~all, -all, ?all och +all

Mekanismen all svarar på frågan ”vad gäller för alla andra?”.

+all är aldrig rätt. Det gör SPF till ett godkännande för vem som helst, även den som förfalskar, samtidigt som posten ser konfigurerad ut. ?all och en post utan all ger mottagaren ingen instruktion alls, och därmed inget skydd mot förfalskning.

Valet mellan ~all och -all betyder mindre i dag än förr, eftersom det är DMARC som avgör leveransen hos de flesta stora mottagare. Båda fungerar:

• ~all är det vanliga valet för domäner som skickar e-post. Vissa mottagare avvisar ett meddelande direkt när SPF ger fail, innan de har tittat på DMARC eller DKIM. RFC 7489 (avsnitt 10.1) varnar för just det. Med ~all får ett vidarebefordrat meddelande som fallerar på SPF ändå en chans att klara DMARC med en DKIM-signatur i linje.
• -all är rätt för en domän som aldrig skickar e-post, tillsammans med en DMARC-post med p=reject. Det är också rimligt för en domän där varje avsändare är känd och signerar med DKIM.

; en domän som skickar via Microsoft 365 och en nyhetsbrevstjänst
example.com.  3600  IN  TXT  "v=spf1 include:spf.protection.outlook.com include:spf.sender.example ~all"

; en parkerad domän som aldrig skickar e-post
example.org.  3600  IN  TXT  "v=spf1 -all"

Gränsen på tio DNS-uppslag

När en mottagare utvärderar SPF kan det krävas DNS-uppslag, och därför sätter RFC 7208 (avsnitt 4.6.4) ett tak. De delar som ger uppslag, include, a, mx, ptr, exists och redirect, får tillsammans ge högst tio DNS-uppslag under en utvärdering. ip4, ip6 och all räknas inte. Går ni över gränsen blir resultatet permerror, och mottagarna behandlar posten som trasig.

Gränsen gäller hela trädet, inte bara det ni ser. Varje include kostar ett uppslag för sig själv, plus alla uppslag i posten den pekar på och i de poster som den i sin tur inkluderar. RFC:n säger också att mottagare bör tillåta högst två uppslag som inte ger något svar (void lookups), så en include som pekar på ett namn som inte längre finns kostar mer än man tror.

Räkna själva. Börja med er post och slå upp varje include:

dig +short TXT example.com
dig +short TXT _spf.google.com
dig +short TXT spf.protection.outlook.com

Lägg till ett för varje include, a, mx, exists eller redirect ni stöter på, på varje nivå. Summan ändras när en leverantör bygger om sin egen post, så en post som hade åtta uppslag i fjol kan ha elva i dag utan att någon hos er har rört DNS.

Molntjänster och include-kedjor

De flesta når gränsen via sina leverantörer. E-posttjänsten, CRM-systemet, kundtjänstverktyget, nyhetsbrevet, faktureringen och rekryteringssystemet kan alla be om en egen include, och vissa stora leverantörers poster innehåller i sin tur tre eller fyra uppslag.

Ställ två frågor innan ni lägger till ännu en include.

1. Skickar tjänsten verkligen med vår domän som kuvertavsändare? Många tjänster skickar med sin egen returdomän, till exempel bounces.sender.example. Då kontrollerar mottagaren SPF för den domänen, inte för er, och er include används aldrig. Den kostar ett uppslag och gör ingen nytta.
2. Kan tjänsten signera med DKIM under vår domän i stället? En DKIM-signatur i linje räcker på egen hand för DMARC, klarar vidarebefordran och kostar inga SPF-uppslag.

Fler sätt att hålla sig under tio:

• Ta bort include för tjänster ni inte längre använder. Gamla include-poster är det vanligaste slöseriet. Se i DMARC-rapporterna vilka källor som fortfarande skickar.
• Flytta massutskick till en subdomän. Ge nyhetsbrevstjänsten news.example.com med egen SPF-post, egen DKIM-nyckel och egen returdomän. Huvuddomänens post förblir kort.
• Byt a och mx mot adresser där servrarna är era egna och stabila. mx följer ofta med av vana på domäner vars MX-servrar aldrig skickar utgående e-post.

Flattening, och varför det går sönder

Flattening betyder att ni ersätter include med de IP-intervall de pekar på just nu, så att posten inte kräver några uppslag:

example.com.  3600  IN  TXT  "v=spf1 ip4:192.0.2.0/24 ip4:198.51.100.0/24 ip6:2001:db8::/32 ~all"

Det löser räkningen men skapar ett underhållsproblem. Leverantörer byter adresser när de bygger ut eller flyttar datacenter, och de gör det i sin egen include-post, som ni inte längre läser. När det händer fallerar SPF för e-post från de nya adresserna, ofta flera veckor efter att ni plattade till posten, och ingenting kopplar felet till ändringen.

Tillplattade poster blir dessutom långa. En TXT-post delas upp i strängar på högst 255 tecken, och RFC 7208 råder er att hålla hela SPF-svaret så litet att det ryms i ett enda DNS-svar. En post som har vuxit förbi det kan fallera hos vissa mottagare.

Om ni plattar till posten, gör det med ett verktyg eller en tjänst som regelbundet slår upp leverantörernas poster igen och publicerar om automatiskt, och behåll leverantörens egen include för det som verktyget inte hanterar. Handgjord flattening är en vanlig orsak till SPF-fel som ingen kan förklara.

SPF och DMARC: att vara i linje

Att klara SPF är inte samma sak som att klara DMARC. DMARC (RFC 7489) kräver att SPF godkänns och är i linje: kuvertavsändarens domän, som SPF kontrollerade, måste stämma med domänen i det synliga Från-fältet. Som standard är kontrollen avslappnad, så bounces.example.com räknas som i linje med example.com.

Därför kan en extern tjänst visa ”SPF: pass” i varje rapport och ändå fallera på DMARC för er domän. Den klarade SPF för sin egen returdomän, som inte är er. Lösningen är antingen en egen returdomän (return-path) under er domän, om tjänsten erbjuder det, eller en DKIM-signatur i linje, vilket oftast är enklare.

Ett meddelande klarar DMARC om SPF eller DKIM godkänns och är i linje. Sikta på DKIM för varje avsändare och se SPF som den andra vägen, inte den enda. DMARC-guiden går igenom hela införandet.

Så bedömer TrustSek SPF

TrustSek läser den SPF-post er domän publicerar i DNS, som en del av modulen e-postsäkerhet. Det är en avläsning vid ett enda tillfälle. Det här rapporterar en kontroll:

Fynden står på engelska, så som TrustSek rapporterar dem i dag.

Tre begränsningar är bra att känna till. Kontrollen följer inte include-kedjor och räknar inte DNS-uppslag, så en post över gränsen på tio flaggas inte: räkna själva som beskrivs ovan. En post som slutar med ?all ger inget fynd, trots att den inte skyddar bättre än en post utan all; välj hellre ~all eller -all. Och en post som klarar allt detta gör ändå ingen nytta för DMARC om inte era avsändare är i linje. Sidan SPF-kontroll sammanfattar resultaten, och metoden förklarar hur allvarlighetsgraden påverkar poängen.

Kontrollera er domäns SPF och resten av e-postsäkerheten

Se hur er SPF-post slutar i dag, tillsammans med DMARC, DKIM, MTA-STS och resten av bedömningen utifrån.

Er domän

Kontrollera er domän

Gratis, inget konto behövs. Tar ungefär 30 sekunder.