Hvad er en SPF-record? En komplet vejledning

En sikkerhedsteknologi som Sender Policy Framework (SPF) kan vise sig at være uvurderlig i en verden, der er plaget af onlineangreb og spam-beskeder.

Cybersikkerhed er et stort problem for alle, lige fra enkeltpersoner og virksomheder til statslige enheder. Sikkerhedsrisici som f.eks. e-mailforfalskning, phishing-angreb, spam og andre ondsindede metoder er blevet meget udbredt og er rettet mod data, applikationer, netværk og mennesker.

Som følge heraf kan webstedsejere lide tab af data, penge, omdømme og kundernes tillid. Og e-mails er en af de letteste angrebsveje.

SPF er en populær e-mail-valideringsmetode, der kan hjælpe med at afværge disse angreb ved at registrere e-mail-forfalskning og forhindre spam. Ved at bruge en SPF-record kan du også forhindre, at dine e-mails bliver markeret som spam af andre servere, inden de når frem til din målgruppe.

I denne artikel vil vi diskutere SPF-records, og hvorfor det er vigtigt at implementere denne teknik for at sikre e-mailsikkerheden.

Check vores videoguide om SPF Record

Hvad betyder SPF?

Før vi kommer til, hvad en SPF-record er, skal vi først forstå SPF.

Sender Policy Framework (SPF) henviser til en metode til autentificering af e-mails, der er designet til at opdage forfalskede afsenderadresser under e-maillevering.

Angribere forfalsker ofte afsenderadresser og får dem til at se ægte ud, som en almindelig brugers adresse. SPF kan hjælpe med at opdage disse meddelelser og sætte dem i karantæne og dermed afspore dem fra deres angreb.

SPF gør det muligt for serveren i den modtagende ende at kontrollere, om en e-mail, der ser ud til at komme fra et givet domæne, faktisk stammer fra en autoriseret IP-adresse på det pågældende domæne. Listen med alle autoriserede IP-adresser og hosts for et bestemt domæne findes i domænets DNS-records.

Hvad er en SPF-record?

En SPF-record er en slags TXT-record, der offentliggøres i en DNS-zonefil, og som indeholder en liste over alle de autoriserede mailservere, der kan sende e-mails på vegne af dit domæne. Det er en implementering af SPF, der skal tilføjes til din DNS for at hjælpe med at identificere og forhindre spammere i at sende ondsindede e-mails med falske adresser på dit domænes vegne.

Spammere udfører e-mail-spoofing ved at oprette en e-mail ved hjælp af falske afsenderadresser, da de fleste e-mail-servere ikke udfører autentificering. De redigerer derefter en e-mail-afsenderadresse ved at forfalske e-mail-hovedlinjerne, så det ser ægte ud, som om e-mailene er sendt fra dit domæne.

Denne proces kaldes spoofing, og den gør det muligt for spammere at snyde brugerne og få fat i deres private data og skade deres omdømme.

I dag har næsten alle skadelige e-mails falske adresser. Som følge heraf lider de personer, hvis e-mailadresser angriberne har stjålet, skade på deres omdømme, spilder tid på at rette op på afviste meddelelser, får deres IP-adresser sortlistet osv.

Derfor er det nødvendigt at oprette SPF-records for at forbedre din e-mail-leveringsmuligheder og -sikkerhed.

Syntaks for SPF-rekord

Generelt defineres en SPF-record ved hjælp af en type TXT-record (ikke at forveksle med den gamle SPF-filtyperecord).

En SPF-record starter med et “v”, som angiver den anvendte SPF-version. I øjeblikket skal denne version være “spf1”, da den anerkendes af de fleste mailudvekslingsservere.

Herefter følger andre udtryk, som definerer reglerne for værter, der sender e-mails fra det givne domæne. Disse termer kan også give flere oplysninger til behandling af SPF-record.

Eksempel på en SPF-record

Her er, hvordan en SPF-record ser ud, og hvad de enkelte dele af den betyder:

v=spf1 a include:_spf.google.com -all

• v=spf1 er SPF version 1, en komponent, der identificerer en TXT-record som en SPF-record.
• a autoriserer den host, der er registreret i domænets A-record, til at sende e-mails.
• include: bruges til at godkende e-mails, som afsenderen kan sende på vegne af et domæne (her google.com).
• -all fortæller modtagerens server, at de adresser, der ikke er opført i denne SPF-record, ikke er autoriseret til at sende e-mails. Den fortæller også serverne, at de skal afvise sådanne adresser.

Hvordan fungerer en SPF-record?

Enhver computer kan sende e-mails, der hævder at komme fra enhver adresse, som SMTP tillader. Angribere og svindlere udnytter dette ved at bruge forfalskede adresser, som er svære at spore.

