SPF-post forklart – syntaks, test og trygt oppsett

En SPF-post forteller hvilke servere som får bruke et domene i e-postens tekniske returadresse. Den er nyttig, men lett å misforstå: SPF sjekker normalt ikke domenet brukeren ser i Fra-feltet, og en grønn SPF-test betyr derfor ikke automatisk at meldingen består DMARC.

Riktig oppsett begynner med en liste over faktiske avsendere. Bedriftens vanlige e-posttjeneste er bare én av dem. Fakturaprogram, nyhetsbrev, CRM, kontaktskjema, nettbutikk og supportsystem kan bruke andre returdomener og annen infrastruktur.

Hva SPF faktisk kontrollerer

Når en server leverer e-post, oppgir den en identitet i SMTP-dialogen. SPF sammenligner IP-adressen som kobler seg til med policyen for denne identiteten.

Returadressen vises ofte som Return-Path i en ferdig levert melding. Den brukes blant annet til feilmeldinger. En tredjepart kan derfor sende en melding med synlig Fra-adresse på dittfirma.no, men bruke sitt eget domene i returadressen. SPF kan da bestå for tredjeparten uten å beskytte det synlige domenet.

DMARC kobler SPF eller DKIM til det synlige Fra-domenet . For at SPF skal gi DMARC-bestått, må SPF både bestå og være alignet med Fra-domenet.

Hvor SPF-posten publiseres

SPF versjon 1 publiseres som én DNS-post av typen TXT på navnet som skal autorisere e-post. For dittfirma.no kan et kontrolloppslag være:

dig dittfirma.no TXT +short

Se etter verdien som begynner med v=spf1. Andre TXT-poster på samme navn, som verifiseringskoder, er ikke ekstra SPF-poster og kan ligge der samtidig.

Det er forskjell på flere TXT-poster og flere tekstsegmenter i samme TXT-post. En lang SPF-verdi kan vises som flere siterte segmenter som DNS-systemet setter sammen. Det er gyldig så lenge oppslaget gir én valgt SPF-post for navnet. To separate verdier som begge begynner med v=spf1, gir permerror.

Er navn, verdier, anførselstegn eller tekstsegmenter ukjent, begynn med grunnlaget for TXT-poster i DNS . Da blir det lettere å skille en teknisk gyldig TXT-post fra en riktig SPF-policy.

Den gamle DNS-typen SPF med typekode 99 skal ikke brukes. RFC 7208 krever TXT.

Slik leses en SPF-verdi

En illustrerende post kan se slik ut:

v=spf1 ip4:192.0.2.0/24 include:sender.example -all

Verdien skal ikke kopieres. Adressen er reservert for dokumentasjon, og sender.example er ikke en e-postleverandør. Eksemplet viser bare strukturen:

1. v=spf1 velger SPF-versjonen og må stå først.
2. Mekanismene vurderes fra venstre mot høyre.
3. Første mekanisme som matcher, avgjør resultatet.
4. all matcher alltid og avslutter derfor normalt posten.

Mekanismer etter all blir aldri vurdert.

Kvalifikatorene foran en mekanisme

I -all er minustegnet kvalifikatoren og all mekanismen. +all betyr at alle IP-adresser består og ødelegger formålet med posten.

Mekanismer og modifikatorer

ptr finnes fortsatt i syntaksen, men bruken er sterkt frarådet i RFC 7208. Den er treg, komplisert og kan skape mange oppslag.

include kopierer ikke teksten fra en annen post. Den starter en rekursiv SPF-evaluering og matcher bare når den refererte policyen gir pass for den aktuelle IP-adressen. En feil eller en ny underliggende include hos leverandøren kan derfor påvirke deres policy uten at hovedposten endres.

Skal posten slutte med ~all eller -all?

~all gir softfail for sendere som ikke matchet. -all gir fail. Forskjellen er et signal fra domeneeieren; det er fortsatt mottakeren som bestemmer hvordan meldingen håndteres.

Velg ikke avslutning ut fra en generell oppskrift. Kartlegg først alle legitime sendere, aktiver DKIM, test alignment og bruk DMARC-rapportene. Når dere kan forklare avsenderstrømmene og vet at ukjente servere ikke skal autoriseres, uttrykker -all en tydeligere policy.

Å bytte fra ~all til -all reparerer ikke:

• manglende leverandører i posten
• mer enn én SPF-post
• for mange DNS-oppslag
• feil returdomene hos en tredjepart
• DKIM- eller DMARC-feil

Test den faktiske e-postflyten før og etter endringen.

En sikker arbeidsrekkefølge

1. Finn hvilke domener som trenger policy

Send en test fra hver tjeneste til en ekstern postkasse dere kontrollerer. Åpne originalmeldingen og noter:

