Defaults.Exposed › Åtgärder › SPF (Sender Policy Framework)

Hur du fixar SPF (Sender Policy Framework)

SPF är den rad i din domäns inställningar som listar vilka e-posttjänster som faktiskt får skicka e-post i ditt företags namn. Utan den kan vem som helst i världen skicka e-post som ser ut att komma från dig — och din äkta e-post hamnar lättare i kundernas skräppost.

Slutsats för ditt företag: Vem som helst kan skicka e-post och utge sig för att vara ditt företag — till dina kunder, anställda och leverantörer — med falska fakturor, betalningsändringar och allt därtill. Samtidigt är risken stor att dina riktiga offerter och fakturor sorteras bort som skräppost, vilket leder till att affärer tyst rinner ut i sanden.

Vad detta kan kosta dig

En bedragare skickar en av dina kunder en faktura 'från dig' med sina egna kontouppgifter och får betalt. Du får reda på det veckor senare när kunden frågar var varorna är — och nu är det ditt rykte som står på spel, och möjligen även ditt ansvar.
Dina offerter, fakturor och svar hamnar tyst i kundernas skräppost för att stora leverantörer inte kan verifiera att de verkligen kommer från dig. Affärer svalnar och du förstår aldrig varför.
En bedragare utger sig för att vara din ägare eller ekonomiansvarig och e-postar personalen med en begäran om brådskande betalning eller presentkort — meddelandet verkar genuint komma från din domän, så någon betalar.
En större potentiell kund låter sin IT- eller säkerhetsavdelning granska din domän och ser inget avsändarskydd. I bästa fall tvingas du åtgärda det under tidspress; i värsta fall väljer de en konkurrent — du förlorar affären eller veckor av fördröjning.
Du tror att du är skyddad för att det finns en SPF-post — men den är satt till 'soft fail' utan att något verkställs, eller så är den tyst trasig, och förfalskad post passerar ändå igenom.

Varför det spelar roll. Att förfalska avsändaradressen på ett e-postmeddelande är trivialt enkelt och kostar angriparen ingenting. SPF är det billigaste och snabbaste sättet att göra din domän svårare att utge sig för att vara och att hålla din legitima e-post borta från skräppost. Google och Yahoo skräpar nu aktivt ned eller avvisar e-post från domäner som inte är autentiserade, så det här är inte längre valfritt — det är grundläggande för att din e-post ska levereras överhuvudtaget.

Kortversionen

Just nu, om du inte har SPF korrekt inställt, kan vem som helst i världen skicka e-post som verkar komma från ditt företag. De kan skicka dina kunder falska fakturor, skicka din personal falska betalningsuppmaningar och maila dina leverantörer som om de vore du — och meddelandena ser genuina ut, för ingenting i din domän säger något annat.

SPF (Sender Policy Framework) är lösningen. Det är en enda textrad i din domäns DNS-inställningar som listar vilka e-posttjänster som faktiskt får skicka e-post som du. Mottagande e-postleverantörer — Gmail, Outlook, alla — kontrollerar den listan innan de avgör om ett meddelande är äkta. Ingen lista, eller en svag sådan, och de har ingenting att gå på.

Den här sidan täcker två saker som båda måste vara rätt: om det finns en SPF-post överhuvudtaget, och om den är tillräckligt strikt för att faktiskt göra sitt jobb.

Vad det här kan kosta dig

Det här är de vardagliga, verkliga sätten ett saknat eller svagt SPF-skydd förvandlas till pengar och förtroende som försvinner. Vi namnger aldrig ett riktigt företag — det här är mönster vi ser i datan.

Fakturaomdirigering. En bedragare skickar en av dina kunder ett e-postmeddelande som ser exakt ut som det kom från dig, med en realistisk faktura med deras eget bankkonto. Kunden betalar. Det första du hör är ett påminnelsemail som frågar var beställningen är. Nu finns det en arg kund, en betalning som gått till en bedragare, och ett svårt samtal om vem som bär förlusten.
VD-/ekonomibedrägeri. Någon mailar din bokförare “från” ägaren: “Snabb tjänst — kan du skicka den här betalningen innan dagen är slut?” Eftersom meddelandet genuint verkar komma från din domän triggar det inte någons instinkter. Pengarna lämnar företaget.
Den tysta leveransskatten. Dina offerter och fakturor börjar hamna i kundernas skräppost för att Gmail och Yahoo inte kan verifiera att de verkligen kommer från dig. Du får ingen studs, inget felmeddelande — affärer tystnar bara. Du förlorar affärer och kan inte ens se att det händer.
Det förlorade kontraktet. En större kunds inköps- eller säkerhetsteam kör en grundläggande kontroll av din domän som en del av inledningen. De ser ingen avsändarautentisering och flaggar dig som en risk. I bästa fall ruskar du ihop en lösning under tidspressen; i värsta fall väljer de en konkurrent som klarade kontrollen.
Varumärkesförgiftningsvågen. Din domän används i en phishingkampanj riktad mot allmänheten. Människor som blivit lurade litar nu inte på ett enda e-postmeddelande med ditt namn på det — så även dina genuina erbjudanden och förlängningar ignoreras eller rapporteras.

