Forståelse af begrænsningerne ved SPF i forbindelse med e-mail-godkendelse
Sender Policy Framework eller SPF er ikke tilstrækkeligt, når det drejer sig om at sikre virksomhedens e-mails mod phishing og spamming angreb. SPF-grænsen for det maksimale antal DNS-søgninger og manglende tilpasning af From-adressen og domænet forårsager implementeringsfejl, hvilket resulterer i problemer med levering af e-mail. Denne blog omhandler disse problemer, og hvordan DMARC hjælper med at overvinde disse SPF-begrænsninger.
Hvad er begrænsningerne for SPF-optegnelser?
Der er 2 store SPF-grænser, som gør det lidt vanskeligt at implementere og vedligeholde.
1. Grænsen for SPF 10-opslag
Når en bruger forespørger DNS-serveren, anvendes dens valideringsressourcer som båndbredde, tid, CPU og hukommelse. For at undgå belastning af validatoren er der en SPF-grænse på 10 yderligere opslag. Selve DNS-forespørgslen efter SPF-politikoptegnelsen tæller dog ikke med i denne grænse.
I henhold til RFC7208 afsnit 4.6.4bør modtagerens mailserver ikke behandle yderligere, når grænsen på 10 opslag er nået. I et sådant tilfælde afviser e-mailen SPF-validering med en Permerror-fejl. SPF Permerror er en af de meddelelser, der ofte forekommer i SPF-implementeringsprocessen. Den forårsager, at e-mailen ikke leveres, og den opstår, hvis der findes flere SPF-poster på et domæne, hvis der opstår en syntaksfejl, eller hvis SPF-postgrænserne er overskredet.
Du kan bruge den gratis SPF-record-checker værktøj til at fjerne denne fejl og sikre sikre e-mailkonversationer.
I henhold til RFC skal en DNS-forespørgsel på et værtsnavn, der er fundet i en MX-post bør ikke generere mere end 10 A-poster eller AAAA-poster. Hvis en DNS PTR-forespørgsel genererer mere end 10 resultater, vises og anvendes kun de første 10 resultater.
2. Den menneskeligt læsbare Fra-adresse
Den anden SPF-begrænsning er, at SPF-poster gælder for specifikke Return-Path-domæner og ikke for From-adressen. Modtagerne er generelt ikke særlig opmærksomme på Return-Path-adressen og fokuserer kun på From-adressen, når de åbner en e-mail. Hackere udnytter dette smuthul til at forsøge phishing-angreb ved at forfalske From-adressen.
Indflydelse af SPF-recordstørrelse på levering af e-mail
Når en modtager overskrider grænsen for SPF-poster, mislykkes SPF-kontrollen, og der opstår en Permerror. Du kan observere denne fejl, når du bruger DMARC-overvågning. Modtageren kan vælge, hvordan han/hun vil håndtere e-mails med Permerror-fejl. De kan vælge at afvise posten, hvilket betyder, at e-mailen bliver sendt tilbage. Nogle modtagere konfigurerer den til at vise et "neutralt" SPF-resultat (som om der ikke er anvendt SPF). De kan også vælge "fail" eller "softfail", hvilket betyder, at e-mails, der ikke opfylder SPF-autentifikationskontrollen, ikke afvises, men havner i spam-mappen.
Disse resultater bestemmes også ved at tage hensyn til resultaterne af DMARC, DKIM og spamvurdering. Overskridelse af SPF-grænsen påvirker e-mailens leveringsegnethed ved at reducere sandsynligheden for, at e-mailen lander i den primære indbakke hos de tilsigtede modtagere.
Validator vurderer SPF-politikken fra venstre mod højre, og når der findes et match på afsender-IP-adressen, stopper processen. Afhængigt af afsenderen kan en validator nu ikke altid nå grænsen for opslag, selv om SPF-politikken kræver mere end 10 opslag for at blive evalueret fuldt ud. Det skaber problemer med at identificere SPF-record-grænse-relaterede problemer med levering af e-mail.
Hvordan reducerer man antallet af nødvendige opslag?
Det er svært for nogle domæneejere at holde sig inden for SPF-grænsen på 10 opslag, da e-mailudvekslingsvanerne har ændret sig betydeligt i forhold til 2006 (dengang RFC4408 blev implementeret). Nu bruger virksomheder flere cloud-baserede programmer og tjenester med et enkelt domæne. Så følgende er nogle måder at overvinde denne almindelige SPF-begrænsning på.
-
Fjern ubrugte tjenester
Vurder din SF-registrering og se, om der er ubrugte eller uopkrævede tjenester. Kontroller, om der er 'omfatter' eller andre mekanismer, der viser domæner for tjenester, der ikke længere er i brug.
-
Fjern standard-SPF-værdierne
Standard-SPF-politikken er normalt indstillet til 'v=spf1 a mx'. Da de fleste A- og AAAA-poster bruges til webservere, som ikke må sende e-mails, er 'a' og 'mx' mekanisme ikke er påkrævet.
-
Undgå at bruge den ptr mekanisme
The ptr mekanismen frarådes kraftigt på grund af den svage sikkerhed og upålidelighed. Mekanismen forårsager SPF-grænseproblemet ved at kræve flere opslag. Derfor bør den så vidt muligt undgås.
-
Undgå at bruge den mx Mekanisme
The mx mekanismen bruges til at modtage e-mails og ikke nødvendigvis til at sende dem. Derfor kan du undgå at bruge den for at holde dig inden for den grænse for SPF-rekord, der er fastsat for opslag. Hvis du er bruger af en cloud-baseret e-mailtjeneste, skal du bruge 'include' mekanisme i stedet.
-
Brug IPv6 eller IPv4
IPv4 og IPv6 har ikke brug for yderligere opslag, hvilket betyder, at de hjælper dig med ikke at overskride SPF-grænsen på højst 10 opslag. Du skal dog holde dig opdateret og vedligeholde de to mekanismer regelmæssigt, da de er mere udsat for fejl, når de ikke er blevet opdateret.
-
Du må ikke flade SPF-plader
Nogle ressourcer hævder, at jo mere fladtrykt (eller kortere) SPF-politikken er, jo bedre er domænets omdømme. De foreslår denne metode for at holde sig inden for de SPF-rekordgrænser, der er fastsat for opslag. Det frarådes dog at flade opsætninger, da det gør din post mere udsat for fejl og kræver regelmæssige opdateringer.
DMARC's rolle i forbindelse med at overvinde SPF-begrænsninger
DMARC tager fat på SPF-begrænsningen af den menneskeligt læsbare Fra-adresse ved at kræve et match eller en tilpasning mellem det menneskeligt læsbare Fra-felt og den server, der er autentificeret af SPF.
Så hvis en e-mail klarer SPF-kontrollen, men domænet ikke er det samme som Fra-adressen, tilsidesætter DMARC denne godkendelse. Det betyder, at e-mailen ikke består godkendelsestesten.
Hvordan hjælper SPF record flattening med at overvinde grænsen på 10 DNS-søgninger
Udjævning af SPF-rekord er en teknik, der bruges til at optimere SPF-poster (Sender Policy Framework) for at overvinde grænsen på 10 DNS-søgninger for SPF. Grænsen på 10 DNS-opslag er en begrænsning, som mange DNS-resolvere pålægger, og som begrænser antallet af DNS-forespørgsler, der kan udføres, når en SPF-rekord for et domæne skal verificeres.
Når en e-mail modtages, forespørger modtagerens mailserver afsenderens domænes DNS efter SPF-posten for at kontrollere, om afsenderen har tilladelse til at sende e-mails fra det pågældende domæne. Men hvis SPF-posten indeholder mange indlejrede indbefattere, kan den hurtigt overskride grænsen på 10 DNS-søgninger, hvilket fører til fejl i SPF-verifikationen og falsk-positive spam-detektioner.
For at afhjælpe denne begrænsning anvendes SPF record flattening. SPF-record flattening er en teknik, der erstatter alle indlejrede include-angivelser i en SPF-record med deres tilsvarende IP-adresser eller CIDR-intervaller. Dette reducerer antallet af DNS-forespørgsler, der er nødvendige for at verificere SPF-rekordet, da hvert enkelt inkluderet domæne ikke længere skal spørges individuelt.
Ved at udjævne SPF-posten reduceres antallet af DNS-forespørgsler, der kræves for at verificere SPF-posten, betydeligt, hvilket gør det muligt for e-mails at bestå SPF-verifikationen, selv om den oprindelige post havde mere end 10 DNS-opslag. Denne teknik reducerer også risikoen for fejl i SPF-rekordvalideringen på grund af timeouts i forbindelse med DNS-forespørgsler eller midlertidige problemer med DNS-serveren.
Udfordringer ved implementering af SPF i store virksomheder
SPF har tvunget en begrænsning på højst 10 opslag for at forhindre DoS- og DDoS-angreb. Desværre kan disse opslag hurtigt blive meget store, især i store virksomheder. Tidligere drev virksomhederne deres egne mailservere, men nu bruger de tredjepartsafsendere. Dette skaber et problem, da hver server kan tage op til 3 eller 4 servere, og man når meget hurtigt grænsen.
- Metoder til at beskytte dig selv mod identitetstyveri - 29. september 2023
- DNS's rolle i e-mail-sikkerhed - 29. september 2023
- Den nye tids phishing-trusler og hvordan man planlægger forud - 29. september 2023
