SPF-postens syntax: mekanismer, kvalificerare och gränser

En SPF-post är en enda DNS TXT-post, publicerad på domänens rot, som börjar med v=spf1, listar de e-postservrar som får skicka i ditt namn och avslutas med en all-mekanism som talar om för mottagarna vad de ska göra med allt annat. v=spf1 include:_spf.google.com ~all är en komplett och giltig post. All övrig SPF-syntax är variationer på dessa tre delar - plus en uppsättning hårda gränser som tyst knäcker poster som annars ser helt korrekta ut.

De gränserna spelar större roll än de flesta tror. I en skanning av 5 499 028 domäner från Tranco-listan, genomförd den 27 februari 2026, fann DMARCguard att 56,0 % publicerar en SPF-post - fler än DMARC (30,4 %) och DKIM (22,7 %) - men att 4,8 % av dessa SPF-poster, 148 655 domäner, överskrider taket på tio DNS-uppslag i RFC 7208 och därmed misslyckas helt vid utvärdering.

De tre delarna i varje SPF-post

Varje giltig post är uppbyggd på samma sätt:

v=spf1  ip4:203.0.113.10  include:_spf.google.com  -all
  |            |                    |               |
version    mekanism             mekanism        fångar allt

1. Versionstaggen. v=spf1 måste vara den första termen och måste stämma exakt. Allt annat innebär att posten inte är en SPF-post över huvud taget.
2. Mekanismer. Utvärderas strikt från vänster till höger. Den första mekanism som matchar den anslutande IP-adressen avgör resultatet och utvärderingen avbryts direkt - ordningen är inte kosmetisk.
3. Fångstmekanismen. En all-mekanism som sista term. Allt som publiceras efter all ignoreras.

En sak som är värd att vara noggrann med: SPF kontrollerar kuvertavsändaren i SMTP-kommandot MAIL FROM (Return-Path) samt HELO-identiteten. Den kontrollerar inte den From:-rubrik som mottagaren faktiskt ser. Att täppa till det gapet är DMARC:s uppgift, vilket är skälet till att de två alltid införs tillsammans. Om du fortfarande kartlägger helheten går vår guide till DNS-säkerhetskonfiguration igenom hur SPF, DKIM, DMARC och DNSSEC hänger ihop.

SPF hade en gång en egen DNS-posttyp (typ 99). RFC 7208 §3.1 pensionerade den i april 2014 - publicera SPF enbart som en TXT-post.

SPF-mekanismer: den fullständiga referensen

En detalj som ofta missförstås: include: är ingen textinklistring. Den kör en fullständig, separat SPF-utvärdering mot den inkluderade domänen och matchar bara om den utvärderingen returnerar pass. Ett -all inuti en inkluderad post avvisar alltså inte din e-post - det gör bara att include: inte matchar, och utvärderingen fortsätter till nästa mekanism.

Kvalificerare: fyra tecken som avgör utfallet

Varje mekanism kan bära ett kvalificerarprefix. RFC 7208 §4.6.2 definierar exakt fyra, och standardvärdet är +.

Publicera aldrig +all. Det ger hela internet rätt att skicka i din domäns namn och är strikt sämre än att sakna SPF-post.

Modifierare: redirect och exp

Modifierare är namn/värde-par snarare än mekanismer, och de får bara förekomma en gång var.

• redirect=example.com ersätter hela din posts resultat med måldomänens SPF-resultat. Den kostar ett DNS-uppslag och ignoreras helt om en all-mekanism finns med, så de två bör inte förekomma tillsammans.
• exp=explain.example.com pekar på en TXT-post med en läsbar förklaringstext som returneras vid fail. Den kostar inget uppslag vid utvärderingen.

Gränserna som knäcker i övrigt giltiga poster

Det är här de flesta verkliga SPF-fel bor. Allt nedanstående kommer direkt från RFC 7208 §3.4 och §4.6.4:

• Tio DNS-frågande termer. Mekanismerna include, a, mx, ptr och exists samt modifieraren redirect förbrukar ett uppslag var. Att överskrida tio MÅSTE ge permerror - ett hårt fel, inte en varning. all, ip4, ip6 och exp är gratis.
• Två tomma uppslag. En fråga som ger NXDOMAIN eller ett tomt svar kallas "void lookup". Implementationer bör begränsa dessa till två; att överskrida gränsen ger också permerror. Kvarglömda include: för tjänster ni slutat använda är den vanliga boven.
• Tio adressposter per mx eller ptr. Utöver den totala budgeten är varje enskild MX-värd begränsad till tio A/AAAA-poster.
• En post per domän. Om ett uppslag returnerar mer än en v=spf1-post blir resultatet permerror. Slå ihop dem till en enda post; publicera aldrig två.
• 255 tecken per sträng, 450 oktetter rekommenderat totalt. En TXT-post kan innehålla flera citerade strängar som sammanfogas utan mellanslag. RFC 7208 §3.4 rekommenderar att hela DNS-svaret hålls under 450 oktetter så att det ryms i ett UDP-paket.
• Tjugo sekunders utvärderingsbudget. Mottagare bör tillåta minst 20 sekunder och returnera temperror därefter.