Det gemensamma för allt detta: angriparen spenderar ingenting, och ditt företag bär kostnaden och skulden.

Vad det faktiskt är

När ett e-postmeddelande anländer vill den mottagande e-postservern veta en sak: är det här verkligen från den det påstår sig vara från? SPF besvarar delar av den frågan.

Du publicerar en kort textrad i din domäns DNS-inställningar — en “TXT-post” — som namnger de e-posttjänster som är tillåtna att skicka för din räkning. Något som:

v=spf1 include:_spf.google.com include:sendgrid.net -all

I klartext lyder det: “Äkta e-post från oss kommer från Googles servrar och SendGrids servrar — avvisa allt annat som påstår sig vara vi.”

De två delar som räknas för ditt betyg:

Finns posten överhuvudtaget? Det här är det viktigaste (det väger mest av alla enskilda e-postkontroller). Ingen post innebär att mottagare inte har någon lista att kontrollera mot, vilket innebär att utpekandet är helt öppet. Det finns också ett subtilt felläge här: om din domän har två eller fler SPF-poster säger reglerna att alla av dem är ogiltiga — så du har faktiskt ingen SPF alls, även om det ser ut som att du har det.
Är policyn tillräckligt strikt? En post kan finnas men ändå vara tandlös. Slutet — mekanismen “all” — är instruktionen till mottagare:
- -all (hard fail) — avvisa allt som inte finns på listan. Starkast. Fullt betyg.
- ~all (soft fail) + DMARC satt till reject — den moderna rekommenderade inställningen. Ekvivalent skydd med hard fail, utan risken att vidarebefordrad e-post studsar. Fullt betyg.
- ~all + DMARC satt till quarantine — acceptabelt, något svagare; flytta DMARC till reject för fullt skydd.
- ~all på egen hand (ingen DMARC-verkställighet) — svagt. Det här säger “förmodligen falskt, leverera ändå.” Förfalskad e-post passerar ändå igenom. Det här är fällan som många företag faller i och tror att de är skyddade.
- ?all (neutral) — ger inget skydd.
- +all — aktivt farligt: det säger till världen att vem som helst får skicka som du. Använd aldrig det här.

Det finns ytterligare ett osynligt fel: SPF är bara tillåtet att utlösa upp till 10 DNS-uppslag när det utvärderas. Stapla för många include:-poster och posten överstiger den gränsen, varpå mottagare behandlar hela saken som trasig — och du är tillbaka till inget skydd. Det här är ett vanligt, tyst problem för företag som använder många marknadsförings- och SaaS-verktyg.

Vad “bra” ser ut som: exakt en SPF-post, som listar alla tjänster som legitimt skickar e-post som du, som slutar med -all (eller ~all parad med DMARC på p=reject), och som bekvämt håller sig under gränsen på 10 uppslag.

Så här åtgärdar du det (gratis, ~10 minuter)

Skicka det här avsnittet till den som hanterar din domän eller webbplats — och notera att åtgärden är gratis. Det är en ändring av en DNS-inställning, inte en produkt du köper. Vi tar bara betalt för att övervaka att den förblir korrekt över tid, inte för att göra ändringen.

Steg 1 — Lista alla tjänster som skickar e-post som du. Det är det här folk får fel. Skriv ned alla: din e-postleverantör (Google Workspace, Microsoft 365 osv.), plus eventuella nyhetsbrevverktyg, CRM, helpdesk, e-handelsplattform, faktura-/bokföringsapp och bokningssystem. Om en tjänst skickar e-post med ditt namn och du glömmer den, blockerar din SPF dess e-post när du skärper policyn.

Steg 2 — Publicera en TXT-post på din rotdomän. Kombinera “include”-raderna för alla dina avsändare till en enda post. Per vanlig plattform:

Google Workspace: include:_spf.google.com
Microsoft 365: include:spf.protection.outlook.com
SendGrid: include:sendgrid.net
Mailchimp: include:servers.mcsv.net
Zoho: include:zoho.eu (eller den regionspecifika domänen)

En kombinerad post ser ut så här:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:sendgrid.net -all

Var du lägger till den, per leverantör:

Cloudflare: DNS → Poster → Lägg till post → Typ TXT, Namn @, Innehåll = värdet ovan.
Microsoft 365 / Google admin: de publicerar den exakta include-strängen att använda i sin installationsguide; kopiera den till din DNS-värds TXT-post.
GoDaddy / de flesta värdar: DNS-hantering → Lägg till → TXT, Värd/Namn @, Värde = posten.

Steg 3 — Börja säkert, skärp sedan. Medan du bekräftar att din avsändarlista är fullständig, publicera med ~all (soft fail) så att ingenting legitimt blockeras av misstag. När du bekräftat att all din äkta e-post fortfarande flödar, skärp till -all (hard fail) — eller bättre, behåll ~all och lägg till en DMARC-policy på p=reject, vilket är det moderna rekommenderade paret.

