Vad är en spf post? Syntax, gränsen på 10 DNS-uppslag

Vad är en spf post? Det är en enda DNS-post av typen TXT på din domän, och den listar vilka servrar som får skicka e-post med din domän i avsändaradressen på SMTP-nivå. En mottagande server läser posten, jämför IP-adressen som ansluter mot listan och returnerar pass, fail, softfail eller neutral. Posten autentiserar alltså sändvägen, inte meddelandet, och den säger ingenting om From-adressen som en person läser.

Den skillnaden förklarar de flesta SPF-ärenden vi ser i spåren.

En spf post är en vitlista över avsändare, publicerad i DNS

SPF står för Sender Policy Framework och beskrivs i RFC 7208. Posten är en TXT-post på domänens rot och börjar med v=spf1. En minimal post ser ut så här:

example.com.  IN  TXT  "v=spf1 ip4:203.0.113.10 include:_spf.provider.example ~all"

Läs den från vänster till höger. Mottagaren kontrollerar varje term i ordning och stannar vid första träffen. Den avslutande termen all fångar allt som inte matchade tidigare.

Domänen som kontrolleras är inte From-headern. Det är domänen i SMTP-kommandot MAIL FROM, som också kallas envelope-avsändare eller Return-Path. Om den är tom, till exempel vid studsar, faller mottagaren tillbaka på HELO-namnet.

Varje term är en mekanism, med eventuellt en kvalificerare framför. Sex av dem täcker nästan alla riktiga poster.

• ip4: och ip6: matchar en bokstavlig adress eller ett CIDR-intervall. De kostar inga uppslag.

• a matchar A- och AAAA-posterna för en domän. Det kostar ett uppslag.

• mx matchar värdarna i domänens MX-poster. Det kostar ett uppslag plus ett per värd.

• include: matchar det som en annan domäns SPF-post matchar. Det kostar ett uppslag, plus allt som ligger nästlat inuti.

• exists: matchar om en A-post finns för ett konstruerat namn. Det kostar ett uppslag.

• ptr matchar på omvänd DNS för den anslutande IP-adressen. Det kostar uppslag, och RFC 7208 avråder från att använda den.

Kvalificerarna sätter resultatet när en term matchar. + är pass och är standard, - är fail, ~ är softfail och ? är neutral. -all betyder alltså att allt som inte står i listan avvisas, och ~all betyder att det accepteras men flaggas.

Använd ip4: och ip6: när du själv kontrollerar adressen. De kostar noll uppslag och kan inte gå sönder när någon annans DNS ändras.

Gränsen på 10 uppslag är det som sänker riktiga poster

RFC 7208 begränsar en SPF-utvärdering till 10 termer som utlöser DNS-frågor: include, a, mx, ptr, exists och modifieraren redirect. Nästlade includes räknas med. Över 10 blir resultatet permerror, och kontrollen misslyckas permanent i stället för att falla tillbaka.

Det finns en andra gräns som får mindre uppmärksamhet. Termer som ger ett tomt svar eller NXDOMAIN kallas void lookups, och specifikationen säger att man ska stanna vid två. En gammal include: som pekar på en leverantör du slutade använda för ett år sedan är ett void lookup som du betalar för.

Så här brukar gränsen nås i praktiken. Google Workspace tar en include. En transaktionell leverantör tar en. En marknadsföringsplattform tar en och nästlar tre till inuti. Ett supportsystem, ett CRM och ett faktureringsverktyg lägger till fyra till. Då är du på 11 utan att ha gjort något ovanligt.

Felet syns inte. Mejlen skickas fortfarande, och en del mottagare levererar dem ändå, men SPF autentiserar inget längre åt dig. Om du förlitar dig på DMARC-alignment via SPF är den vägen stängd tills du platt ut posten eller tar bort avsändare.

Ett sätt att upptäcka felet tidigt är att följa andelen meddelanden i DMARC-rapporterna där SPF inte är aligned, inte bara andelen där SPF saknar pass helt. Ett bolag kan ha en grön SPF-kontroll i sina tester och ändå se den andelen växa, eftersom en ny avsändare lagts till utan att posten uppdaterades. Ett enkelt veckolarm på den andelen fångar det innan någon kund märker något.

Tre åtgärder fungerar, i prioritetsordning:

1. Ta bort avsändare du inte använder längre. Gå igenom includes mot dina DMARC-aggregatrapporter från de senaste 90 dagarna.

2. Flytta massutskick till en subdomän, till exempel mail.example.com, med en egen SPF-post och en egen budget på 10 uppslag.

3. Platta ut includes till bokstavliga ip4:-intervall, men bara med automatisering. Leverantörer roterar sina IP-adresser, och en handplattad post blir inaktuell utan att något larm går.

Publicera exakt en spf post per domän

En domän ska inte publicera två SPF-poster. Om en mottagare hittar två TXT-poster som båda börjar med v=spf1 blir resultatet permerror, precis som vid gränsen på uppslag. Det händer när en person lägger till en post för ett nytt verktyg medan någon annan redan har en på plats.

Lösningen är mekanisk. Slå ihop termerna till en enda post, med ett v=spf1 i början och ett all i slutet. Allt som leverantörens dokumentation säger att du ska lägga till går in i den befintliga posten som ytterligare en include:, aldrig som en ny TXT-post.

Två mindre fällor finns. En TXT-sträng som är över 255 tecken måste delas upp i flera citerade strängar inom samma post, vilket de flesta DNS-leverantörer gör åt dig. Och håll hela svaret under cirka 450 byte där det går, eftersom större svar kan falla tillbaka från UDP till TCP, och en del resolvers hanterar det dåligt.

