Defaults.Exposed › Fikser › SPF (Sender Policy Framework)

Slik fikser du SPF (Sender Policy Framework)

SPF er linjen i domeneinnstillingene dine som lister opp hvilke e-posttjenester som faktisk har lov til å sende e-post på vegne av virksomheten din. Uten den kan hvem som helst i verden sende e-post som ser ut til å komme fra deg — og din egen genuine e-post havner lettere i kundenes søppelpost.

Bunnlinjen for virksomheten din: Hvem som helst kan sende e-post og utgi seg for å være din virksomhet — til kunder, ansatte og leverandører — fakturaer, betalingsendringer og alt mulig. Samtidig er det større sjanse for at dine egne genuine tilbud og fakturaer havner i søppelpost, slik at avtaler stilles i ro uten at du forstår hvorfor.

Hva dette kan koste deg

En svindler sender en falsk faktura 'fra deg' til en av dine kunder med sine egne kontoopplysninger, og kunden betaler. Du får vite om det uker senere når kunden spør etter varene sine — og nå er det ditt rykte, og muligens ditt ansvar.
Dine tilbud, fakturaer og svar havner stille i kundenes søppelpost fordi store e-postleverandører ikke kan verifisere at de virkelig er fra deg. Avtaler kjøles ned og du forstår aldri hvorfor.
En svindler utgir seg for å være deg eller en økonomiansvarlig og sender e-post til ansatte med en forespørsel om en hasteoverføring eller gavekort — meldingen ser genuint ut til å komme fra domenet ditt, så noen betaler.
En større prospekts IT- eller sikkerhetsgjennomgang sjekker domenet ditt, ser ingen avsenderbeskyttelse, og enten dropper deg eller ber deg fikse det før de signerer — noe som koster deg avtalen eller uker med forsinkelse.
Du tror du er beskyttet fordi en SPF-post finnes — men den er satt til 'myk feil' uten noe som håndhever den, eller den er stille ødelagt, slik at forfalsket e-post fortsatt slipper gjennom.

Hvorfor det er viktig. Å forfalske 'fra'-adressen på en e-post er trivielt enkelt og koster en angriper ingenting. SPF er den billigste og raskeste måten å gjøre domenet ditt vanskeligere å etterligne og å holde din genuine e-post ute av søppelpost. Google og Yahoo sender nå aktivt e-post til søppelpost eller avviser den fra domener som ikke er autentiserte, så dette er ikke lenger valgfritt — det er grunnleggende for at e-posten din i det hele tatt skal leveres.

Kort fortalt

Akkurat nå, med mindre du har SPF satt opp riktig, kan hvem som helst i verden sende e-post som ser ut til å komme fra virksomheten din. De kan sende falske fakturaer til kundene dine, falske betalingsforespørsler til de ansatte, og e-post til leverandørene som om det var deg — og meldingene vil se genuine ut, fordi ingenting på domenet ditt sier noe annet.

SPF (Sender Policy Framework) er løsningen. Det er én enkelt tekstlinje i domenets DNS-innstillinger som lister opp hvilke e-posttjenester som faktisk har lov til å sende e-post som deg. Mottakende e-postleverandører — Gmail, Outlook og alle andre — sjekker den listen før de avgjør om en melding er ekte. Ingen liste, eller en svak en, og de har ingenting å gå etter.

Denne siden dekker to ting som begge må være riktige: om en SPF-post i det hele tatt eksisterer, og om den er satt strengt nok til å faktisk gjøre jobben sin.

Hva dette kan koste deg

Dette er de hverdagslige, virkelige måtene en manglende eller svak SPF-post fører til at penger og tillit forsvinner. Vi nevner aldri en ekte virksomhet — dette er mønstrene vi ser på tvers av dataene.

Fakturabyttet. En kriminell sender en av kundene dine en e-post som ser nøyaktig ut som den kom fra deg, vedlagt en ekte-utseende faktura med sin egen bankkonto. Kunden betaler. Det første du hører er en purring om hvor bestillingen er. Nå er det en sint kunde, en betaling som gikk til en kriminell, og en vanskelig samtale om hvem som bærer tapet.
Direktør/finans-svindelen. Noen sender din bokholder «fra» deg som eier: «Raskt spørsmål — kan du skyve denne betalingen igjennom før dagen er omme?» Fordi meldingen genuint ser ut til å komme fra domenet ditt, vekker den ikke mistanke. Penger forlater virksomheten.
Den stille leveringsskatten. Tilbudene og fakturaene dine begynner å havne i kundenes søppelpostmapper fordi Gmail og Yahoo ikke kan verifisere at de virkelig er fra deg. Du får ingen bouncing, ingen feil — avtaler kjøles bare ned. Du taper forretninger og kan ikke engang se at det skjer.
Den tapte kontrakten. En større klients innkjøps- eller sikkerhetsteam kjører en grunnleggende sjekk på domenet ditt som del av onboarding. De ser ingen avsenderautentisering og flagger deg som en risiko. I beste fall haster du for å fikse det under press; i verste fall velger de en konkurrent som bestod.
Merkevareforgivelsesbølgen. Domenet ditt brukes i en phishing-kampanje rettet mot allmenheten. Folk som ble lurt stoler nå ikke på e-post med ditt navn på — så selv dine genuine tilbud og fornyelser blir ignorert eller rapportert.