• synlig Fra-domene
• Return-Path eller SMTP-returdomene
• sendende IP-adresse
• SPF-resultat og domenet som ble vurdert
• DKIM-domene og selector
• DMARC-resultat

En tjeneste som bruker leverandørens eget returdomene trenger ikke nødvendigvis å stå i SPF-posten på rotdomenet deres. Den trenger derimot riktig DKIM- eller SPF-alignment for å bestå DMARC med deres synlige Fra-domene.

2. Lag et avsenderregister

Koble hver kilde til en tjeneste og en intern eier. Et enkelt register kan ha kolonnene system, formål, returdomene, leverandørkrav, ansvarlig og siste verifiserte test. Ukjente IP-adresser i en rapport skal undersøkes, ikke automatisk autoriseres.

3. Hent verdier fra aktiv leverandørdokumentasjon

Bruk den nøyaktige include, IP-adressen eller delegeringen leverandøren oppgir for deres løsning. Ikke gjett en SPF-verdi fra MX-navnet eller navnet på SMTP-serveren. MX styrer innkommende e-post og er ikke en generell liste over utgående servere.

4. Bygg én samlet policy

Hvis det allerede finnes en SPF-post, skal nye mekanismer inn i denne. Ikke opprett en ekstra post. Fjern samtidig tjenester dere med sikkerhet har avviklet.

Plasser smale og billige mekanismer tidlig når det gir mening. En kontrollert, stabil ip4 krever ikke DNS-oppslag under SPF-evalueringen, mens include, a og mx bruker av den samlede oppslagsgrensen.

5. Kontroller hele oppslagskjeden

Grensen er ti DNS-baserte mekanismer og modifikatorer under én evaluering, ikke ti ord i hovedposten. Leverandørens rekursive kjede teller med. I tillegg anbefaler standarden en grense på to resultatløse DNS-oppslag.

Den separate guiden viser hvordan dere teller og reduserer SPF-oppslag uten blind flattening .

6. Planlegg endring og tilbakeføring

Lagre nåværende verdi, tidspunkt, årsak og forventet resultat. Reduser TTL i forkant hvis endringen er risikofylt og DNS-leverandøren tillater det. Ikke gjør flere urelaterte e-postendringer samtidig; da blir det vanskelig å finne årsaken hvis leveringen endres.

Tilbakeføring betyr normalt å gjenopprette den forrige, dokumentert fungerende SPF-verdien. Den skal ikke være avhengig av hukommelse eller et gammelt skjermbilde.

Test både DNS og en ekte melding

Et DNS-verktøy kan kontrollere at posten finnes og at syntaksen kan evalueres. Det kan ikke bevise at sendetjenesten bruker returidentiteten dere forventer.

Etter publisering:

1. Spør en autoritativ navnetjener direkte og kontroller den nye TXT-verdien.
2. Spør flere rekursive resolvere etter at TTL-en gir grunn til å forvente oppdatering.
3. Kjør en rekursiv SPF-analyse og kontroller antall oppslag og feil.
4. Send en melding fra hver avsenderstrøm.
5. Kontroller mottakerens betrodde Authentication-Results.
6. Bekreft både spf=pass og domenet SPF evaluerte.
7. Bekreft om DMARC består via alignet SPF eller DKIM.

En test som bare viser at TXT-posten kan hentes, er ikke en ende-til-ende-test.

SPF-resultatene du kan møte

En permerror krever endring hos domeneeieren. Å vente på «DNS-propagering» reparerer ikke to SPF-poster eller en kjede med for mange oppslag.

Domener som ikke skal sende e-post

For et navn som aldri skal brukes som SMTP-identitet, kan en eksplisitt policy være:

v=spf1 -all

Publiser den bare på navn dere har bestemt ikke skal sende. En SPF-post på www.dittfirma.no gjelder ikke automatisk for rotdomenet, og en post på rotdomenet dekker ikke alle mulige underdomener. DNS-navnet som faktisk brukes som SPF-identitet må ha riktig policy.

SPF alene hindrer heller ikke angripere i å bruke et forvekslingsdomene eller en annen synlig Fra-identitet. Det inngår i et bredere oppsett med DKIM, DMARC, domenekontroll og gode rutiner mot phishing.

Teknisk grunnlag og neste steg

RFC 7208 definerer SPF, resultatene, mekanismene og behandlingsgrensene. Ved praktisk drift bør posten også vurderes i sammenheng med DKIM-selector og nøkler og DMARC-policy og rapportering .

Trenger bedriften postkasser på eget domene, finner dere kapasitet og pris under e-post for bedrifter . Har dere en SPF-feil, kan dere sende domenenavnet, den offentlige TXT-verdien og et anonymisert autentiseringsresultat via kundeservice . Ikke send passord eller private nøkler.