Definition
Ett SPF-record (Sender Policy Framework-record) är en DNS TXT-resurspost publicerad i en domäns publika DNS-zon som räknar upp IP-adresser, IPv6-prefix och e-postservervärdnamn som är auktoriserade att skicka e-post för den domänens räkning. När en mottagande e-postserver accepterar ett inkommande meddelande frågar den avsändarens DNS efter SPF-recorden och jämför den anslutande IP-adressen mot policyn. Om IP:n inte är listad kan den mottagande servern markera meddelandet som softfail, avvisa det direkt eller flagga det för ytterligare utvärdering — beroende på policykvalifikatorn som ställts in av domänägaren.
SPF formaliserades först som en IETF-standard i RFC 4408 (2006) och uppdaterades senare till den nuvarande auktoritativa specifikationen i RFC 7208, publicerad av Internet Engineering Task Force (IETF) i april 2014. Det är en av tre kompletterande e-postautentiseringsstandarder vid sidan av DKIM (DomainKeys Identified Mail) och DMARC (Domain-based Message Authentication, Reporting, and Conformance).
Hur det fungerar
SPF-utvärderingsprocessen omfattar flera sekventiella steg som utförs av den mottagande e-postserverns SMTP-motor under MAIL FROM-fasen av SMTP-handskakningen.
Domänägaren publicerar ett SPF TXT-record i DNS. Ett typiskt record följer denna syntax: v=spf1 include:_spf.google.com ip4:203.0.113.5 ~all. Komponenterna är: v=spf1 (versionsidentifierare), en eller flera mekanismer (include, ip4, ip6, a, mx, exists) och en slutkvalifikator (+all, -all, ~all, ?all). Kvalifikatorn -all innebär hård misslyckande — varje server som inte är explicit listad är inte auktoriserad. Kvalifikatorn ~all (softfail) släpper igenom meddelandet men noterar policyavvikelsen, vanligt under migreringsperioder.
När ett meddelande anländer extraherar den mottagande MTA:n (Mail Transfer Agent) avsändardomänen för envelopet (MAIL FROM-adressen, även kallad RFC5321.MailFrom-adressen) och utför en DNS TXT-uppslagning för _spf.<domain> eller direkt på domänens rot. SPF-biblioteket utvärderar varje mekanism i ordning tills en matchar eller gränsen på tio DNS-uppslagningar nås (“SPF PermError”-gränsen definierad i RFC 7208 sektion 4.6.4). Resultatet — Pass, Fail, SoftFail, Neutral, TempError eller PermError — infogas i meddelandets Received-SPF-huvud och skickas vidare till spamfiltret och eventuell DMARC-policymotor.
Det är kritiskt att notera att SPF autentiserar envelope-avsändaren (MAIL FROM), inte det synliga From-huvudet i meddelandekroppen. Denna distinktion innebär att SPF ensam inte förhindrar förfalskning av visningsnamn i e-postklienter, vilket är anledningen till att DMARC-justering — som kräver att SPF- och/eller DKIM-resultat matchar RFC5322.From-domänen — är nödvändig för fullständigt skydd.
Var du stöter på det
SPF-records visas i alla sammanhang där e-postleveransbarhet och avsändarrykte spelar roll. Transaktionell e-postinfrastruktur som drivs av tjänster som Amazon SES, SendGrid, Mailgun, Postmark och SparkPost kräver att domänägare lägger till SPF include-mekanismer som pekar på leverantörens sändande infrastruktur innan meddelanden passerar autentiseringskontroller.
Tävlingsplattformar som skickar e-postbekräftelseröster — inklusive Woobox, ShortStack och anpassade system byggda med Mailchimp Transactional (Mandrill) — förlitar sig på att den sändande domänen har ett giltigt SPF-record. Brevlådeleverantörer inklusive Google (Gmail), Microsoft (Outlook / Exchange Online Protection) och Yahoo Mail utvärderar SPF som indata till sina leveransbarhetsalgoritmer. Ett saknat eller felkonfigurerat SPF-record ökar avsevärt sannolikheten att bekräftelsemejl tyst levereras till spam-mappar eller avvisas helt, vilket gör att röster förblir obekräftade.
DNS-hostingpaneler från leverantörer som Cloudflare, AWS Route 53, GoDaddy och Namecheap exponerar SPF TXT-record-redigering genom sina hanteringsgränssnitt. Diagnostikverktyg som MXToolbox SPF Lookup, Google Admin Toolbox och DMARCIAN:s SPF Surveyor låter domänägare inspektera och validera publicerade records.
Praktiska exempel
En tävlingsplattform skickar röstbekräftelsemejl från [email protected]. Domänen votes.example.com har SPF-recorden v=spf1 include:sendgrid.net -all. När Gmail tar emot ett bekräftelsemeddelande frågar dess inkommande SMTP-server DNS efter SPF-recorden för votes.example.com, expanderar sendgrid.net-include-mekanismen och kontrollerar den anslutande IP:n mot SendGrids auktoriserade serverlista. Om IP:n matchar är SPF-resultatet Pass och meddelandet fortsätter till inkorgen. Om domänen inte hade något SPF-record skulle Gmails filter behandla meddelandet som oautentiserat, vilket minskar sannolikheten för inkorgsplacering.
En regional dagstidnings-tävling byter sin transaktionella e-postleverantör från Mailchimp till Amazon SES utan att uppdatera sitt SPF-record. Bekräftelsemejl börjar misslyckas med SPF-kontroller hos Microsoft Outlook och bulkmappas, vilket gör att väljare missar bekräftelsefönstret. Tävlingsadministratören diagnostiserar problemet med MXToolbox, lägger till include:amazonses.com i SPF-recorden och leveransbarheten återhämtar sig inom DNS-spridningsfönstret (vanligen 0–48 timmar beroende på TTL-inställningar).
Relaterade begrepp
SPF är en av tre pelare i e-postautentiseringsstacken: se DKIM för kryptografisk signaturverifiering och DMARC för policylagret som agerar på SPF- och DKIM-resultat. Den praktiska påverkan på tävlingsoperationer beskrivs i Email Confirmation Vote, där leveransbarhet av bekräftelsemeddelandet är det enskilt mest kritiska operativa beroendet. BIMI (Brand Indicators for Message Identification), en nyare standard som bygger på DMARC, tillåter verifierade avsändare att visa en varumärkeslogotyp hos stödjande brevlådeleverantörer — en framväxande förtroendesignal som inte täcks här.