Tråden gjennom alt dette: angriperen bruker ingenting, og virksomheten din bærer kostnadene og skylden.

Hva det faktisk er

Når en e-post ankommer, vil den mottakende e-postserveren vite én ting: er dette virkelig fra den det utgir seg for å komme fra? SPF svarer på deler av det spørsmålet.

Du publiserer en kort tekstlinje i domenets DNS-innstillinger — en «TXT-post» — som navngir e-posttjenestene som er autorisert til å sende på dine vegne. Noe slikt som:

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

På vanlig norsk lyder det: «Genuine e-poster fra oss kommer fra Googles servere og SendGrids servere — avvis alt annet som utgir seg for å være oss.»

De to delene som betyr noe for karakteren din:

Finnes posten? Dette er den viktige delen (den bærer mest vekt av alle enkle e-postkontroller). Ingen post betyr at mottakere ikke har noen liste å sjekke mot, så imitasjon er helt åpent. Det finnes også en subtil feilmodus her: hvis domenet ditt har to eller flere SPF-poster, sier reglene at alle er ugyldige — så du har effektivt ingen SPF i det hele tatt, selv om det ser ut som du har det.
Er policyen streng nok? En post kan eksistere men likevel være tannløs. Slutten — «all»-mekanismen — er instruksjonen til mottakerne:
- -all (hard feil) — avvis alt som ikke er på listen. Sterkest. Full uttelling.
- ~all (myk feil) + DMARC satt til reject — den moderne anbefalte oppsettet. Tilsvarende beskyttelse som hard feil, uten risikoen for at videresendt e-post bouncer. Full uttelling.
- ~all + DMARC satt til quarantine — akseptabelt, litt svakere; flytt DMARC til reject for full beskyttelse.
- ~all alene (ingen DMARC-håndhevelse) — svakt. Dette sier «sannsynligvis falskt, lever likevel.» Forfalsket e-post slipper fortsatt gjennom. Dette er fellen mange virksomheter faller i når de tror de er beskyttet.
- ?all (nøytral) — gir ingen beskyttelse.
- +all — aktivt farlig: det forteller verden at hvem som helst kan sende som deg. Bruk aldri dette.

Det er én usynlig feil til: SPF har kun lov til å utløse opptil 10 DNS-oppslag når det evalueres. Stable for mange include:-oppføringer og posten overskrider den grensen, og da behandler mottakerne hele greia som ødelagt — og du er tilbake til ingen beskyttelse. Dette er et vanlig, stille problem for virksomheter som bruker mange markedsførings- og SaaS-verktøy.

Hva «bra» ser ut som: nøyaktig én SPF-post, som lister opp alle tjenester som legitimt sender e-post som deg, avsluttet med -all (eller ~all kombinert med DMARC ved p=reject), og holder seg komfortabelt under 10-oppslag-grensen.

Slik fikser du det (gratis, ~10 minutter)

Send denne seksjonen til den som administrerer domenet eller nettstedet ditt — og merk at fiksen er gratis. Det er en endring i en DNS-innstilling, ikke et produkt du kjøper. Vi tar bare betalt for å overvåke at det holder seg riktig over tid, ikke for å gjøre endringen.

Steg 1 — List opp alle tjenester som sender e-post som deg. Dette er delen folk gjør galt. Skriv ned alle: e-postleverandøren din (Google Workspace, Microsoft 365 osv.), pluss eventuelle nyhetsbrevverktøy, CRM, helpdesk, e-handelsplattform, fakturerings-/regnskapsapp og bookingsystem. Hvis en tjeneste sender e-post med ditt navn og du glemmer den, vil SPF blokkere e-postene når du strammer inn policyen.

Steg 2 — Publiser én TXT-post på rotdomenet ditt. Kombiner «include»-linjene for alle avsenderne dine til én enkelt 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 det regionpassende domenet)

En kombinert post ser slik ut:

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

Hvor du legger den til, per leverandør:

Cloudflare: DNS → Poster → Legg til post → Type TXT, Navn @, Innhold = verdien ovenfor.
Microsoft 365 / Google admin: de publiserer den eksakte include-strengen som skal brukes i oppsettveiviseren; kopier den inn i TXT-posten hos DNS-verten din.
GoDaddy / de fleste verter: DNS-administrasjon → Legg til → TXT, Vert/Navn @, Verdi = posten.

Steg 3 — Start trygt, deretter håndhev. Mens du bekrefter at avsenderlisten din er komplett, publiser med ~all (myk feil) slik at ingenting legitimt blir blokkert ved et uhell. Når du har bekreftet at all din genuine e-post fortsatt flyter, stram inn til -all (hard feil) — eller, bedre, behold ~all og legg til en DMARC-policy med p=reject, som er det anbefalte moderne paret.

