I denne artikel vil vi diskutere SPF-records, og hvorfor det er vigtigt at implementere denne teknik for at sikre e-mailsikkerheden<\/a>.<\/p>\n Check vores\u00a0videoguide om SPF Record<\/a><\/strong><\/p>\n F\u00f8r vi kommer til, hvad en SPF-record er, skal vi f\u00f8rst forst\u00e5 SPF.<\/p>\n Sender Policy Framework (SPF) henviser til en metode til autentificering af e-mails, der er designet til at opdage forfalskede afsenderadresser under e-maillevering.<\/p>\n Angribere forfalsker ofte afsenderadresser<\/a> og f\u00e5r dem til at se \u00e6gte ud, som en almindelig brugers adresse. SPF kan hj\u00e6lpe med at opdage disse meddelelser og s\u00e6tte dem i karant\u00e6ne og dermed afspore dem fra deres angreb.<\/p>\n SPF g\u00f8r det muligt for serveren i den modtagende ende at kontrollere, om en e-mail, der ser ud til at komme fra et givet dom\u00e6ne, faktisk stammer fra en autoriseret IP-adresse p\u00e5 det p\u00e5g\u00e6ldende dom\u00e6ne. Listen med alle autoriserede IP-adresser og hosts for et bestemt dom\u00e6ne findes i dom\u00e6nets DNS-records<\/a>.<\/p>\n\n En SPF-record er en slags TXT-record<\/a>, der offentligg\u00f8res i en DNS-zonefil, og som indeholder en liste over alle de autoriserede mailservere, der kan sende e-mails p\u00e5 vegne af dit dom\u00e6ne. Det er en implementering af SPF, der skal tilf\u00f8jes til din DNS<\/a> for at hj\u00e6lpe med at identificere og forhindre spammere i at sende ondsindede e-mails med falske adresser p\u00e5 dit dom\u00e6nes vegne.<\/p>\n Spammere udf\u00f8rer e-mail-spoofing ved at oprette en e-mail ved hj\u00e6lp af falske afsenderadresser, da de fleste e-mail-servere ikke udf\u00f8rer autentificering. De redigerer derefter en e-mail-afsenderadresse ved at forfalske e-mail-hovedlinjerne<\/a>, s\u00e5 det ser \u00e6gte ud, som om e-mailene er sendt fra dit dom\u00e6ne.<\/p>\n Denne proces kaldes spoofing, og den g\u00f8r det muligt for spammere at snyde brugerne og f\u00e5 fat i deres private data og skade deres omd\u00f8mme.<\/p>\n I dag har n\u00e6sten alle skadelige e-mails falske adresser. Som f\u00f8lge heraf lider de personer, hvis e-mailadresser angriberne har stj\u00e5let, skade p\u00e5 deres omd\u00f8mme, spilder tid p\u00e5 at rette op p\u00e5 afviste meddelelser, f\u00e5r deres IP-adresser sortlistet osv.<\/p>\n Derfor er det n\u00f8dvendigt at oprette SPF-records for at forbedre din e-mail-leveringsmuligheder<\/a> og -sikkerhed.<\/p>\n Generelt defineres en SPF-record ved hj\u00e6lp af en type TXT-record (ikke at forveksle med den gamle SPF-filtyperecord).<\/p>\n En SPF-record starter med et “v”, som angiver den anvendte SPF-version. I \u00f8jeblikket skal denne version v\u00e6re “spf1”, da den anerkendes af de fleste mailudvekslingsservere.<\/p>\n Herefter f\u00f8lger andre udtryk, som definerer reglerne for v\u00e6rter, der sender e-mails fra det givne dom\u00e6ne. Disse termer kan ogs\u00e5 give flere oplysninger til behandling af SPF-record.<\/p>\n Her er, hvordan en SPF-record ser ud, og hvad de enkelte dele af den betyder:<\/p>\n Enhver computer kan sende e-mails, der h\u00e6vder at komme fra enhver adresse, som SMTP<\/a> tillader. Angribere og svindlere udnytter dette ved at bruge forfalskede adresser, som er sv\u00e6re at spore.<\/p>\n En lignende teknik anvendes i phishing-angreb, hvor angriberne narrer brugerne til at afsl\u00f8re deres personlige eller forretningsm\u00e6ssige oplysninger ved at efterligne et \u00e6gte websted eller en \u00e6gte tjeneste, som brugerne ofte benytter.<\/p>\n For at modvirke dette g\u00f8r SPF det muligt for et dom\u00e6nes ejer at definere, hvilke computere der har tilladelse til at sende e-mails fra det p\u00e5g\u00e6ldende dom\u00e6ne ved hj\u00e6lp 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.<\/p>\n Som vi s\u00e5 i eksemplet ovenfor, er en SPF-record i form af en TXT-record, der indeholder en liste over alle IP-adresser p\u00e5 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.<\/p>\n N\u00e5r en autoriseret bruger sender en e-mail med en SPF-record aktiveret, udf\u00f8rer modtagerens mailserver et DNS-opslag for at finde den TXT-record og fastsl\u00e5, om afsenderens IP-adresse<\/a> er autoriseret.<\/p>\n Hvis den ikke finder nogen SPF-record, sender den en “hard fail”- eller “soft fail”-meddelelse til afsenderen.<\/p>\n Hvis modtagerens server afviser det p\u00e5g\u00e6ldende dom\u00e6ne, skal den uautoriserede bruger eller klient modtage en afvisningsmeddelelse (“hard fail”). Men hvis klienten tilf\u00e6ldigvis er en message transfer agent (MTA), vil der i dette tilf\u00e6lde blive genereret en afvisningsmail til den faktiske envelope-from-adresse (“soft fail”).<\/p>\n SPF-poster best\u00e5r af flere forskellige dele, begyndende med versionsnummeret.<\/p>\n Alle SPF-records begynder med et versionsnummer, som skal godkendes af mekanismer, der definerer gyldige afsendere. SPF-versionnummeret, f.eks. spf1, efterf\u00f8lges af en streng, der omfatter mekanismer, kvantificatorer og modifikatorer.<\/p>\n Mekanismer beskriver de v\u00e6rter, der er udpeget som autoriserede udg\u00e5ende afsendere for et givet dom\u00e6ne. En SPF-record kan have nul eller flere mekanismer. Nogle af de almindelige mekanismer i SPF-records er f\u00f8lgende:<\/p>\n Disse definerer alle de IP-adresser, der er godkendt til at sende e-mails fra dom\u00e6net.<\/p>\n Mekanismer har en kvantifikator for at definere, hvordan de kan h\u00e5ndtere et match.<\/p>\n En e-mail-server sammenligner afsenderens IP-adresse med listen over de godkendte IP-adresser i mekanismerne. N\u00e5r den finder et match for IP-adressen i en af SPF-mekanismerne, implementerer den reglen for h\u00e5ndtering af resultatet. Og standardreglen for dette er De fire kvantifikatorer er som f\u00f8lger:<\/p>\n N\u00e5r du ikke ser nogen kvantifikator i en SPF-record, betyder det, at Modifikatorer giver dig mulighed for at udvide rammen. De er v\u00e6rdi- eller navnepar adskilt af De to mest udbredte modifikatorer er:<\/p>\n Hvis dit dom\u00e6ne har en SPF-record, mindsker det risikoen for at modtage ondsindede, forfalskede e-mails, hvilket \u00f8ger din e-mailsikkerhed og beskytter den mod cyberangribere og spammere<\/a>.<\/p>\n En SPF-record \u00f8ger ogs\u00e5 dit dom\u00e6nes trov\u00e6rdighed og mindsker risikoen for at blive slettet af spamfiltre. Dette hj\u00e6lper legitime e-mails med at finde vej til dig hurtigere.<\/p>\n Desuden er tilf\u00f8jelse af SPF-rekorder i dit dom\u00e6ne blevet mere og mere afg\u00f8rende for at verificere, hvilke afsendere der kan sende e-mails p\u00e5 vegne af dit dom\u00e6ne. Det giver mange fordele, som vi vil unders\u00f8ge n\u00e6ste gang.<\/p>\n SPF-poster er med til at \u00f8ge e-mailsikkerheden for b\u00e5de 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.<\/p>\n Tilf\u00f8jelse af SPF-poster er en m\u00e5de at g\u00f8re netop dette p\u00e5. Ved at g\u00f8re det mere udfordrende for e-mailangribere at komme igennem, er der mindre sandsynlighed for, at spam-beskeder lander i din indbakke; dermed \u00f8ges din e-mailsikkerhed.<\/p>\n Hvis et dom\u00e6ne 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\u00e5lgruppe (ogs\u00e5 kendt som leveringsegnethed).<\/p>\n Dette bliver en vejsp\u00e6rring for enkeltpersoner og virksomheder, der bruger s\u00e5danne dom\u00e6ner til at n\u00e5 deres m\u00e5lgruppe af kunder, medarbejdere, leverand\u00f8rer og andre tilknyttede personer.<\/p>\n Hvis dine brugere konstant modtager e-mails fra angribere, der udgiver sig for at v\u00e6re din virksomhed<\/a>, er dit dom\u00e6nes trov\u00e6rdighed i fare. D\u00e5rlige akt\u00f8rer kan ogs\u00e5 skade dine kunder og medarbejdere ved at afsl\u00f8re deres personlige oplysninger, hvilket vil skade dit omd\u00f8mme yderligere<\/a>.<\/p>\n Derfor er det vigtigt at beskytte dit dom\u00e6ne mod s\u00e5danne h\u00e6ndelser ved hj\u00e6lp af SPF-records. Ved at begr\u00e6nse afsendelsen af e-mails til kun autoriserede IP-adresser, der er opf\u00f8rt i posterne, forhindrer du spam-meddelelser og reducerer sandsynligheden for s\u00e5danne angreb.<\/p>\n E-mail-verifikationssystemet DMARC<\/a> sikrer, at kun autoriserede brugere sender e-mails p\u00e5 dit dom\u00e6nes vegne.<\/p>\n Dets politikker instruerer ogs\u00e5 servere om, hvordan de skal h\u00e5ndtere e-mails med mislykkede DKIM- og SPF-kontroller. DMARC anviser, at s\u00e5danne e-mails skal markeres som afvist, spam eller leveret.<\/p>\n Det giver ogs\u00e5 dom\u00e6neadministratorer mulighed for at modtage rapporter, der fremh\u00e6ver e-mailaktiviteter, og foretage justeringer af deres politikker i overensstemmelse hermed.<\/p>\n Du skal oprette en SPF-record for dit dom\u00e6ne<\/a>, hvis du sender kommercielle og transaktionsrelaterede e-mails til dine kunder, medarbejdere eller leverand\u00f8rer. Ved at bruge forskellige e-mail-sikkerhedsl\u00f8sninger bliver din e-mail-leveringsmuligheder og sikkerhed st\u00e6rk.<\/p>\n Hvis du \u00f8nsker, at dine e-mails skal n\u00e5 frem til den tilsigtede destination, kan du derfor sikre dig dette ved at bruge SPF-records og give bedre sikkerhed for dine dom\u00e6ner og e-mails. Det vil filtrere falske e-mails fra phishere og spammere og beskytte dit omd\u00f8mme.<\/p>\n Her er hvordan du kan tilf\u00f8je, oprette og redigere dine SPF-records.<\/p>\n F\u00f8r du begynder at oprette en SPF-record, er det n\u00f8dvendigt at forst\u00e5, om din ops\u00e6tning af e-mailforsendelse kr\u00e6ver, at du g\u00f8r det i f\u00f8rste omgang.<\/p>\n S\u00e5 f\u00f8rst skal du forst\u00e5 Return Path. SPF drejer sig om det dom\u00e6ne, der bruges i Return-Path, i stedet for FROM-dom\u00e6net. Derfor skal du i begyndelsen finde ud af den Return-Path, der anvendes til din mailforsendelse.<\/p>\n Visse e-mailforsendelsestjenester (ESP’er) som Google kan ogs\u00e5 bruge dit dom\u00e6nenavn i deres Return-path. Dette kr\u00e6ver, at du selv opretter en SPF-record for dit dom\u00e6ne.<\/p>\n Andre ESP’er, s\u00e5som Postmark, kan dog bruge deres dom\u00e6ne i Return-path, hvor du ikke selv beh\u00f8ver at oprette en SPF-patent; det skal din ESP i stedet g\u00f8re.<\/p>\n S\u00e5 nu hvor du ved, hvorfor du skal oprette en SPF-record, skal du forst\u00e5 trin for trin-processen for, hvordan du g\u00f8r det.<\/p>\n Organisationer kan have flere steder, hvorfra de sender en e-mail. S\u00e5 i det f\u00f8rste skridt til at oprette en SPF-record skal du identificere, hvilke IP-adresser du bruger fra dit dom\u00e6ne til at sende e-mails. List alle dine IP-adresser og de tilsvarende mailservere i et tekstdokument eller regneark.<\/p>\n Find desuden ud af, hvilke alle veje der bruges til at sende e-mails p\u00e5 dit m\u00e6rkes vegne. Det kan v\u00e6re en webserver, en e-mailserver p\u00e5 kontoret som Microsoft Exchange, din ESP’s mailserver, en mailserver, der tilh\u00f8rer din kundes postkasseudbyder, eller en tredjeparts mailserver<\/a>.<\/p>\n Men hvis du er usikker p\u00e5 dine IP-adresser, kan du kontakte din ESP og f\u00e5 den komplette liste med alle IP-adresser, der er relateret til din konto. En anden mulighed kunne v\u00e6re at dr\u00f8fte dette med din systemadministrator. De kan give dig en liste over alle de IP-adresser, der anvendes af din virksomhed.<\/p>\n En organisation kan eje mange dom\u00e6ner. Ud af dette kan de dedikere nogle af deres dom\u00e6ner til at sende e-mails og andre til andre form\u00e5l.<\/p>\n I trin nummer 2 skal du oprette en SPF-record for hvert dom\u00e6ne, du ejer, uanset om dom\u00e6nerne bruges til e-mails eller til andre form\u00e5l.<\/p>\n Dette skyldes, at cyberkriminelle kan fors\u00f8ge at forfalske de andre dom\u00e6ner, som du m\u00e5ske ikke bruger til at sende dine e-mails, da de ikke vil v\u00e6re beskyttet med SPF, mens andre, der bruges til at sende e-mails, er det.<\/p>\n SPF sammenligner IP-adressen p\u00e5 afsenderens mailserver med en liste med autoriserede afsender-IP-adresser, som afsenderen har offentliggjort i sin DNS<\/a>-record for at validere en afsenders identitet og holde dine e-mails sikre.<\/p>\n For at oprette en SPF-record skal du skrive et Desuden, hvis du bruger en tredjepartsl\u00f8sning til at sende e-mails p\u00e5 dit dom\u00e6nes vegne:<\/p>\n Nu kan din SPF se nogenlunde s\u00e5dan ud:<\/p>\n Dette er for dine dom\u00e6ner, der er autoriseret til at sende e-mails p\u00e5 dine vegne. Men for dine andre dom\u00e6ner skal du udelukke modifikatorer (undtagen S\u00e5dan kan din SPF-post se ud for dom\u00e6ner, som du ikke bruger til at sende e-mails: S\u00e5dan kan du oprette din SPF-record. Derefter skal du blot offentligg\u00f8re den.<\/p>\n N\u00e5r du har defineret SPF-posten, er det n\u00e6ste skridt at offentligg\u00f8re den i din DNS. Der er to metoder til at g\u00f8re dette:<\/p>\n Dette vil g\u00f8re det muligt for postkassemodtagere som Gmail<\/a>, Hotmail, Mailbird osv. at anmode om SPF-recorden.<\/p>\n Desuden, hvis du \u00f8nsker at opdatere DNS-records:<\/p>\n N\u00e5r 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\u00e5 markedet for SPF-record checkeres, s\u00e5som Dmarcian, Agari, Mimecast osv.<\/p>\n Ved at udf\u00f8re en test kan du kontrollere gyldigheden af din SPF-record og se listen med alle de autoriserede servere, der kan sende e-mails p\u00e5 vegne af dit dom\u00e6ne. Hvis du ikke kan se en legitim IP-adresse p\u00e5 listen, kan du medtage den afsendende IP-adresse til venstre og opdatere din record.<\/p>\n Du skal have adgang til dit dom\u00e6nes DNS-kontrolpanel for at tilf\u00f8je en SPF-record. Hvis du bruger en webhostingudbyder, f.eks. Kinsta, er det enklere at tilf\u00f8je en SPF-record til din DNS. Du kan henvise til dokumentation og f\u00f8lge trinene for at g\u00f8re det.<\/p>\n Generelt offentligg\u00f8r udbydere af e-mailtjenester SPF-poster for at g\u00f8re det muligt at sende e-mails fra dine dom\u00e6ner. Men hvis du ikke har en id\u00e9 om det, eller hvis din internetudbyder administrerer dine DNS-records, kan du sende dette videre til din it-afdeling.<\/p>\n Selv om tilf\u00f8jelse af SPF-poster giver dig fordele med hensyn til e-mail-sikkerhed, leveringsmuligheder<\/a> og meget mere, er der visse begr\u00e6nsninger ved dem. Lad os tale om disse begr\u00e6nsninger.<\/p>\n Tidligere SPF-versioner blev brugt til at kontrollere indstillingerne i afsenderdom\u00e6nets DNS TXT-records for at lette hurtigere implementering og testning. DNS TXT-records var designet til at v\u00e6re fritekst uden nogen semantik knyttet til dem.<\/p>\n IANA tildelte imidlertid SPF en ressourceoptegnelse af typen 99 i 2005. Dette resulterede i en reduceret anvendelse af SPF, da brugerne var overv\u00e6ldet af de to mekanismer, som var forvirrende for dem. I 2014 blev den indstillet.<\/p>\n SPF blev oprindeligt udviklet for at forhindre angribere i at forfalske en e-mails envelope-from-adresse. Men mange g\u00f8r det nu kun i mailheaderen i “From”-feltet, som er synligt for modtagerne i stedet for at blive behandlet af deres MTA. Det \u00f8ger risikoen for spoofing.<\/p>\n Selv om du kan bruge SPF med DMARC til at kontrollere mailheaderen i From-feltet, har du m\u00e5ske brug for en avanceret, st\u00e6rkere l\u00f8sning for at v\u00e6re beskyttet mod spoofing af displaynavne i stedet for SPF.<\/p>\n Desuden er det en udfordring at opdatere SPF-poster, hvis du tilf\u00f8jer e-mail-str\u00f8mme eller skifter internetudbyder. SPF-poster kan ogs\u00e5 bryde videresendelsen af en almindelig meddelelse, og det garanterer ikke e-mailautentificering.<\/p>\n F\u00f8r vi finder ud af de bedste fremgangsm\u00e5der til oprettelse og vedligeholdelse af SPF-records, skal vi f\u00f8rst tale om nogle generelle fremgangsm\u00e5der.<\/p>\n Efter disse generelle fremgangsm\u00e5der skal vi tale om nogle af de bedste fremgangsm\u00e5der for SPF-records.<\/p>\n SPF indeholder masser af kraftfulde og komplekse mekanismer, men det er ikke n\u00f8dvendigt at bruge dem alle i dine SPF-records. Hold dine SPF-poster enkle, og defin\u00e9r kun det n\u00f8dvendige antal SPF-records, ikke flere end det.<\/p>\n Dette g\u00e6lder ogs\u00e5 for Tilf\u00f8j intervallerne i CIDR-notation, da en enkelt fejl kan \u00e6ndre v\u00e6rdien dramatisk. S\u00e5 hvis det lykkes en angriber at kompromittere nogle af dine systemer, og et af dem har en IP-adresse, der h\u00f8rer til dette interval, kan det v\u00e6re fatalt. De kan misbruge den korrekt autentificerede IP-adresse til at sende spam-e-mails. Det kan skade dit omd\u00f8mme, f\u00f8re til tab af data og resultere i, at dit dom\u00e6ne bliver markeret som spam af mailudbydere<\/a>.<\/p>\n Da denne risiko er enormt udbredt, er postudbydere blevet \u00e5rv\u00e5gne og blokerer dom\u00e6ner, der ser mist\u00e6nkelige ud for dem, for at forhindre s\u00e5danne h\u00e6ndelser. De begr\u00e6nser de tilladte CIDR-st\u00f8rrelsesintervaller, som skal betragtes som gyldige i SPF-records.<\/p>\n Undg\u00e5 at bruge Angivelsen Generelt har dom\u00e6ner kun \u00e9n SPF-record, hvilket betyder, at de kun kan gemme \u00e9n TXT-record, der begynder med udsagnet Denne SPF-begr\u00e6nsning overtr\u00e6des ofte. Mange fors\u00f8ger at tilf\u00f8je flere poster, fordi de m\u00e5ske har implementeret forskellige tjenester i deres dom\u00e6ne, hvor hver tjenesteudbyder m\u00e5ske kr\u00e6ver, at de opretter og tilf\u00f8jer en SPF-record til deres dom\u00e6ne.<\/p>\n Dobbelte poster skader din e-mailleveringsmuligheder, indbyder til sikkerhedsrisici og kan \u00f8del\u00e6gge dit omd\u00f8mme. Store postkassetjenesteudbydere som Google og Microsoft har teknikker til at begr\u00e6nse s\u00e5danne skader og automatisk rette dobbelte poster. Men mindre e-mailsystemer har m\u00e5ske ikke.<\/p>\n N\u00e5r du identificerer dobbelte SPF-records, skal du straks tage fat p\u00e5 problemet, som er ret nemt at l\u00f8se. Organisationer med flere SPF-poster kan sl\u00e5 dem sammen til en enkelt erkl\u00e6ring. Ved at kombinere to SPF-records sikres det, at SPF-poster kan have op til 255 tegn for en enkelt streng, if\u00f8lge RFC. Dette er en begr\u00e6nsning for alle TXT-records i en DNS.<\/p>\n Som forklaret tidligere kan SPF-records, der ikke overholder denne retningslinje, medf\u00f8re permanente eller midlertidige fejl i modtagernes mailsystemer. Selv om din DNS-manager m\u00e5ske forhindrer dig i at g\u00e5 ud over denne gr\u00e6nse, kan det medf\u00f8re problemer ved lagring af l\u00e6ngere records.<\/p>\n Selv om du kun kan holde posterne p\u00e5 255 tegn i en enkelt streng, er der mulighed for at oprette flere strenge i en DNS-record. S\u00e5 n\u00e5r en modtagermailserver begynder at analysere SPF-rekorden og finder flere strenge i en post, kombinerer den dem i en bestemt r\u00e6kkef\u00f8lge uden mellemrum.<\/p>\n N\u00e5r dette er gjort, vil postserveren verificere indholdet. Husk igen, at der stadig er en begr\u00e6nsning p\u00e5 det samlede antal tegn i din post, selv om du kan tilf\u00f8je flere strenge. Det kan v\u00e6re en udfordring at forst\u00e5 denne begr\u00e6nsning, men den sikrer, at DNS-pakker ikke overstiger 512 bytes, hvilket er en anbefalet UDP-pakkel\u00e6ngde.<\/p>\n Hvis din SPF-record imidlertid overstiger denne gr\u00e6nse, skal du oprette underordre og opdele en enkelt record i flere records for at undg\u00e5 SPF-verifikationsproblemer. N\u00e5r du opdeler dine SPF-poster, skal du inkludere hver underpost i hoveddelen. V\u00e6r forsigtig, da det kan skabe et overv\u00e6ldende antal DNS-anmodninger, hvilket er et sikkerhedsproblem, der skal afhj\u00e6lpes.<\/p>\n Ud over at holde 255 tegn i en streng skal du ogs\u00e5 begr\u00e6nse antallet af DNS-opslag. RFC-specifikationerne anviser, at der ikke m\u00e5 udf\u00f8res mere end 10 DNS-s\u00f8gninger i posten. Det er med til at forhindre problemer som uendelige DNS-sl\u00f8jfer og DDoS-angreb (Distributed Denial of Service)<\/a>.<\/p>\n Men hvad sker der egentlig, n\u00e5r du foretager over 10 opslag i din record?<\/p>\n Det resulterer i en permanent fejl under SPF-godkendelse. SPF-mekanismer – Mekanismerne – Desuden skal du v\u00e6re opm\u00e6rksom p\u00e5 indlejrede include-angivelser, f.eks. underordrer, der bruges til at opl\u00f8se en st\u00f8rre record. Dette kan \u00f8ge antallet af DNS-foresp\u00f8rgsler, der genereres af din SPF-post. S\u00e5 n\u00e5r du bruger en tjeneste fra en tredjepart, skal du sikre dig, at de ikke bruger for mange DNS-foresp\u00f8rgsler i SPF-records.<\/p>\n Alle SPF-records opl\u00f8ser til et undernet eller en IP-adresse.<\/p>\n Duplikater af undernet og IP-adresser kan nemt genereres, n\u00e5r der oprettes en liste over IP-adresser og systemer, der har tilladelse til at sende e-mails. Det kan typisk ske, n\u00e5r du tilf\u00f8jer Den bedste praksis at f\u00f8lge her kunne v\u00e6re at bruge ip4- eller ipv6-notationen, hvis serverens IP-adresse sj\u00e6ldent \u00e6ndres. P\u00e5 den m\u00e5de kan modtagerne undg\u00e5 DNS-s\u00f8gninger. Desuden kan du angive et IP-adresseomr\u00e5de, hvis du har en lang liste med udg\u00e5ende e-mail-servere, da DNS-s\u00f8gninger for hver SPF-record er begr\u00e6nset til ti.<\/p>\n Bortset fra disse kan du overveje et par andre ting:<\/p>\n DomainKeys Identified Mail (DKIM) indeholder en krypteringsn\u00f8gle og en digital signatur, der bekr\u00e6fter, at en e-mailmeddelelse ikke er forfalsket eller \u00e6ndret. Da DKIM anvender kryptografiske digitale signaturer, skal du f\u00f8lge nogle bedste praksis for at sikre dit dom\u00e6ne.<\/p>\n DMARC (Domain-based Message Authentication and Conformance) forener SPF- og DKIM-godkendelsesmekanismerne i en f\u00e6lles ramme og giver dom\u00e6neejere mulighed for at angive, hvordan de \u00f8nsker, at en e-mail fra det p\u00e5g\u00e6ldende dom\u00e6ne skal h\u00e5ndteres, hvis den ikke best\u00e5r en godkendelsestest.<\/p>\n 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\u00e5et godkendelsen, og som er sendt p\u00e5 dit dom\u00e6nes vegne. Dette hj\u00e6lper med at identificere og blokere svigagtige meddelelser, der sendes fra dit dom\u00e6ne, hvilket er med til at beskytte dine kunder og forbedre dit dom\u00e6nes omd\u00f8mme.<\/p>\n S\u00e5 hvis du ikke bruger DMARC endnu, skal du begynde at bruge det med det samme. Og hvis du g\u00f8r det, skal du s\u00f8rge for, at dine meddelelser indeholder “identifier alignment” Denne tilpasning er afg\u00f8rende for, at en e-mail kan best\u00e5 DMARC’s verifikation. Men hvis du ikke medtager den, mens du bruger DMARC, vil det sende dine e-mails direkte til den mist\u00e6nkelige liste.<\/p>\n Du kan bruge nogle v\u00e6rkt\u00f8jer til at kontrollere SPF-records. Disse v\u00e6rkt\u00f8jer er kendt som SPF record checking tools eller SPF record checkers.<\/p>\n En SPF-record checker hj\u00e6lper med at sikre gyldigheden af en SPF-record ved at kontrollere forskellige parametre:<\/p>\n Eksempler p\u00e5 SPF-record-checkere er bl.a. Dmarcian, Agari og Mimecast.<\/p>\n\n Da cybersikkerhedsrisici udvikler sig og p\u00e5virker b\u00e5de enkeltpersoner og virksomheder, skal du s\u00f8rge for at implementere s\u00e5 mange sikkerhedslag som muligt for at forblive beskyttet. Du kan bruge mange sikkerhedsteknikker, v\u00e6rkt\u00f8jer, l\u00f8sninger og tjenester til at beskytte dine data, netv\u00e6rk, applikationer og systemer.<\/p>\n Tilf\u00f8jelse af en SPF-post til dit dom\u00e6ne er en af de teknikker, der kan hj\u00e6lpe med at beskytte dine virksomhedsaktiver og dit omd\u00f8mme ved at forhindre spammere i at sende e-mails p\u00e5 vegne af dit dom\u00e6ne.<\/p>\n Hvis du bruger SPF alene, kan det ikke give dig fuldst\u00e6ndig 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.<\/p>\n S\u00e5 hvis du bruger disse teknikker, skal du s\u00f8rge for at f\u00f8lge den bedste praksis, der er anf\u00f8rt ovenfor for SPF-records, DKIM og DMARC, og du skal bruge en SPF-record kontrolprogram til at teste gyldigheden af din record.<\/p>\n","protected":false},"excerpt":{"rendered":" En sikkerhedsteknologi som Sender Policy Framework (SPF) kan vise sig at v\u00e6re uvurderlig i en verden, der er plaget af onlineangreb og spam-beskeder. Cybersikkerhed er et …<\/p>\n","protected":false},"author":164,"featured_media":47952,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_kinsta_gated_content":false,"_kinsta_gated_content_redirect":"","footnotes":""},"tags":[31,36,515,636,637],"topic":[694,732],"class_list":["post-47951","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","tag-dns","tag-email","tag-email-deliverability","tag-recor","tag-spf","topic-e-mail-marketing-tips","topic-sikkerhedstips"],"yoast_head":"\nHvad betyder SPF?<\/h2>\n
![\"Viser](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/07\/spfrecord-1.png\")
Hvad er en SPF-record?<\/h2>\n
![\"Viser](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/07\/SPF-Record-1.png\")
Syntaks for SPF-rekord<\/h3>\n
Eksempel p\u00e5 en SPF-record<\/h3>\n
v=spf1 a include:_spf.google.com -all<\/pre>\n
\n
v=spf1<\/code> er SPF version 1, en komponent, der identificerer en TXT-record som en SPF-record.<\/li>\na<\/code> autoriserer den host, der er registreret i dom\u00e6nets A-record, til at sende e-mails.<\/li>\ninclude:<\/code> bruges til at godkende e-mails, som afsenderen kan sende p\u00e5 vegne af et dom\u00e6ne (her google.com).<\/li>\n-all<\/code> fort\u00e6ller modtagerens server, at de adresser, der ikke er opf\u00f8rt i denne SPF-record, ikke er autoriseret til at sende e-mails. Den fort\u00e6ller ogs\u00e5 serverne, at de skal afvise s\u00e5danne adresser.<\/li>\n<\/ul>\nHvordan fungerer en SPF-record?<\/h2>\n
![\"Retning](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/07\/SPF-Record-Works-1-1.jpg\")
Komponenter i en SPF-record<\/h2>\n
Versionsnummer<\/h3>\n
Mekanismer<\/h3>\n
\n
a<\/code>:<\/strong> Angiver alle IP-adresser i en DNS A-record (eksempel: v=spf1 a:google.com -all<\/code>). Den bruges til sidst og definerer reglen for h\u00e5ndtering af en afsender-IP, der ikke passer til nogen tidligere mekanismer.<\/li>\nmx<\/code>:<\/strong> Definerer alle A-records i retning af den MX-record, der tilh\u00f8rer hver v\u00e6rt. Eksempel: v=spf1 mx mx:google.com -all<\/code><\/li>\ninclude:<\/code>:<\/strong> Definerer andre autoriserede dom\u00e6ner (eksempel: v=spf1 include:outlook.microsoft.com -all<\/code>). Hvis politikken for det p\u00e5g\u00e6ldende dom\u00e6ne er godkendt, vil denne mekanisme ogs\u00e5 v\u00e6re godkendt. Du har brug for redirect-udvidelsen, hvis du vil opn\u00e5 fuld delegation med et andet dom\u00e6nes politik.<\/li>\nptr<\/code>:<\/strong> Den definerer alle A-records mod PTR-posten for hver host (eksempel: v=spf1 ptr:domain.com -all<\/code>). Du skal dog undg\u00e5 denne mekanisme, hvis det er muligt.<\/li>\nall<\/code>:<\/strong> Matcher alle fjern- og lokale IP-adresser og anvendes i SPF-recordens ende (eksempel: v=spf1 +all<\/code>).<\/li>\nexists<\/code>:<\/strong> Dette angiver dom\u00e6ner, der er afmeldt som en undtagelse i henhold til definitionen SPF. N\u00e5r der k\u00f8res en foresp\u00f8rgsel p\u00e5 et givet dom\u00e6ne, vil det v\u00e6re et match ved opn\u00e5else af et resultat. Det bruges sj\u00e6ldent og giver mere komplicerede matches som f.eks. DNSBL-foresp\u00f8rgsler.<\/li>\nip4<\/code>:<\/strong> Bruges til at definere en IPv4-adresse, f.eks. v=spf1 ip4:192.0.0.0.1 -all.<\/li>\nip6<\/code><\/strong>: Bruges til at definere en IPv6-adresse, f.eks. v=spf1 ip6:2001:db8::8a2e:370:7334 -all<\/li>\n<\/ul>\nKvantiteter<\/h3>\n
pass<\/code> eller +<\/code>.<\/p>\n\n
+<\/code><\/strong> repr\u00e6senterer resultatet PASS. Hvis adressen best\u00e5r testen, skal meddelelsen accepteres (eksempel: v=spf1 +all<\/code>). Du kan udelade det, fordi f.eks. +mx<\/code> og mx<\/code> er det samme.<\/li>\n-<\/code><\/strong> st\u00e5r for HARDFAIL og angiver, at adressen ikke har best\u00e5et testen, og at e-mailen skal afvises (eksempel: v=spf1 -all<\/code>).<\/li>\n~<\/code><\/strong> st\u00e5r for SOFTFAIL og udtales som en tilde. Det betyder, at adressen ikke har best\u00e5et testen; resultatet er dog ikke endeligt. Du kan acceptere og m\u00e6rke en e-mail, der ikke er i overensstemmelse med kravene (eksempel: v=spf1 ~all<\/code>).<\/li>\n?<\/code><\/strong> st\u00e5r for NEUTRAL, hvor adressen hverken har fejlet eller best\u00e5et testen, og det st\u00e5r dig frit for at acceptere eller afvise den (eksempel: v=spf1 ?all<\/code>).<\/li>\n<\/ul>\n+all<\/code> -kvantifikatoren er anvendt.<\/p>\nModifikatorer<\/h3>\n
=<\/code> -tegnet og giver flere oplysninger. SPF-records kan ogs\u00e5 have nul, en eller to modifikatorer, men de kan kun optr\u00e6de \u00e9n gang, mod slutningen af den record.<\/p>\n\n
redirect<\/code>:<\/strong> Bruges til at sende en foresp\u00f8rgsel til andre dom\u00e6ner. Denne modifikator er let at forst\u00e5 sammenlignet med andre mekanismer og modifikatorer og bruges, n\u00e5r du har flere dom\u00e6ner og har brug for at bruge den samme SPF-record overalt.<\/li>\nexp<\/code>:<\/strong> Bruges til at give en forklaring, n\u00e5r en FAIL-kantifikator er inkluderet i en matchet mekanisme. Denne forklaring vil blive placeret i SPF-loggen.<\/li>\n<\/ul>\nHvorfor har du brug for SPF-records?<\/h2>\n
\u00d8get e-mailsikkerhed<\/h3>\n
![\"To](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/07\/Email-Security.jpg\")
Forbedret levering af e-mail<\/h3>\n
Forbedret omd\u00f8mme p\u00e5 dom\u00e6net<\/h3>\n
![\"Viser](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/07\/Domain-Reputation.jpg\")
Overholdelse af DMARC<\/h3>\n
Hvem har brug for en SPF-record?<\/h2>\n
\n
S\u00e5dan opretter, tilf\u00f8jer og redigerer du SPF-records<\/h2>\n
S\u00e5dan opretter du en SPF-records<\/h3>\n
![\"Viser](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/07\/How-to-Create-.jpg\")
Trin 1: Identificer IP-adresser, der sender e-mails<\/h4>\n
Trin 2: Liste over de afsendende dom\u00e6ner<\/h4>\n
Trin 3: Ops\u00e6tning af en SPF-record<\/h4>\n
v=spf1<\/code> -tag efterfulgt af de IP-adresser, der er godkendt til at sende e-mails. Eksempel: v=spf1 ip4:192.0.0.1 -all<\/code><\/p>\n\n
include<\/code> i SPF-recorden for at angive, at tredjeparten er en lovlig afsender. Du kan f.eks. skrive: include:google.com<\/code><\/li>\n-all<\/code> eller ~all<\/code>.Her betyder -all<\/code> -taget en HARD SPF FAIL, mens ~all<\/code> -taget betyder en SOFT SPF FAIL. For f\u00f8rende postkasseudbydere vil b\u00e5de -all<\/code> og ~all<\/code> dog resultere i en SPF-fejl. Men generelt anvendes -all<\/code> ofte, da det er mere sikkert.<\/li>\nv=spf1 ip4:192.0.0.1 include:google.com -all<\/code><\/p>\n-all<\/code>) i SPF-posten.<\/p>\nv=spf1 \u2013all<\/code><\/p>\nTrin 4: Offentligg\u00f8r SPF-rekordet<\/h4>\n
\n
\n
Trin 5: Test SPF-posten<\/h4>\n
S\u00e5dan tilf\u00f8jer du en SPF-record til dit dom\u00e6ne<\/h3>\n
![\"Viser](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/07\/How-to-Add.jpg\")
Begr\u00e6nsninger ved SPF-records<\/h2>\n
DNS SPF-records<\/h3>\n
Problemer med headers<\/h3>\n
Bedste praksis for SPF-records<\/h2>\n
\n
+all<\/code> i den. Den eneste m\u00e5de, hvorp\u00e5 man kan bruge all<\/code> produktivt, er i mekanismerne ~all<\/code> eller -all<\/code>.<\/li>\n<\/ul>\nBrug begr\u00e6nsede SPF-records<\/h3>\n
include:<\/code> -mekanismen. Brug den i et begr\u00e6nset antal, og undg\u00e5 indlejrede includes, hvis du kan. Det vil forhindre dig i at overskride gr\u00e6nsen p\u00e5 10 DNS-s\u00f8gninger. Du kan ogs\u00e5 tilf\u00f8je brede IP-adresser p\u00e5 \u00e9n gang i stedet for at g\u00f8re det hele enkeltvis. Det forenkler processen og sparer tid.<\/p>\nAngiv intervaller i CIDR-notation<\/h3>\n
Undg\u00e5 at bruge erkl\u00e6ringen +all<\/h3>\n
+all<\/code> -erkl\u00e6ringen i dine SPF-records. Det kan se alt for tillidsfuldt ud, og det er sv\u00e6rt at opdage denne type sikkerhedsproblemer, fordi disse SPF-records er syntaktisk gyldige. Selv v\u00e6rkt\u00f8jer og testl\u00f8sninger til kontrol af posterne kan muligvis ikke identificere overdrevent tilladte records.<\/p>\n+all<\/code> g\u00f8r det muligt for SPF-rekordet at give hele internettet lov til at sende e-mails p\u00e5 dit dom\u00e6nes vegne, herunder ondsindede e-mails. Faktisk har dom\u00e6ner, der er involveret i spamdistribution, ofte SPF-records, der afsluttes med +all<\/code>. Som f\u00f8lge heraf kan de sende spam-e-mails med malware-infektioner<\/a> fra enhver IP-adresse.<\/p>\nPas p\u00e5 duplikerede records<\/h3>\n
v=spf1<\/code>. Og hvis du fors\u00f8ger at tilf\u00f8je flere poster i et dom\u00e6ne, kan det f\u00f8re til permanente fejl.<\/p>\n![\"Viser](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/07\/duplicate-data-1-1.jpg\")
v=spf1<\/code> forbliver i SPF-recordens begyndelse og kun optr\u00e6der \u00e9n gang, mens all<\/code> bevares i slutningen.<\/p>\nBegr\u00e6nsning af tegn<\/h3>\n
Begr\u00e6ns DNS-opslag<\/h3>\n
include:<\/code>, a<\/code>, PTR<\/code>, mx<\/code>, exists<\/code> og redirect<\/code> – vil f\u00f8re til en DNS-foresp\u00f8rgsel.<\/p>\nall<\/code>, ip4<\/code> og ip6<\/code> – t\u00e6ller dog ikke med i en DNS-foresp\u00f8rgsel.<\/p>\nUndg\u00e5 duplikerede undernet og IP-adresser<\/h3>\n
![\"Viser](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/07\/subnetduplicate-1.jpg\")
include:<\/code> -angivelsen i din SPF-post samt i dom\u00e6nets MX-records for postkassetjenesteudbyderen. Disse IP’er kan v\u00e6re de samme og tilh\u00f8re de inkluderede undernet.<\/p>\n\n
include:<\/code> -mekanismer, og undg\u00e5 indlejrede indlejringer, hvis du kan.<\/li>\n~all<\/code> eller -all<\/code> i stedet for mekanismen +all<\/code>.<\/li>\nexists<\/code> SPF-mekanismen, for hvis du ikke bruger den korrekt, kan sikkerhedsrisici sive ud gennem de fejl, der beg\u00e5s under processen.<\/li>\nBrug af DKIM med SPF<\/h3>\n
\n
Brug af DMARC med SPF<\/h3>\n
S\u00e5dan tjekker du SPF-records<\/h2>\n
SPF Record Checker<\/h3>\n
![\"Viser](\"https:\/\/kinsta.com\/wp-content\/uploads\/2022\/07\/checkspf.png\")
\n
Opsummering<\/h2>\n