SPF-kontroll: så testar, läser och fixar du din SPF-post
En SPF-kontroll visar på sekunder om din domän kan förfalskas. Så läser, testar och fixar du din SPF-post - och klarar de nya kraven från Google, Yahoo och Microsoft.
Kör samma kontroll direkt – gratis
Ange din domän och få en 9-punkts audit – DNS, SPF/DKIM/DMARC, SSL, säkerhetsheaders, dark web-exponering – på 60 sekunder.
Ingen registrering · <60s · GDPR/EU-hantering
E-post är fortfarande angriparnas vanligaste väg in i organisationer - och det billigaste tricket är att utge sig för att vara dig. FBI:s Internet Crime Complaint Center registrerade 193 407 anmälningar om nätfiske och spoofing under 2024, fler än någon annan brottstyp, och 2,77 miljarder dollar i förluster på grund av vd-bedrägerier (BEC) (IC3 Annual Report 2024). Första försvarslinjen mot att någon förfalskar din domän är en korrekt publicerad SPF-post - och snabbaste sättet att veta att din är frisk är att köra den genom en SPF-kontroll.
Den här guiden förklarar vad SPF är, hur du läser en post rad för rad, hur du kontrollerar den manuellt och med ett gratisverktyg, och exakt vilka fel en kontroll fångar innan de förstör din leveransbarhet.
Snabbkoll: FortifyNets kostnadsfria 60-sekundersskanning validerar SPF, DKIM och DMARC samtidigt. Kör en gratis skanning och se din e-postautentiseringspoäng direkt.
Vad är en SPF-post?
SPF (Sender Policy Framework) är en standard för e-postautentisering, definierad i RFC 7208, som låter en domänägare publicera listan över de e-postservrar som får skicka e-post för domänens räkning. Den ligger i DNS som en enda TXT-post som börjar med v=spf1. När en mottagande server tar emot ett meddelande slår den upp posten och kontrollerar om den avsändande serverns IP-adress är behörig.
En typisk post ser ut så här:
v=spf1 include:_spf.google.com include:sendgrid.net ip4:198.51.100.10 ~all
En viktig nyans: SPF autentiserar kuvertavsändaren (den dolda MAIL FROM-/Return-Path-adressen), inte den From:-adress som mottagarna faktiskt ser. Den luckan är just därför SPF behöver DMARC vid sin sida - mer om det nedan.
Relaterade guider: Vad är DMARC? · DNS-säkerhetskonfiguration
Därför behöver du en SPF-kontroll
Sedan februari 2024 kräver Google och Yahoo SPF av alla avsändare, plus fullständig SPF + DKIM + DMARC för den som skickar 5 000 eller fler meddelanden per dag till deras användare. Microsoft började tillämpa samma regler i maj 2025 (Red Sift). Sedan november 2025 avvisar Gmail icke-kompatibel massutskickspost direkt med 550-fel i stället för att skjuta upp den. Ett enda stavfel i din SPF-post kan numera innebära att dina fakturor, lösenordsåterställningar och nyhetsbrev studsar - inte hamnar i skräpposten, utan studsar.
En kontroll spelar roll eftersom SPF fallerar tyst. Posten flödar på tills den dag en mottagare bedömer att din post är trasig - och då gör den det inte längre. En kontroll förvandlar de osynliga problemen till ett tydligt godkänt eller underkänt som du kan agera på.
Så läser du din SPF-post
En SPF-post är en lista över mekanismer (vilka avsändare som tillåts) och kvalificerare (vad som ska hända med alla andra).
Vanliga mekanismer är ip4/ip6 (en specifik adress eller ett intervall), a (domänens A-post), mx (dess e-postservrar), include (delegera till en annan domäns SPF, t.ex. din e-postleverantör) och all (matchar allt, placeras alltid sist).
Kvalificeraren framför all är det viktigaste tecknet i hela posten:
| Kvalificerare | Symbol | SPF-resultat | Vad mottagare vanligtvis gör |
|---|---|---|---|
| Pass | + | Behörig | Levererar som vanligt |
| Fail (hardfail) | -all | Ej behörig | Avvisar meddelandet |
| Softfail | ~all | Troligen ej behörig | Tar emot, men markerar som misstänkt |
| Neutral | ?all | Inget ställningstagande | Levererar; ingen åsikt |
Bästa praxis 2026 är att kombinera ~all (softfail) med en DMARC-policy p=reject. M3AAWG och de flesta leveransbarhetsteam rekommenderar nu den kombinationen eftersom DMARC blir det verkliga tillämpningslagret, medan softfail undviker att råka blockera en bortglömd legitim avsändare (Valimail). Publicera aldrig +all - det ger hela internet behörighet att skicka som du.
Så kontrollerar du din SPF-post (steg för steg)
Du kan själv granska vilken domäns SPF-post som helst från en terminal:
- macOS/Linux:
dig TXT example.com +short - Windows:
nslookup -type=TXT example.com
Leta efter raden som börjar med v=spf1. Ser du två av dem är det redan ett problem (se nedan). Att läsa den råa posten visar vad som är publicerat, men räknar inte DNS-uppslag eller flaggar policymisstag - det är där ett dedikerat verktyg gör nytta.
För att kontrollera SPF, DKIM och DMARC i ett svep, kör FortifyNets gratis skanning: ange din domän så får du varje post tolkad, antalet DNS-uppslag och en prioriterad åtgärdslista på ungefär en minut.
Gränsen på 10 DNS-uppslag (felet de flesta verktyg fångar)
Detta är det vanligaste SPF-felet, och det förblir osynligt tills det slår till. RFC 7208 anger att en SPF-utvärdering får utlösa högst 10 DNS-uppslag. Mekanismerna include, a, mx, ptr och exists samt modifieraren redirect räknas alla; ip4, ip6 och all gör det inte. Överskrid 10 så returnerar mottagaren ett PermError, vilket underkänner SPF för varje meddelande du skickar (DMARCLY).
Det finns en tystare andra gräns också: högst 2 “void”-uppslag (mekanismer som inte resolverar till något). Ett dött include som pekar på en nedlagd leverantör kan tippa dig över den.
Det är lätt att överskrida 10 uppslag utan att märka det. Varje include: för en SaaS-leverantör (Google, Microsoft 365, ett CRM, en helpdesk, en marknadsföringsplattform) kan i sig innehålla nästlade includes, så tre eller fyra leverantörer räcker ofta. Lösningen är “SPF-flattening”: ersätt nästlade includes med de IP-intervall de resolverar till, eller konsolidera leverantörer.
Vanliga SPF-fel som en SPF-kontroll flaggar
| Vad kontrollen hittar | Resultat det utlöser | Så åtgärdar du det |
|---|---|---|
| Fler än 10 DNS-uppslag | PermError | Platta till eller ta bort include:; konsolidera avsändare |
| Fler än 2 void-uppslag | PermError | Ta bort includes, a eller mx som inte resolverar |
| Två eller fler SPF-poster | PermError | Slå ihop allt till en v=spf1-TXT-post |
| En sträng över 255 tecken | Ogiltig/avhuggen post | Dela upp i flera citerade strängar i samma TXT-post |
+all finns med | Godkänner alla förfalskningar | Ersätt med ~all eller -all omedelbart |
Ingen all-mekanism | Otydlig policy | Avsluta posten med ~all (eller -all) |
Autentiseringsgapet, i ett diagram
De flesta domäner gör fortfarande fel. Av 73,3 miljoner domäner som analyserades i december 2025 hade 83,9 % ingen DMARC-post alls och endast 2,5 % tillämpade p=reject - vilket innebär att de allra flesta kan förfalskas med litet motstånd (DMARC-adoption 2025). SPF är grunden som gör resten möjlig.
Källa: DMARC-adoptionsforskning, december 2025 (urval på 73,3 miljoner domäner). SPF matar DMARC-kontrollerna ovan.
Checklista för SPF (bästa praxis)
- Publicera exakt en
v=spf1-TXT-post per sändande domän. - Auktorisera varje legitim källa: din e-postvärd, marknadsföringsplattform, CRM, ärendehanteringssystem och varje server som skickar för din räkning.
- Håll det totala antalet DNS-uppslag på högst 10; platta till när du lägger till leverantörer.
- Avsluta med
~alloch backa upp med DMARCp=reject(eller använd-allpå parkerade domäner som inte skickar). - Lägg till SPF även för subdomäner och parkerade domäner - angripare älskar oanvända. En domän som aldrig skickar e-post bör publicera
v=spf1 -all. - Kontrollera igen efter varje ändring av dina e-postleverantörer; SPF driver iväg när din stack förändras.
SPF, DKIM och DMARC: hela bilden
SPF i sig är nödvändigt men inte tillräckligt. Tre poster fungerar tillsammans:
- SPF auktoriserar sändande servrar (kuvertavsändaren).
- DKIM signerar varje meddelande kryptografiskt så att det inte kan manipuleras under transporten.
- DMARC knyter SPF och DKIM till den synliga
From:-domänen (alignment), talar om för mottagare vad de ska göra när autentiseringen misslyckas och skickar rapporter till dig.
Du behöver alla tre för att uppfylla Google, Yahoo och Microsoft - och för att faktiskt stoppa spoofing. När din SPF går igenom, fortsätt med vår DMARC-guide, och använd MXToolbox-alternativet för löpande DNS- och e-postpostkontroller.
Vanliga frågor
Hur ofta bör jag kontrollera min SPF-post? Efter varje ändring av dina e-postleverantörer, och minst en gång per kvartal. SPF driver tyst iväg när du lägger till och tar bort SaaS-verktyg.
Kan jag ha två SPF-poster? Nej. En domän måste publicera exakt en v=spf1-TXT-post; två eller fler orsakar ett PermError. Slå ihop dem till en enda post.
Stoppar SPF all spoofing? Nej. SPF kontrollerar bara kuvertavsändaren, så angripare kan fortfarande förfalska den synliga From:-adressen. DMARC täpper till den luckan genom att kräva alignment - därför behöver du båda.
Vad är skillnaden mellan ~all och -all? ~all (softfail) säger åt mottagare att olistade avsändare troligen är obehöriga men att ta emot och flagga dem; -all (hardfail) säger åt dem att avvisa direkt. De flesta avsändare använder ~all plus DMARC-tillämpning.
Är ett gratis SPF-kontrollverktyg tillförlitligt? Ja. Ett bra verktyg gör samma DNS-uppslag och uppslagsräkning som en mottagande e-postserver. FortifyNets skanning validerar dessutom DKIM och DMARC i samma svep.
Kontrollera din SPF-post nu
En trasig SPF-post är osynlig tills din e-post slutar komma fram - och nu när Google, Yahoo och Microsoft avvisar oautentiserad post direkt har du inte råd att gissa. Kör FortifyNets kostnadsfria 60-sekundersskanning för att validera SPF, DKIM och DMARC, räkna dina DNS-uppslag och få en tydlig, prioriterad åtgärdslista. Ingen registrering krävs.