En lignende teknik anvendes i phishing-angreb, hvor angriberne narrer brugerne til at afsløre deres personlige eller forretningsmæssige oplysninger ved at efterligne et ægte websted eller en ægte tjeneste, som brugerne ofte benytter.

For at modvirke dette gør SPF det muligt for et domænes ejer at definere, hvilke computere der har tilladelse til at sende e-mails fra det pågældende domæne ved hjælp af DNS-records. Desuden kan modtagerne afvise en e-mail fra en uautoriseret kilde efter at have verificeret adressen ud fra SPF-records, inden de modtager e-mailens indhold.

Som vi så i eksemplet ovenfor, er en SPF-record i form af en TXT-record, der indeholder en liste over alle IP-adresser på autoriserede e-mail-servere for dig. Du kan have en eller flere autoriserede IP-adresser indstillet til at sende e-mails i en SPF-record.

Når en autoriseret bruger sender en e-mail med en SPF-record aktiveret, udfører modtagerens mailserver et DNS-opslag for at finde den TXT-record og fastslå, om afsenderens IP-adresse er autoriseret.

Hvis den ikke finder nogen SPF-record, sender den en “hard fail”- eller “soft fail”-meddelelse til afsenderen.

Hvis modtagerens server afviser det pågældende domæne, skal den uautoriserede bruger eller klient modtage en afvisningsmeddelelse (“hard fail”). Men hvis klienten tilfældigvis er en message transfer agent (MTA), vil der i dette tilfælde blive genereret en afvisningsmail til den faktiske envelope-from-adresse (“soft fail”).

Komponenter i en SPF-record

SPF-poster består af flere forskellige dele, begyndende med versionsnummeret.

Versionsnummer

Alle SPF-records begynder med et versionsnummer, som skal godkendes af mekanismer, der definerer gyldige afsendere. SPF-versionnummeret, f.eks. spf1, efterfølges af en streng, der omfatter mekanismer, kvantificatorer og modifikatorer.

Mekanismer

Mekanismer beskriver de værter, der er udpeget som autoriserede udgående afsendere for et givet domæne. En SPF-record kan have nul eller flere mekanismer. Nogle af de almindelige mekanismer i SPF-records er følgende:

• a: Angiver alle IP-adresser i en DNS A-record (eksempel: v=spf1 a:google.com -all). Den bruges til sidst og definerer reglen for håndtering af en afsender-IP, der ikke passer til nogen tidligere mekanismer.
• mx: Definerer alle A-records i retning af den MX-record, der tilhører hver vært. Eksempel: v=spf1 mx mx:google.com -all
• include:: Definerer andre autoriserede domæner (eksempel: v=spf1 include:outlook.microsoft.com -all). Hvis politikken for det pågældende domæne er godkendt, vil denne mekanisme også være godkendt. Du har brug for redirect-udvidelsen, hvis du vil opnå fuld delegation med et andet domænes politik.
• ptr: Den definerer alle A-records mod PTR-posten for hver host (eksempel: v=spf1 ptr:domain.com -all). Du skal dog undgå denne mekanisme, hvis det er muligt.
• all: Matcher alle fjern- og lokale IP-adresser og anvendes i SPF-recordens ende (eksempel: v=spf1 +all).
• exists: Dette angiver domæner, der er afmeldt som en undtagelse i henhold til definitionen SPF. Når der køres en forespørgsel på et givet domæne, vil det være et match ved opnåelse af et resultat. Det bruges sjældent og giver mere komplicerede matches som f.eks. DNSBL-forespørgsler.
• ip4: Bruges til at definere en IPv4-adresse, f.eks. v=spf1 ip4:192.0.0.0.1 -all.
• ip6: Bruges til at definere en IPv6-adresse, f.eks. v=spf1 ip6:2001:db8::8a2e:370:7334 -all

Disse definerer alle de IP-adresser, der er godkendt til at sende e-mails fra domænet.

Kvantiteter

Mekanismer har en kvantifikator for at definere, hvordan de kan håndtere et match.

En e-mail-server sammenligner afsenderens IP-adresse med listen over de godkendte IP-adresser i mekanismerne. Når den finder et match for IP-adressen i en af SPF-mekanismerne, implementerer den reglen for håndtering af resultatet. Og standardreglen for dette er pass eller +.

De fire kvantifikatorer er som følger:

• + repræsenterer resultatet PASS. Hvis adressen består testen, skal meddelelsen accepteres (eksempel: v=spf1 +all). Du kan udelade det, fordi f.eks. +mx og mx er det samme.
• - står for HARDFAIL og angiver, at adressen ikke har bestået testen, og at e-mailen skal afvises (eksempel: v=spf1 -all).
• ~ står for SOFTFAIL og udtales som en tilde. Det betyder, at adressen ikke har bestået testen; resultatet er dog ikke endeligt. Du kan acceptere og mærke en e-mail, der ikke er i overensstemmelse med kravene (eksempel: v=spf1 ~all).
• ? står for NEUTRAL, hvor adressen hverken har fejlet eller bestået testen, og det står dig frit for at acceptere eller afvise den (eksempel: v=spf1 ?all).