Steg 4 — Sørg for at du har nøyaktig ÉN post. Hvis en gammel SPF-post allerede finnes, rediger den i stedet for å legge til en ny. To v=spf1-poster kansellerer hverandre og lar deg stå ubeskyttet.

Steg 5 — Følg med på oppslagsantallet. Hvis du har mange avsendere, kan du sprenge 10-oppslags-grensen. Konsolider i så fall — noen leverandører tilbyr «SPF-flatting», eller fjern avsendere du ikke lenger bruker.

Steg 6 — Sjekk domenet på nytt for å bekrefte at det nå består, med posten til stede og policyen streng.

Vanlige feil

To SPF-poster. Den vanligste stille feilen. Å legge til en ny post i stedet for å redigere den eksisterende ugyldiggjør begge. Det må være nøyaktig én.
Stoppe ved ~all og anta at du er ferdig. Myk feil uten DMARC bak seg er den svake midtveien — det ser konfigurert ut men beskytter deg nesten ikke. Enten gå til -all, eller kombiner ~all med DMARC p=reject.
Glemme en avsender. Å stramme inn til -all før du har listet opp faktureringsappen, CRM eller nyhetsbrevverktøyet vil begynne å blokkere din egen legitimate e-post. List alt opp først.
Sprenge 10-oppslags-grensen. Hver include: kan lenke til flere oppslag. For mange og posten behandles som ødelagt. Hold det kompakt.
Bruke +all. Dette autoriserer eksplisitt hele internett til å sende som deg. Det er verre enn å ikke ha noen post. Publiser det aldri.

Hvor dette passer inn

SPF er grunnlaget, men det er ett av tre lag. DKIM legger til en kryptografisk signatur som beviser at en melding ikke ble manipulert, og DMARC er instruksjonen som binder SPF og DKIM sammen og forteller mottakerne hva de faktisk skal gjøre med e-post som feiler — inkludert blokkering av imitasjon av det synlige «fra»-navnet kundene dine ser. Få SPF riktig først (det er den raskeste gevinsten og bærer mest vekt), og legg deretter til DKIM og DMARC for å lukke døren fullstendig. Alle tre fikser er gratis.

Sett det opp hos din leverandør

Trinn for trinn for populære leverandører:

FAQ

Jeg er ikke teknisk anlagt — kan jeg ordne dette selv?

Du trenger ikke forstå detaljene. Endringen er én eller to linjer som legges til i domeneinnstillingene dine, gjort av den som administrerer nettstedet ditt eller IT-leverandøren din. Send dem avsnittet 'Slik fikser du det' nedenfor — det tar vanligvis noen minutter og er gratis. Vi tar bare betalt for å overvåke at det forblir riktig over tid.

Vi har allerede en SPF-post — betyr ikke det at vi er dekket?

Ikke nødvendigvis. Å ha en post er første halvdel; å ha den satt strengt er den andre. En post som slutter med '~all' (myk feil) uten DMARC bak seg, forteller mottakende servere 'dette kan være falskt, men lever det likevel' — noe som gir minimal beskyttelse. To SPF-poster, eller én som gjør for mange oppslag, behandles som ødelagt og gir deg ingen beskyttelse overhodet til tross for at den ser ut til å eksistere. Begge halvdelene må være riktige.

Vil det å fikse dette ved et uhell ødelegge min egen e-post?

Det kan det, hvis posten mangler en legitim avsender — for eksempel fakturaappen eller nyhetsbrevverktøyet som sender e-post i ditt navn. Det er nøyaktig derfor den sikre tilnærmingen er å liste opp alle tjenester som sender e-post som deg først, publisere med en myk '~all' mens du bekrefter at ingenting mangler, og deretter stramme inn til hard avvisning. Gjort i den rekkefølgen vil det ikke ødelegge noe.

Hva er forskjellen mellom '~all' og '-all', og hvilken bør vi bruke?

'-all' (hard feil) forteller mottakere å avvise alt som ikke er på listen din — den sterkeste innstillingen. '~all' (myk feil) sier 'sannsynligvis ikke legitimt, men godta det uansett.' Den moderne anbefalingen er '~all' kombinert med en DMARC-policy for 'reject' — det paret gir deg samme beskyttelse som '-all' uten risikoen for at videresendt e-post bouncer. '~all' alene, uten DMARC-håndhevelse, er den svake konfigurasjonen å unngå.

Vil SPF stoppe all e-postforfalskning alene?

Nei — det er det viktige første laget, ikke hele svaret. SPF sier hvilke servere som kan sende for deg, men forteller ikke mottakere hva de skal gjøre når en melding feiler, og dekker ikke det synlige 'fra'-navnet som en bruker ser. For å låse imitasjon fullstendig trenger du også DKIM og DMARC. SPF er det raskeste steget med størst effekt, så start her, og legg deretter til de to andre.

Hvor lang tid tar det å få det til å virke, og kan det koste noe?

DNS-endringer trer vanligvis i kraft innen minutter til noen timer. Selve fiksen er alltid gratis — det er bare å redigere en innstilling hos DNS-leverandøren din. Noen som forteller deg at det krever et betalt produkt for å legge til en SPF-post, tar feil.