Softfail eller hardfail: välj efter vad du ser

all-termen är ett policyuttalande, och det vanliga rådet ("använd -all") hoppar över den del som faktiskt spelar roll. En hård fail är bara säker när du känner till varje legitim avsändare.

Vår tumregel efter att ha läst spår:

• ~all medan du fortfarande inventerar avsändare, eller om du vidarebefordrar e-post och inte kontrollerar vägen.

• -all när DMARC-rapporterna visar att alla legitima källor passerar under några veckor.

• Aldrig +all, som godkänner hela internet, och aldrig ?all på en produktionsdomän.

I praktiken är skillnaden mindre än folk tror. De flesta stora mottagare behandlar SPF som en signal bland flera, och när en DMARC-policy finns är det DMARC-utslaget som avgör. Ändå är en -all på en ofullständig post ett sätt att tappa fakturor.

SPF går sönder vid vidarebefordring, och det är med flit

SPF kontrollerar IP-adressen som anslöt till mottagarservern. När ett meddelande vidarebefordras, skickas via en sändlista eller relayas av en aliastjänst är den anslutande IP-adressen vidarebefordrarens, inte din. SPF-kontrollen faller även om du inte gjort något fel.

Det går inte att lösa inuti SPF. Därför finns DKIM vid sidan av: en signatur överlever hoppet, en IP-lista gör det inte. En domän som bara förlitar sig på SPF ser autentiseringsfel på varje vidarebefordrat meddelande.

Det är också därför SPF ensamt inte uppfyller DMARC för vidarebefordrad post. Planera för att DKIM ska bära de meddelandena.

Att passera SPF räcker inte för att matcha din From-domän

Ett meddelande kan passera SPF och ändå misslyckas i DMARC. DMARC kräver att domänen som passerade SPF, Return-Path-domänen, matchar den synliga From-domänen. Många delade leverantörer använder sin egen studsdomän som standard, så SPF passerar för provider-mail.net och säger ingenting om example.com.

Kontrollera det i de råa headers. I raden Authentication-Results ska du titta på smtp.mailfrom=. Om den inte är din domän eller en subdomän till den passerar SPF utan att hjälpa dig.

Botemedlet är en egen Return-Path på en subdomän, vilket de flesta seriösa avsändare stöder. Postmark, Resend, Mailgun och SendGrid dokumenterar alla den uppsättningen, även om den inte alltid är påslagen som standard.

Ordningen spelar roll när du sätter upp den. Lägg först till subdomänens DNS-poster, vänta tills de svarar, och byt sedan Return-Path i din sändartjänst. Byter du i fel ordning får du en period där SPF-kontrollen mot den nya domänen faller, och det är just den perioden som brukar ge supportärenden.

Så kontrollerar och rättar du posten på fyra steg

Gör dessa i ordning, och kontrollera igen efter varje DNS-ändring.

1. Slå upp den nuvarande posten. Kör dig +short TXT example.com och hitta raden som börjar med v=spf1. Om det finns två, slå ihop dem.

2. Räkna uppslagen. Lägg ihop include, a, mx, exists, redirect och allt som är nästlat i includes. Om du ligger på 8 eller mer, planera upprensningen nu, inte vid den elfte.

3. Lista riktiga avsändare. Använd DMARC-aggregatrapporter eller Authentication-Results-headers från testutskick. Lägg bara till källor som faktiskt syns.

4. Skicka ett test och läs headern. Resultatet ska stå spf=pass med smtp.mailfrom på din domän.

DNS-ändringar tar tid att spridas, och TTL på din nuvarande post avgör hur länge gamla svar lever kvar. Sänk den till 300 sekunder en dag före en planerad ändring.

Ett exempel med tre avsändare, och vad SPF inte gör

Ta en produkt som skickar från Google Workspace, en transaktionell leverantör och ett supportsystem. En ren post ser ut så här:

example.com.  IN  TXT  "v=spf1 include:_spf.google.com include:spf.transactional.example include:spf.helpdesk.example -all"

Det är tre includes, och var och en döljer sina egna nästlade uppslag. Räkna dem innan du publicerar, eftersom den synliga längden inte säger något om den verkliga budgeten. En post med tre includes kan redan ligga på 7 eller 8 uppslag.

Dela då upp efter syfte. Behåll mänsklig e-post på rotdomänen. Lägg produktnotiser på notify.example.com med en post som bara listar den transaktionella leverantören. Rotposten förblir kort, subdomänen får en egen budget på 10 uppslag, och ett reputationsproblem i ett flöde drar inte med sig det andra.

Uppdelningen gör också DMARC-rapporterna läsbara. Varje flöde har sin egen Return-Path-domän, så ett fel pekar på en avsändare i stället för en hop.

SPF kommer inte att stoppa någon från att förfalska din From-adress, eftersom den aldrig tittar på den headern. Den krypterar inte heller något. Den säger inte varför ett meddelande hamnade i skräpposten. Och den skalar inte förbi budgeten på 10 uppslag utan löpande underhåll.

Behandla den som en av tre poster du publicerar tillsammans: SPF för sändvägen, DKIM för meddelandets integritet och DMARC för policyn som binder dem till din From-domän. Om du bara har SPF och ingenting annat är nästa konkreta steg att publicera en DMARC-post med p=none och läsa rapporterna i två veckor.