Når du ikke ser nogen kvantifikator i en SPF-record, betyder det, at +all -kvantifikatoren er anvendt.

Modifikatorer

Modifikatorer giver dig mulighed for at udvide rammen. De er værdi- eller navnepar adskilt af = -tegnet og giver flere oplysninger. SPF-records kan også have nul, en eller to modifikatorer, men de kan kun optræde én gang, mod slutningen af den record.

De to mest udbredte modifikatorer er:

• redirect: Bruges til at sende en forespørgsel til andre domæner. Denne modifikator er let at forstå sammenlignet med andre mekanismer og modifikatorer og bruges, når du har flere domæner og har brug for at bruge den samme SPF-record overalt.
• exp: Bruges til at give en forklaring, når en FAIL-kantifikator er inkluderet i en matchet mekanisme. Denne forklaring vil blive placeret i SPF-loggen.

Hvorfor har du brug for SPF-records?

Hvis dit domæne har en SPF-record, mindsker det risikoen for at modtage ondsindede, forfalskede e-mails, hvilket øger din e-mailsikkerhed og beskytter den mod cyberangribere og spammere.

En SPF-record øger også dit domænes troværdighed og mindsker risikoen for at blive slettet af spamfiltre. Dette hjælper legitime e-mails med at finde vej til dig hurtigere.

Desuden er tilføjelse af SPF-rekorder i dit domæne blevet mere og mere afgørende for at verificere, hvilke afsendere der kan sende e-mails på vegne af dit domæne. Det giver mange fordele, som vi vil undersøge næste gang.

Øget e-mailsikkerhed

SPF-poster er med til at øge e-mailsikkerheden for både enkeltpersoner og virksomheder. I en tid med cybersikkerhed, hvor brugere fra hele verden rammes af cyberkriminalitet, skal du tage skridt til at beskytte din indbakke.

Tilføjelse af SPF-poster er en måde at gøre netop dette på. Ved at gøre det mere udfordrende for e-mailangribere at komme igennem, er der mindre sandsynlighed for, at spam-beskeder lander i din indbakke; dermed øges din e-mailsikkerhed.

Forbedret levering af e-mail

Hvis et domæne ikke har en SPF-record, kan dets e-mails afvises, eller servere kan markere dem som spam. Og hvis dette sker gentagne gange, reduceres dets evne til at sende e-mails med succes til dets målgruppe (også kendt som leveringsegnethed).

Dette bliver en vejspærring for enkeltpersoner og virksomheder, der bruger sådanne domæner til at nå deres målgruppe af kunder, medarbejdere, leverandører og andre tilknyttede personer.

Forbedret omdømme på domænet

Hvis dine brugere konstant modtager e-mails fra angribere, der udgiver sig for at være din virksomhed, er dit domænes troværdighed i fare. Dårlige aktører kan også skade dine kunder og medarbejdere ved at afsløre deres personlige oplysninger, hvilket vil skade dit omdømme yderligere.

Derfor er det vigtigt at beskytte dit domæne mod sådanne hændelser ved hjælp af SPF-records. Ved at begrænse afsendelsen af e-mails til kun autoriserede IP-adresser, der er opført i posterne, forhindrer du spam-meddelelser og reducerer sandsynligheden for sådanne angreb.

Overholdelse af DMARC

E-mail-verifikationssystemet DMARC sikrer, at kun autoriserede brugere sender e-mails på dit domænes vegne.

Dets politikker instruerer også servere om, hvordan de skal håndtere e-mails med mislykkede DKIM- og SPF-kontroller. DMARC anviser, at sådanne e-mails skal markeres som afvist, spam eller leveret.

Det giver også domæneadministratorer mulighed for at modtage rapporter, der fremhæver e-mailaktiviteter, og foretage justeringer af deres politikker i overensstemmelse hermed.

Hvem har brug for en SPF-record?

Du skal oprette en SPF-record for dit domæne, hvis du sender kommercielle og transaktionsrelaterede e-mails til dine kunder, medarbejdere eller leverandører. Ved at bruge forskellige e-mail-sikkerhedsløsninger bliver din e-mail-leveringsmuligheder og sikkerhed stærk.

• Virksomheder og enkeltpersoner: Med en e-mail-godkendelsesteknik som SPF-records på plads kan virksomheder og enkeltpersoner verificere, om en e-mail er sendt på vegne af deres domæne, eller om nogen gør det for deres personlige vindings skyld og snyder dine samarbejdspartnere. Og du kan gøre dette endnu stærkere ved at bruge SPF-records med DMARC eller DKIM for at angive en fuldstændig autentificeringspolitik for alle dine e-mails.
• Internetudbydere: SPF-poster er en fordel for internetudbydere. Hvis de ikke har opsat en SPF-record korrekt, skal de måske udføre e-mailfiltrering igen. Desuden fortæller en fejlslagen autentificering, at der er en mulighed for, at deres e-mails bliver blokeret eller genkendt som spam af mange servere.