Vart dina tio uppslag faktiskt tar vägen

Varje extern avsändare du lägger till kostar minst ett uppslag, och några kostar mer eftersom deras egna poster i sin tur innehåller fler include-satser.

Sex eller sju tjänster och du ligger vid taket. Åtgärderna, i prioritetsordning: ta bort include-satser för tjänster ni lagt ner, flytta avsändare till egna subdomäner med egna SPF-poster, och först därefter överväg att platta ut include-satser till bokstavliga ip4:-intervall - utplattning tar bort uppslag men innebär att du själv måste hålla reda på leverantörernas IP-ändringar.

Andel domäner som publicerar en SPF-post, per toppdomän. Källa: DMARCguard, "State of Email Authentication 2026", skanning av 5 499 028 Tranco-domäner, 27 februari 2026.

Fem syntaxfel som ger PermError

1. Två v=spf1-poster på samma namn. Vanligt efter en migrering. Slå ihop, stapla inte.
2. En kvalificerare på all som motsäger avsikten - ?all ser försiktigt ut men säger ingenting till mottagarna, så förfalskad post går rakt igenom.
3. Termer efter all. Allt till höger om all är död text.
4. Kvarglömd ptr. Avrådd sedan 2014, långsam, och den bränner ett uppslag utan nytta.
5. Include-satser för nedlagda leverantörer. De kostar ett uppslag var och kan bli tomma uppslag när leverantören tar bort sin post.

Så kontrollerar du din egen post

Läs posten direkt från DNS med en enda fråga:

dig +short TXT example.com

På Windows är motsvarigheten nslookup -type=TXT example.com. Leta efter exakt en sträng som börjar med v=spf1 och räkna sedan de uppslagskrävande termerna för hand - och kom ihåg att räkna dem som göms inuti varje include:.

Sedan februari 2024 kräver Google och Yahoo att massutskickare (ungefär 5 000 meddelanden om dagen eller fler) autentiserar med både SPF och DKIM och publicerar en DMARC-post med minst p=none. Ett permerror från en trasig SPF-post äventyrar den efterlevnaden, så det är värt att verifiera i stället för att anta.

Kör en gratis 60-sekunders FortifyNet-skanning så kontrollerar vi din SPF-post tillsammans med DKIM, DMARC, din TLS-konfiguration, säkerhetsheaders och exponering på dark web - utan registrering.

Vanliga frågor

Kan en domän ha två SPF-poster? Nej. Om ett uppslag returnerar mer än en v=spf1-post kräver RFC 7208 §4.5 att mottagaren returnerar permerror, vilket får SPF att misslyckas helt. Slå ihop mekanismerna till en post.

Ska jag använda -all eller ~all? Börja med ~all medan du säkerställer att alla legitima avsändare är listade, och gå sedan över till -all. -all är den starkare signalen mot förfalskning, men först när din avsändarinventering verkligen är komplett.

Räknas ip4:-poster mot gränsen på tio uppslag? Nej. ip4:, ip6:, all och exp gör inga DNS-frågor vid utvärderingen och är undantagna. Bara include, a, mx, ptr, exists och redirect räknas.

Stoppar SPF ensamt förfalskning? Nej. SPF validerar kuvertavsändaren, inte den From:-rubrik som mottagaren läser. En angripare kan klara SPF på en domän hen kontrollerar och samtidigt visa din. DMARC binder ihop de två identiteterna, och det är det som faktiskt täpper till gapet.

Hur lång får en SPF-post vara? Varje enskild sträng i en TXT-post är begränsad till 255 tecken, men flera strängar sammanfogas. RFC 7208 rekommenderar att hela DNS-svaret hålls under 450 oktetter så att det överlever i ett UDP-paket.

Relaterade guider

• SPF-kontroll: så testar, läser och fixar du din SPF-post
• Så konfigurerar du DMARC steg för steg
• Vad är DKIM? DomainKeys Identified Mail förklarat

---

Källor: RFC 7208, Sender Policy Framework (SPF) version 1, IETF, april 2014 (§3.1, §3.4, §4.5, §4.6.2, §4.6.4, §5.5, §6.1, §6.2) · DMARCguard, "State of Email Authentication 2026", skanning av 5 499 028 Tranco-domäner, 27 februari 2026 · Googles och Yahoos krav på massutskickare, i kraft sedan februari 2024.