SPF: hvem kan sende e-post på vegne av domenet ditt?

Modul 4: Poster for e-post · Lesetid: 10 minutter

Læringsmål: Etter denne leksjonen kan du lese en SPF-post, legge til en tjeneste riktig og unngå de tre mest kjente SPF-feilene: to poster, +all og mer enn ti oppslag.

Nøkkelbegreper: SPF, v=spf1, mekanisme (a, mx, ip4, ip6, include), kvalifikator (+ - ~ ?), all, én SPF-post, grense på 10 DNS-oppslag, envelope-avsender (Return-Path)

Problemet: hvem som helst kan bruke navnet ditt

E-post ble laget på åttitallet for et lite, vennlig internett. Enhver e-postserver kan sende en e-post med info@example.com som avsender, selv om den serveren ikke har noe som helst med example.com å gjøre. Svindlere utnytter dette til fulle.

SPF (Sender Policy Framework, RFC 7208) er et første steg for å forhindre dette. I en SPF-post oppgir du hvilke servere som har lov til å sende e-post på vegne av domenet ditt. En mottakende e-postserver sjekker ved hver innkommende e-post: kommer denne e-posten fra en server som står på listen?

Tenk på det som en gjesteliste ved en dør. Dørvakten (den mottakende e-postserveren) henter listen fra domenet ditt og sjekker om besøkeren (den sendende serveren) står på den.

Hvordan ser en SPF-post ut?

En SPF-post er en TXT-post på domenenavnet ditt som starter med v=spf1:

example.com.  3600  IN  TXT  "v=spf1 mx ip4:192.0.2.25 include:spf.mailer.example ~all"

Du leser den fra venstre til høyre. Mottakeren går gjennom delene én etter én og stopper ved den første som passer.

Slutten: ~all, -all, ?all eller +all

Foran hver del kan det stå et tegn som sier hva som skjer hvis delen passer. For all (som alltid passer) utgjør det tegnet hele forskjellen:

Står det ikke noe tegn, gjelder +. mx betyr altså +mx.

Hvilken velger du? ~all er en trygg standard. -all er strengere og bra hvis du er sikker på at alle avsenderne dine står i posten. Bruker du DMARC (leksjon 4.5), er det til slutt DMARC-policyen som bestemmer hva som skjer; mange administratorer velger da ~all.

Feil 1: to SPF-poster

Det kan bare finnes én SPF-post per domene. Finner mottakeren to, blir resultatet en feil (permerror), og SPF-en din teller ikke i det hele tatt. Det er verre enn å ikke ha SPF.

Dette går ofte galt i praksis. En nyhetsbrevtjeneste eller Microsoft 365 sier "legg til denne SPF-posten", og plutselig står det en ny v=spf1-post ved siden av den gamle. Løsningen: legg den nye tjenesten til i den eksisterende posten.

Feil:

"v=spf1 mx include:spf.oldhost.example ~all"
"v=spf1 include:spf.protection.outlook.com -all"

Riktig:

"v=spf1 mx include:spf.oldhost.example include:spf.protection.outlook.com ~all"

Pass på: ikke fjern servere du fortsatt bruker når du slår sammen poster. Sender nettstedet ditt e-post via serveren til hostingselskapet ditt, må den fortsatt stå der, selv om vanlig e-post går til Microsoft 365. En hostingpakke har ofte allerede en standard-SPF med en include fra hostingselskapet (hos WebOké er det for eksempel include:webawere.nl); la den stå så lenge nettstedet eller skjemaene dine sender e-post via den serveren.

Feil 2: +all eller en for romslig post

+all til slutt, eller en enorm rekke som ip4:0.0.0.0/0, betyr at alle har lov. Da beskytter ikke SPF-en lenger noe som helst, og spamfiltre ser det som et dårlig tegn.

Feil 3: mer enn ti oppslag

For å sjekke en SPF-post må mottakeren noen ganger stille ekstra DNS-spørringer. Hver include, a, mx, exists, ptr og redirect koster ett oppslag, og en include teller også med alle oppslagene i posten den peker til. Ifølge RFC 7208 kan ikke totalen overstige ti. Går det over, blir resultatet permerror, og SPF feiler.