Hvis du ønsker, at dine e-mails skal nå frem til den tilsigtede destination, kan du derfor sikre dig dette ved at bruge SPF-records og give bedre sikkerhed for dine domæner og e-mails. Det vil filtrere falske e-mails fra phishere og spammere og beskytte dit omdømme.

Sådan opretter, tilføjer og redigerer du SPF-records

Her er hvordan du kan tilføje, oprette og redigere dine SPF-records.

Sådan opretter du en SPF-records

Før du begynder at oprette en SPF-record, er det nødvendigt at forstå, om din opsætning af e-mailforsendelse kræver, at du gør det i første omgang.

Så først skal du forstå Return Path. SPF drejer sig om det domæne, der bruges i Return-Path, i stedet for FROM-domænet. Derfor skal du i begyndelsen finde ud af den Return-Path, der anvendes til din mailforsendelse.

Visse e-mailforsendelsestjenester (ESP’er) som Google kan også bruge dit domænenavn i deres Return-path. Dette kræver, at du selv opretter en SPF-record for dit domæne.

Andre ESP’er, såsom Postmark, kan dog bruge deres domæne i Return-path, hvor du ikke selv behøver at oprette en SPF-patent; det skal din ESP i stedet gøre.

Så nu hvor du ved, hvorfor du skal oprette en SPF-record, skal du forstå trin for trin-processen for, hvordan du gør det.

Trin 1: Identificer IP-adresser, der sender e-mails

Organisationer kan have flere steder, hvorfra de sender en e-mail. Så i det første skridt til at oprette en SPF-record skal du identificere, hvilke IP-adresser du bruger fra dit domæne til at sende e-mails. List alle dine IP-adresser og de tilsvarende mailservere i et tekstdokument eller regneark.

Find desuden ud af, hvilke alle veje der bruges til at sende e-mails på dit mærkes vegne. Det kan være en webserver, en e-mailserver på kontoret som Microsoft Exchange, din ESP’s mailserver, en mailserver, der tilhører din kundes postkasseudbyder, eller en tredjeparts mailserver.

Men hvis du er usikker på dine IP-adresser, kan du kontakte din ESP og få den komplette liste med alle IP-adresser, der er relateret til din konto. En anden mulighed kunne være at drøfte dette med din systemadministrator. De kan give dig en liste over alle de IP-adresser, der anvendes af din virksomhed.

Trin 2: Liste over de afsendende domæner

En organisation kan eje mange domæner. Ud af dette kan de dedikere nogle af deres domæner til at sende e-mails og andre til andre formål.

I trin nummer 2 skal du oprette en SPF-record for hvert domæne, du ejer, uanset om domænerne bruges til e-mails eller til andre formål.

Dette skyldes, at cyberkriminelle kan forsøge at forfalske de andre domæner, som du måske ikke bruger til at sende dine e-mails, da de ikke vil være beskyttet med SPF, mens andre, der bruges til at sende e-mails, er det.

Trin 3: Opsætning af en SPF-record

SPF sammenligner IP-adressen på afsenderens mailserver med en liste med autoriserede afsender-IP-adresser, som afsenderen har offentliggjort i sin DNS-record for at validere en afsenders identitet og holde dine e-mails sikre.

For at oprette en SPF-record skal du skrive et v=spf1 -tag efterfulgt af de IP-adresser, der er godkendt til at sende e-mails. Eksempel: v=spf1 ip4:192.0.0.1 -all

Desuden, hvis du bruger en tredjepartsløsning til at sende e-mails på dit domænes vegne:

• Tilføj include i SPF-recorden for at angive, at tredjeparten er en lovlig afsender. Du kan f.eks. skrive: include:google.com
• Når du har tilføjet alle de autoriserede IP-adresser, der er tilknyttet dit domæne, skal du afslutte SPF-rekordet med et tag – enten -all eller ~all.Her betyder -all -taget en HARD SPF FAIL, mens ~all -taget betyder en SOFT SPF FAIL. For førende postkasseudbydere vil både -all og ~all dog resultere i en SPF-fejl. Men generelt anvendes -all ofte, da det er mere sikkert.
• Opret dine SPF-poster på en sådan måde, at de ikke overstiger 255 tegn, og undgå at tilføje mere end 10 include statements, også kendt som “opslag”

Nu kan din SPF se nogenlunde sådan ud:

v=spf1 ip4:192.0.0.1 include:google.com -all

Dette er for dine domæner, der er autoriseret til at sende e-mails på dine vegne. Men for dine andre domæner skal du udelukke modifikatorer (undtagen -all) i SPF-posten.

