SPF: liste over hvem som kan sende e-post for domenet

Hva er SPF?

SPF står for Sender Policy Framework. Dere publiserer en liste i DNS over servere og tjenester som har lov til å sende for domenet. Når en melding kommer inn, slår mottakeren opp listen og sjekker om serveren som leverte meldingen står på den.

Én detalj er verdt å kjenne til. SPF sjekker returadressen som brukes under selve leveringen, ikke nødvendigvis adressen som vises i «Fra»-feltet i e-postprogrammet. Derfor er SPF alene ikke nok til å stoppe forfalskning. DMARC knytter de to adressene sammen.

SPF er beskrevet i RFC 7208.

Slik ser en SPF-record ut

En SPF-record er en TXT-oppføring på selve domenet, ikke på et underdomene. Den begynner alltid med v=spf1. Deretter kommer en liste over godkjente avsendere, og til slutt en regel for alt annet.

Eksempelet under er for et domene der Microsoft 365 er eneste avsender. Verdien er hentet fra Microsofts veiledning.

• v=spf1 forteller at dette er en SPF-oppføring.
• include: henter inn listen til en annen tjeneste, her Microsoft.
• ip4: og ip6: godkjenner en bestemt IP-adresse, for eksempel en egen server.
• -all eller ~all til slutt bestemmer hva som gjelder for alle andre.

Type:   TXT
Navn:   (domenet selv, ofte vist som @ eller tomt)
Verdi:  v=spf1 include:spf.protection.outlook.com -all

-all eller ~all

-all betyr hard feiling: servere som ikke står på listen, er ikke godkjent, og meldingen bør avvises. ~all betyr myk feiling: de er trolig ikke godkjent, og meldingen bør merkes. Hva mottakeren faktisk gjør, avgjør mottakeren selv.

Offisielle veiledninger er ikke enige. Microsoft anbefaler -all for Microsoft 365-domener som også har DKIM og DMARC. Google anbefaler ~all.

I praksis: ~all er et trygt valg mens dere fortsatt kartlegger hvem som sender. Bytt til -all når listen er komplett og DMARC overvåker resultatet. Valget gjør mindre forskjell enn en komplett liste.

Grensen på 10 DNS-oppslag

Standarden setter en grense på 10 oppslag når en mottaker evaluerer SPF. Oppslagene teller for include, a, mx, ptr, exists og redirect. ip4, ip6 og all teller ikke. Og alt i en include teller også: hvis en tjeneste henviser videre til tre andre, bruker den fire oppslag.

Går dere over 10, blir resultatet permerror, altså en permanent feil. SPF feiler da for alle meldinger, også de fra godkjente servere. Microsoft beskriver at mottakeren da kan avvise meldingen.

Slik kommer dere under grensen: fjern tjenester dere ikke bruker lenger, flytt ekstern masseutsending til et eget underdomene med egen SPF-oppføring (anbefalt av Microsoft), eller bruk ip4 i stedet for include når leverandøren har faste adresser. Siste løsning krever at dere følger med på endringer.

To SPF-poster gir permerror

Et domene kan ha én SPF-oppføring. Har det to, gir mottakeren permerror, og SPF feiler. Dette skjer typisk når en ny leverandør ber dere «legge til denne TXT-oppføringen» og noen legger den inn ved siden av den gamle.

Slik retter dere det: slå sammen til én oppføring. Alle include-verdiene settes inn i samme linje, med én v=spf1 først og én all-regel sist. Ifølge egen måling 6. oktober 2026 av 928 norske e-postdomener hadde 0,5 % to SPF-oppføringer.

Vanlige include-verdier

Verdiene under kommer fra leverandørenes egne veiledninger. For alle andre leverandører: bruk verdien leverandøren selv oppgir.

• Microsoft 365: include:spf.protection.outlook.com
• Google Workspace: include:_spf.google.com (Googles eksempel: v=spf1 include:_spf.google.com ~all)
• Domeneshop e-post: include:_spf.domeneshop.no (Domeneshops standard: v=spf1 include:_spf.domeneshop.no ~all)
• one.com: include:_custspf.one.com

_custspf.one.com når e-posten ligger et annet sted

one.com bruker oppføringen include:_custspf.one.com som standard SPF-liste. Den godkjenner one.coms egne servere. Har domenet DNS hos one.com, ligger den ofte der fra før, selv om e-posten senere flyttes til Microsoft 365 eller Google Workspace.

Da oppstår to problemer. Det første er at Microsoft eller Google ikke er godkjent, så meldinger derfra feiler SPF. Det andre er at noen legger den nye leverandørens oppføring inn som en ny post i stedet for å endre den gamle, og dermed har to SPF-poster.

one.com viser selv oppsett der _custspf.one.com står sammen med Microsoft eller Google, for dem som fortsatt sender noe fra one.com, for eksempel et skjema på et webhotell. Hvis dere ikke sender noe fra one.com, trenger oppføringen ikke være der. Ifølge egen måling 6. oktober 2026 av 928 norske e-postdomener hadde 13 % av domenene med DNS hos one.com _custspf.one.com selv om e-posten lå et annet sted.

Slik retter dere det: åpne DNS-innstillingene hos one.com, finn TXT-oppføringen som begynner med v=spf1, og rediger den. Fjern _custspf.one.com hvis ingenting sendes derfra, og legg til include-verdien for dagens e-postleverandør. Opprett ikke en ny SPF-oppføring ved siden av.

Slik sjekker og retter dere SPF

1. Slå opp TXT-oppføringene på domenet og finn de som begynner med v=spf1. Det skal være nøyaktig én.
2. Lag en liste over alle som sender med domenet deres: e-postleverandøren, nettbutikk, nyhetsbrev, regnskapsprogram og kontaktskjema.
3. Sett alle include-verdiene inn i én oppføring, og avslutt med ~all eller -all.
4. Tell oppslagene. Er de over 10, fjern det dere ikke bruker, eller flytt noe til et underdomene.
5. Lagre, vent, og send en testmelding til en Gmail-adresse. Åpne «Vis original» og se etter spf=pass.

Sjekk domenet

Sjekk domenet deres på forsiden for å se SPF-oppføringen slik mottakerne ser den.

Vanlige spørsmål