ip4 og ip6 koster ikke noe oppslag. all heller ikke.

I tillegg kan maksimalt to oppslag komme "tomme" tilbake (et navn som ikke finnes eller ikke har noe svar). En include til en tjeneste du ikke bruker lenger, og som har fjernet posten sin, kan altså også gi problemer.

Bruker du mange tjenester, tell etter med et SPF-kontrollverktøy (leksjon 8.3) og fjern tjenester du ikke lenger bruker.

Hva SPF ikke gjør

SPF kontrollerer envelope-avsenderen: den tekniske avsenderadressen (Return-Path) som e-postservere bruker seg imellom. Det er ikke alltid samme adresse som "Fra:"-adressen du ser i e-postprogrammet ditt. En nyhetsbrevtjeneste sender ofte med en egen Return-Path. SPF alene stopper dermed ikke enhver forfalsket avsender. Det er DKIM (leksjon 4.4) og DMARC (leksjon 4.5) til for.

SPF svikter også ved videresending: sender du e-post automatisk videre til en annen adresse, kommer e-posten frem til sluttmottakeren fra en server som ikke står i din SPF.

Hvorfor det betyr noe

Store e-postleverandører har blitt strengere. Siden februar 2024 krever Gmail og Yahoo at alle som sender e-post, minst har SPF eller DKIM, og at de som sender mye e-post (mer enn omtrent 5 000 per dag) har SPF, DKIM og DMARC. Microsoft stiller samme krav for Outlook.com, Hotmail og Live.com siden mai 2025. Selv om du sender lite e-post, hjelper en god SPF-post mot søppelpostmappen.

I praksis: slik ser det ut i et panel

I dette eksempelet bruker vi DirectAdmin. I DNS Administration klikker du på blyanten bak TXT-posten som starter med v=spf1. DirectAdmin åpner en SPF-hjelper: under Include Domain fyller du inn domenet til tjenesten (uten include:), under Mode velger du SoftFail (~all) eller Fail (-all). Nederst ser du hele posten. Min side har en tilsvarende SPF-hjelper på fanen DNS.

Andre paneler har ikke alltid en slik hjelper. Da redigerer du TXT-posten som vanlig tekst; innholdet er akkurat det samme.

Oppsummering

• SPF er en TXT-post med v=spf1 som sier hvilke servere som har lov til å sende e-post på vegne av domenet ditt.
• Nøyaktig én SPF-post per domene. Ny tjeneste? Legg den til i den eksisterende posten.
• Avslutt med ~all eller -all, aldri med +all.
• Maksimalt ti DNS-oppslag (include, a, mx, exists, ptr, redirect), ip4/ip6 teller ikke med.
• SPF ser på envelope-avsenderen; for ekte beskyttelse trenger du også DKIM og DMARC.

Quiz

Oppgave

Oppgave Z4.3: Slå opp SPF. Slå opp SPF-posten til google.com (eller til ditt eget domene). Lim inn hele posten, og fyll inn hva den avsluttes med (~all, -all, ?all eller +all). For ditt eget domene sjekker oppgaven også om du har nøyaktig én SPF-post.

Oppgave O4.3: Still inn selv i øvingssonen din. I øvingssonen bruker du en falsk tjeneste; for ditt eget domene bruker du den ekte include-en som e-postleverandøren din oppgir (for eksempel include:_spf.google.com). Lag en SPF-post i øvingssonen din <code>.dnspractice.eu som tillater: MX-serverne til sonen (mx), adressen 192.0.2.25 og øvingstjenesten _spf.mailsuite-demo.dnspractice.eu. Andre servere er mistenkelige eller ikke tillatt, så posten avsluttes med ~all eller -all.

Les mer

Trinnene i disse artiklene gjelder for panelene til WebOké; i andre paneler fungerer det på lignende måte.

• DirectAdmin-veiledning 5.7: SPF stille inn og utvide
• Hvordan fungerer SPF-recorden i DNS?
• Legge til eller endre en SPF-post i DirectAdmin
• WebOké-veiledning 5.5: DNS-hjelpere: MX, SPF, DMARC, CAA og SRV
• RFC 7208 (SPF), spesielt avsnitt 4.6.4 (grense på ti oppslag og to tomme oppslag)