Sådan kan din SPF-post se ud for domæner, som du ikke bruger til at sende e-mails: v=spf1 –all

Sådan kan du oprette din SPF-record. Derefter skal du blot offentliggøre den.

Trin 4: Offentliggør SPF-rekordet

Når du har defineret SPF-posten, er det næste skridt at offentliggøre den i din DNS. Der er to metoder til at gøre dette:

1. Samarbejd med din interne DNS-administrator, og instruer dem i at offentliggøre SPF-recorden til din DNS. Din DNS-udbyder vil give dig et dashboard, som du kan få adgang til og nemt udføre udgivelsesopgaven.
2. Du kan bede DNS-tjenesteudbyderen direkte om at offentliggøre din SPF-record i DNS’en.

Dette vil gøre det muligt for postkassemodtagere som Gmail, Hotmail, Mailbird osv. at anmode om SPF-recorden.

Desuden, hvis du ønsker at opdatere DNS-records:

1. Log ind på den domænekonto, du har købt hos din udbyder af domænehosting
2. Vælg det domæne, hvis poster du ønsker at opdatere
3. Gå til den side, hvor dine DNS-poster er gemt, hvilket kan være en DNS-manager
4. Opret en ny TXT-record og definér dit domænes navn som hostfeltet
5. Udfyld feltet “TXT Value” med SPF-recorden og angiv en Time To Live (TTL)
6. Klik på “Add Record” eller “Save” for at offentliggøre den nye SPF-record på din DNS.

Trin 5: Test SPF-posten

Når du har oprettet din SPF-record og offentliggjort den, kan du bruge en SPF-record-checker til at teste SPF-recorden. Der findes mange muligheder på markedet for SPF-record checkeres, såsom Dmarcian, Agari, Mimecast osv.

Ved at udføre en test kan du kontrollere gyldigheden af din SPF-record og se listen med alle de autoriserede servere, der kan sende e-mails på vegne af dit domæne. Hvis du ikke kan se en legitim IP-adresse på listen, kan du medtage den afsendende IP-adresse til venstre og opdatere din record.

Sådan tilføjer du en SPF-record til dit domæne

Du skal have adgang til dit domænes DNS-kontrolpanel for at tilføje en SPF-record. Hvis du bruger en webhostingudbyder, f.eks. Kinsta, er det enklere at tilføje en SPF-record til din DNS. Du kan henvise til dokumentation og følge trinene for at gøre det.

Generelt offentliggør udbydere af e-mailtjenester SPF-poster for at gøre det muligt at sende e-mails fra dine domæner. Men hvis du ikke har en idé om det, eller hvis din internetudbyder administrerer dine DNS-records, kan du sende dette videre til din it-afdeling.

Begrænsninger ved SPF-records

Selv om tilføjelse af SPF-poster giver dig fordele med hensyn til e-mail-sikkerhed, leveringsmuligheder og meget mere, er der visse begrænsninger ved dem. Lad os tale om disse begrænsninger.

DNS SPF-records

Tidligere SPF-versioner blev brugt til at kontrollere indstillingerne i afsenderdomænets DNS TXT-records for at lette hurtigere implementering og testning. DNS TXT-records var designet til at være fritekst uden nogen semantik knyttet til dem.

IANA tildelte imidlertid SPF en ressourceoptegnelse af typen 99 i 2005. Dette resulterede i en reduceret anvendelse af SPF, da brugerne var overvældet af de to mekanismer, som var forvirrende for dem. I 2014 blev den indstillet.

Problemer med headers

SPF blev oprindeligt udviklet for at forhindre angribere i at forfalske en e-mails envelope-from-adresse. Men mange gør det nu kun i mailheaderen i “From”-feltet, som er synligt for modtagerne i stedet for at blive behandlet af deres MTA. Det øger risikoen for spoofing.

Selv om du kan bruge SPF med DMARC til at kontrollere mailheaderen i From-feltet, har du måske brug for en avanceret, stærkere løsning for at være beskyttet mod spoofing af displaynavne i stedet for SPF.

Desuden er det en udfordring at opdatere SPF-poster, hvis du tilføjer e-mail-strømme eller skifter internetudbyder. SPF-poster kan også bryde videresendelsen af en almindelig meddelelse, og det garanterer ikke e-mailautentificering.

Bedste praksis for SPF-records

Før vi finder ud af de bedste fremgangsmåder til oprettelse og vedligeholdelse af SPF-records, skal vi først tale om nogle generelle fremgangsmåder.