Steg 4 — Se till att du har exakt EN post. Om det redan finns en gammal SPF-post, redigera den snarare än att lägga till en till. Två v=spf1-poster tar ut varandra och lämnar dig oskyddad.

Steg 5 — Håll koll på uppslagens antal. Om du har många avsändare kan du blåsa igenom gränsen på 10 uppslag. Om det händer, konsolidera — vissa leverantörer erbjuder “SPF-utplattning”, eller ta bort avsändare du inte längre använder.

Steg 6 — Kontrollera din domän igen för att bekräfta att den nu klarar kontrollen, med posten på plats och policyn strikt.

Vanliga misstag

Två SPF-poster. Det vanligaste tysta felet. Att lägga till en ny post istället för att redigera den befintliga ogiltigförklarar båda. Det måste finnas exakt en.
Stanna vid ~all och anta att du är klar. Soft fail utan DMARC bakom sig är svag mellanväg — det ser konfigurerat ut men skyddar dig knappt. Gå antingen till -all, eller para ~all med DMARC p=reject.
Glömma en avsändare. Att skärpa till -all innan du listat din fakturaapp, CRM eller nyhetsbrevverktyg börjar blockera din egen legitima e-post. Lista allt först.
Blåsa igenom gränsen på 10 uppslag. Varje include: kan kedja till fler uppslag. För många och posten behandlas som trasig. Håll den smidig.
Använda +all. Det här auktoriserar uttryckligen hela internet att skicka som du. Det är värre än att inte ha någon post. Publicera det aldrig.

Var det här passar in

SPF är grunden, men det är ett av tre lager. DKIM lägger till en kryptografisk signatur som bevisar att ett meddelande inte har manipulerats, och DMARC är instruktionen som kopplar ihop SPF och DKIM och berättar för mottagare vad de faktiskt ska göra med e-post som misslyckas — inklusive att blockera utpekande av det synliga ‘från’-namn som dina kunder ser. Få rätt på SPF först (det är den snabbaste vinsten och väger mest), lägg sedan till DKIM och DMARC för att helt stänga dörren. Alla tre åtgärderna är gratis.

Konfigurera det hos din leverantör

Steg för steg för populära leverantörer:

Vanliga frågor

Jag är inte teknisk — kan jag lösa det här själv?

Du behöver inte förstå detaljerna. Åtgärden består av en eller två rader som läggs till i din domäns inställningar, utfört av den som hanterar din webbplats eller din IT-leverantör. Skicka avsnittet 'Så här åtgärdar du det' nedan till dem — det tar vanligtvis några minuter och kostar ingenting. Vi tar bara betalt för att övervaka att det förblir korrekt över tid.

Vi har redan en SPF-post — betyder inte det att vi är skyddade?

Inte nödvändigtvis. Att ha en post är första halvan; att den är strikt nog är den andra. En post som slutar med '~all' (soft fail) utan DMARC bakom sig säger till mottagarservrar 'det här kan vara falskt, men leverera ändå' — vilket ger minimalt skydd. Två SPF-poster, eller en med för många uppslag, behandlas som trasig och ger inget skydd alls trots att den verkar finnas. Båda delarna måste vara rätt.

Kan det hända att jag råkar blockera min egen e-post om jag åtgärdar det här?

Det kan hända om posten missar en legitim avsändare — till exempel din fakturaapp eller ditt nyhetsbrevverktyg som skickar e-post i ditt namn. Det är just därför den säkra metoden är att lista alla tjänster som skickar e-post för dig, publicera med '~all' medan du bekräftar att inget missas, och sedan skärpa till hard fail. Gjort i den ordningen bryts ingenting.

Vad är skillnaden mellan '~all' och '-all', och vilket bör vi använda?

'-all' (hard fail) säger åt mottagare att avvisa allt som inte finns på listan — den starkaste inställningen. '~all' (soft fail) säger 'förmodligen inte legitimt, men acceptera det ändå.' Den moderna rekommendationen är '~all' kombinerat med en DMARC-policy på 'reject' — det paret ger samma skydd som '-all' utan risk för att vidarebefordrad e-post studsar. '~all' ensamt, utan DMARC som verkställer det, är den svaga konfigurationen att undvika.

Kan SPF stoppa all e-postförfalskning på egen hand?

Nej — det är det nödvändiga första lagret, inte hela svaret. SPF anger vilka servrar som får skicka för dig, men det berättar inte för mottagare vad de ska göra när ett meddelande misslyckas, och det täcker inte heller det synliga 'från'-namn som användaren ser. För att fullt ut låsa ner utpekandet av avsändare vill du också ha DKIM och DMARC. SPF är det snabbaste steget med störst effekt, så börja här och lägg sedan till de andra två.

Hur lång tid tar det innan det träder i kraft, och kan det kosta något?

DNS-ändringar tar vanligtvis effect inom minuter till några timmar. Åtgärden i sig kostar alltid ingenting — det är bara att redigera en inställning hos din DNS-leverantör. Den som säger att du behöver köpa en betald produkt för att lägga till en SPF-post har fel.