• Din sende-IP-adresse skal indeholde en PTR-record. Den fungerer lidt som en omvendt telefonbog, der gør det muligt at slå en IP-adresse op sammen med et hostnavn. Offentlige internetadgangspunkter og IP-adresser til internetforbindelser i boliger har dog ofte ikke PTR-records. Den bruges, når der er behov for at verificere indgående forbindelser.
• Brug systemer til autentificering af e-mail. Du kan bruge enten et eller alle tre e-mail-godkendelsessystemer: SPF, DMARC og DKIM. Legitime afsendere, der bruger email-autentifikation, kan let genkendes sammenlignet med dem, der ikke bruger det og fortsat er udsat for en sikkerhedsrisiko i forbindelse med spamming af e-mails. Selv om brugen af disse systemer ikke nødvendigvis vil garantere, at dine e-mails lander i de tilsigtede indbakker, vil det give øget beskyttelse. Det er bedre end ikke at have nogen e-mailsikkerhedsmekanismer til at overvåge og bevare afsenderens omdømme.
• Brug eller medtag aldrig nogensinde en post med +all i den. Den eneste måde, hvorpå man kan bruge all produktivt, er i mekanismerne ~all eller -all.

Efter disse generelle fremgangsmåder skal vi tale om nogle af de bedste fremgangsmåder for SPF-records.

Brug begrænsede SPF-records

SPF indeholder masser af kraftfulde og komplekse mekanismer, men det er ikke nødvendigt at bruge dem alle i dine SPF-records. Hold dine SPF-poster enkle, og definér kun det nødvendige antal SPF-records, ikke flere end det.

Dette gælder også for include: -mekanismen. Brug den i et begrænset antal, og undgå indlejrede includes, hvis du kan. Det vil forhindre dig i at overskride grænsen på 10 DNS-søgninger. Du kan også tilføje brede IP-adresser på én gang i stedet for at gøre det hele enkeltvis. Det forenkler processen og sparer tid.

Angiv intervaller i CIDR-notation

Tilføj intervallerne i CIDR-notation, da en enkelt fejl kan ændre værdien dramatisk. Så hvis det lykkes en angriber at kompromittere nogle af dine systemer, og et af dem har en IP-adresse, der hører til dette interval, kan det være fatalt. De kan misbruge den korrekt autentificerede IP-adresse til at sende spam-e-mails. Det kan skade dit omdømme, føre til tab af data og resultere i, at dit domæne bliver markeret som spam af mailudbydere.

Da denne risiko er enormt udbredt, er postudbydere blevet årvågne og blokerer domæner, der ser mistænkelige ud for dem, for at forhindre sådanne hændelser. De begrænser de tilladte CIDR-størrelsesintervaller, som skal betragtes som gyldige i SPF-records.

Undgå at bruge erklæringen +all

Undgå at bruge +all -erklæringen i dine SPF-records. Det kan se alt for tillidsfuldt ud, og det er svært at opdage denne type sikkerhedsproblemer, fordi disse SPF-records er syntaktisk gyldige. Selv værktøjer og testløsninger til kontrol af posterne kan muligvis ikke identificere overdrevent tilladte records.

Angivelsen +all gør det muligt for SPF-rekordet at give hele internettet lov til at sende e-mails på dit domænes vegne, herunder ondsindede e-mails. Faktisk har domæner, der er involveret i spamdistribution, ofte SPF-records, der afsluttes med +all. Som følge heraf kan de sende spam-e-mails med malware-infektioner fra enhver IP-adresse.

Pas på duplikerede records

Generelt har domæner kun én SPF-record, hvilket betyder, at de kun kan gemme én TXT-record, der begynder med udsagnet v=spf1. Og hvis du forsøger at tilføje flere poster i et domæne, kan det føre til permanente fejl.

Denne SPF-begrænsning overtrædes ofte. Mange forsøger at tilføje flere poster, fordi de måske har implementeret forskellige tjenester i deres domæne, hvor hver tjenesteudbyder måske kræver, at de opretter og tilføjer en SPF-record til deres domæne.

Dobbelte poster skader din e-mailleveringsmuligheder, indbyder til sikkerhedsrisici og kan ødelægge dit omdømme. Store postkassetjenesteudbydere som Google og Microsoft har teknikker til at begrænse sådanne skader og automatisk rette dobbelte poster. Men mindre e-mailsystemer har måske ikke.

Når du identificerer dobbelte SPF-records, skal du straks tage fat på problemet, som er ret nemt at løse. Organisationer med flere SPF-poster kan slå dem sammen til en enkelt erklæring. Ved at kombinere to SPF-records sikres det, at v=spf1 forbliver i SPF-recordens begyndelse og kun optræder én gang, mens all bevares i slutningen.

Begrænsning af tegn

SPF-poster kan have op til 255 tegn for en enkelt streng, ifølge RFC. Dette er en begrænsning for alle TXT-records i en DNS.

Som forklaret tidligere kan SPF-records, der ikke overholder denne retningslinje, medføre permanente eller midlertidige fejl i modtagernes mailsystemer. Selv om din DNS-manager måske forhindrer dig i at gå ud over denne grænse, kan det medføre problemer ved lagring af længere records.

Selv om du kun kan holde posterne på 255 tegn i en enkelt streng, er der mulighed for at oprette flere strenge i en DNS-record. Så når en modtagermailserver begynder at analysere SPF-rekorden og finder flere strenge i en post, kombinerer den dem i en bestemt rækkefølge uden mellemrum.

Når dette er gjort, vil postserveren verificere indholdet. Husk igen, at der stadig er en begrænsning på det samlede antal tegn i din post, selv om du kan tilføje flere strenge. Det kan være en udfordring at forstå denne begrænsning, men den sikrer, at DNS-pakker ikke overstiger 512 bytes, hvilket er en anbefalet UDP-pakkelængde.

Hvis din SPF-record imidlertid overstiger denne grænse, skal du oprette underordre og opdele en enkelt record i flere records for at undgå SPF-verifikationsproblemer. Når du opdeler dine SPF-poster, skal du inkludere hver underpost i hoveddelen. Vær forsigtig, da det kan skabe et overvældende antal DNS-anmodninger, hvilket er et sikkerhedsproblem, der skal afhjælpes.

Begræns DNS-opslag

Ud over at holde 255 tegn i en streng skal du også begrænse antallet af DNS-opslag. RFC-specifikationerne anviser, at der ikke må udføres mere end 10 DNS-søgninger i posten. Det er med til at forhindre problemer som uendelige DNS-sløjfer og DDoS-angreb (Distributed Denial of Service).

Men hvad sker der egentlig, når du foretager over 10 opslag i din record?

Det resulterer i en permanent fejl under SPF-godkendelse. SPF-mekanismer – include:, a, PTR, mx, exists og redirect – vil føre til en DNS-forespørgsel.

Mekanismerne – all, ip4 og ip6 – tæller dog ikke med i en DNS-forespørgsel.

Desuden skal du være opmærksom på indlejrede include-angivelser, f.eks. underordrer, der bruges til at opløse en større record. Dette kan øge antallet af DNS-forespørgsler, der genereres af din SPF-post. Så når du bruger en tjeneste fra en tredjepart, skal du sikre dig, at de ikke bruger for mange DNS-forespørgsler i SPF-records.

Undgå duplikerede undernet og IP-adresser

Alle SPF-records opløser til et undernet eller en IP-adresse.

Duplikater af undernet og IP-adresser kan nemt genereres, når der oprettes en liste over IP-adresser og systemer, der har tilladelse til at sende e-mails. Det kan typisk ske, når du tilføjer include: -angivelsen i din SPF-post samt i domænets MX-records for postkassetjenesteudbyderen. Disse IP’er kan være de samme og tilhøre de inkluderede undernet.

Den bedste praksis at følge her kunne være at bruge ip4- eller ipv6-notationen, hvis serverens IP-adresse sjældent ændres. På den måde kan modtagerne undgå DNS-søgninger. Desuden kan du angive et IP-adresseområde, hvis du har en lang liste med udgående e-mail-servere, da DNS-søgninger for hver SPF-record er begrænset til ti.

Bortset fra disse kan du overveje et par andre ting:

• Brug et begrænset antal include: -mekanismer, og undgå indlejrede indlejringer, hvis du kan.
• Brug mekanismerne ~all eller -all i stedet for mekanismen +all.
• Undgå at bruge exists SPF-mekanismen, for hvis du ikke bruger den korrekt, kan sikkerhedsrisici sive ud gennem de fejl, der begås under processen.
• Prøv ikke at bruge “ptr” og mekanismen, da den er blevet forældet i det seneste SPF RFC-udkast til SPF.
• Undgå at tildele typen af DNS-post. Dette accepteres ikke længere i TXT-poster.
• Når du angiver adresseblokke via CIDR-notationen i SPF-posterne, skal du bruge blokke mellem /30 og /16. De højere tal efter en skråstreg betyder mindre adresseblokke, hvilket er bedre. Brug heller ikke blokke mellem /1 og /15, da nogle modtagere måske ignorerer eller ikke tager hensyn til dem.
• Sørg for at opløse alle mekanismer, der anvender et domæne i SPF-posten. Ofte fjerner systemadministratorer ikke ældre systemer som f.eks. en Exchange-server placeret on-premise, som Office365 cloud-tjenester har erstattet. Selv om det er påkrævet at tilføje Office365 til de opdaterede SPF-poster, er det stadig muligt, at det ikke er blevet opdateret, hvis man fjerner legacy-systemet. I dette tilfælde er domænet i SPF-recorden stadig til stede, men i virkeligheden eksisterer det ikke længere, hvilket fører til en midlertidig SPF-fejl.
• Brug e-mailgodkendelsessystemer som DKIM og DMARC sammen med SPF for at gøre det mere effektivt til at beskytte dit domæne. Så hvis du bruger DKIM og DMARC, er det nødvendigt også at kende de bedste fremgangsmåder for dem.

Brug af DKIM med SPF

DomainKeys Identified Mail (DKIM) indeholder en krypteringsnøgle og en digital signatur, der bekræfter, at en e-mailmeddelelse ikke er forfalsket eller ændret. Da DKIM anvender kryptografiske digitale signaturer, skal du følge nogle bedste praksis for at sikre dit domæne.

• Du skal regelmæssigt ændre dine kryptografiske nøgler for at forhindre angribere i at udnytte dem. Mange mailafsendere bruger gamle nøgler, der er oprettet for flere år siden, som angribere lettere kan udnytte; for disse skal du oprette en frisk DKIM-nøgle. Du kan også rotere nøglerne mange gange om året, især hvis du sender tusindvis eller millioner af e-mails på en måned for at sikre følsomme e-mails.
• Sørg for at holde længden af dine nøgler på mindst 1 024 bit, da signaturer, der er oprettet med nøgler, der er mindre end det, ofte ignoreres. Derfor skifter flere og flere afsendere til nøgler på 2 048 bit eller endnu længere.
• Hvis du er en ESP, skal du ikke kun bruge én DKIM-nøgle til alle dine kunder. Tildel dem en ny unik DKIM-nøgle til deres e-mails.
• Hvis du opdager, at der er afviste e-mails, skal du signere dem med DKIM.

Brug af DMARC med SPF

DMARC (Domain-based Message Authentication and Conformance) forener SPF- og DKIM-godkendelsesmekanismerne i en fælles ramme og giver domæneejere mulighed for at angive, hvordan de ønsker, at en e-mail fra det pågældende domæne skal håndteres, hvis den ikke består en godkendelsestest.

Brugen af DMARC har mange fordele. Det giver dig en rapporteringsfunktion og giver dig mulighed for at signalere til udbydere af postkassetjenester, at de skal blokere meddelelser, der ikke har bestået godkendelsen, og som er sendt på dit domænes vegne. Dette hjælper med at identificere og blokere svigagtige meddelelser, der sendes fra dit domæne, hvilket er med til at beskytte dine kunder og forbedre dit domænes omdømme.

Så hvis du ikke bruger DMARC endnu, skal du begynde at bruge det med det samme. Og hvis du gør det, skal du sørge for, at dine meddelelser indeholder “identifier alignment” Denne tilpasning er afgørende for, at en e-mail kan bestå DMARC’s verifikation. Men hvis du ikke medtager den, mens du bruger DMARC, vil det sende dine e-mails direkte til den mistænkelige liste.

Sådan tjekker du SPF-records

Du kan bruge nogle værktøjer til at kontrollere SPF-records. Disse værktøjer er kendt som SPF record checking tools eller SPF record checkers.

SPF Record Checker

En SPF-record checker hjælper med at sikre gyldigheden af en SPF-record ved at kontrollere forskellige parametre:

1. Eksistensen af posten: Dette bruges til at bekræfte, om en given SPF-record faktisk findes i en DNS eller ej.
2. Flere poster: En enkelt SPF-rekord er tilladt i en DNS. En SPF-record-checker kontrollerer derfor, om der kun findes én record eller flere.
3. Maksimale opslag: Det maksimale antal SPF-opslag, der skal foretages, er begrænset til 10. Derfor finder SPF record checker ud af det samlede antal opslag, og om det overstiger 10 eller ej.
4. PTR-mekanisme: Værktøjet verificerer brugen af en PTR-mekanisme, da det ikke anbefales at bruge denne mekanisme.

Eksempler på SPF-record-checkere er bl.a. Dmarcian, Agari og Mimecast.

Opsummering

Da cybersikkerhedsrisici udvikler sig og påvirker både enkeltpersoner og virksomheder, skal du sørge for at implementere så mange sikkerhedslag som muligt for at forblive beskyttet. Du kan bruge mange sikkerhedsteknikker, værktøjer, løsninger og tjenester til at beskytte dine data, netværk, applikationer og systemer.

Tilføjelse af en SPF-post til dit domæne er en af de teknikker, der kan hjælpe med at beskytte dine virksomhedsaktiver og dit omdømme ved at forhindre spammere i at sende e-mails på vegne af dit domæne.

Hvis du bruger SPF alene, kan det ikke give dig fuldstændig beskyttelse; brug derfor DKIM og DMARC sammen med dine SPF-records. Denne strategi er mere effektiv til at opdage sikkerhedsrisici som e-mail-spoofing, at blive sortlistet af servere og blive markeret som spam.

Så hvis du bruger disse teknikker, skal du sørge for at følge den bedste praksis, der er anført ovenfor for SPF-records, DKIM og DMARC, og du skal bruge en SPF-record kontrolprogram til at teste gyldigheden af din record.