Inzicht in de beperkingen van SPF bij e-mailverificatie
Sender Policy Framework of SPF volstaat niet als het gaat om het beveiligen van zakelijke e-mails tegen phishing en spamming aanvallen. SPF beperkt het maximum aantal DNS-lookups en het niet op elkaar afstemmen van het Van-adres en het domein, wat leidt tot fouten bij de implementatie en problemen met de aflevering van e-mail. Deze blog bespreekt deze problemen en hoe DMARC helpt deze SPF-beperkingen te overwinnen.
Wat zijn de beperkingen van het SPF Record?
Er zijn 2 belangrijke SPF-beperkingen die het een beetje lastig maken om te implementeren en te onderhouden.
1. De SPF 10-Lookup Limiet
Wanneer een gebruiker de DNS-server opvraagt, worden de middelen van de validator zoals bandbreedte, tijd, CPU en geheugen gebruikt. Om de validator niet te belasten is er een SPF-limiet van 10 extra lookups. De DNS-zoekopdracht voor de SPF-beleidsrecord zelf telt echter niet mee voor deze limiet.
Volgens RFC7208 paragraaf 4.6.4moet de mailserver van de ontvanger niet verder verwerken zodra de 10-lookup-limiet is bereikt. In dat geval weigert de e-mail de SPF-validatie met een Permerror-fout. SPF Permerror is een van de berichten die vaak voorkomen in het SPF-implementatieproces. Het veroorzaakt niet-levering van e-mail en treedt op als er meerdere SPF-records bestaan op één domein, een syntaxisfout optreedt, of door overschrijding van SPF-recordlimieten.
U kunt de gratis SPF record checker om deze fout te elimineren en beveiligde e-mailconversaties te garanderen.
Bovendien, volgens de RFC, een DNS query van een hostnaam gevonden in een MX record niet meer dan 10 A-records of AAAA-records genereren. Als een DNS PTR-query meer dan 10 resultaten oplevert, worden alleen de eerste 10 resultaten weergegeven en gebruikt.
2. Het menselijk leesbare Van-adres
De tweede SPF-beperking is dat SPF-records gelden voor specifieke Return-Path domeinen en niet voor het Van-adres. Ontvangers letten doorgaans niet op het Return-Path-adres en kijken alleen naar het Van-adres wanneer zij een e-mail openen. Hackers maken gebruik van deze lacune om phishing-aanvallen uit te voeren door het Van-adres te vervalsen.
Het effect van de grootte van SPF-records op e-mailaflevering
Wanneer een ontvanger de SPF-recordlimiet overschrijdt, mislukken de SPF-controles en treedt een Permerror op. U kunt deze fout waarnemen wanneer u DMARC-controle gebruikt. De ontvanger kan kiezen hoe om te gaan met e-mails met een Permerror-fout. Hij kan ervoor kiezen de invoer te verwerpen, wat betekent dat de e-mail wordt teruggestuurd. Sommige ontvangers configureren het om een 'neutraal' SPF-resultaat te tonen (alsof er geen SPF wordt gebruikt). Zij kunnen ook kiezen voor 'fail' of 'softfail', wat betekent dat e-mails die de SPF-verificatiecontroles niet doorstaan, niet worden geweigerd maar in de spammap terechtkomen.
Deze resultaten worden ook bepaald aan de hand van de resultaten van DMARC, DKIM en spamrating. Het overschrijden van de SPF-limiet heeft gevolgen voor de bezorgbaarheid van e-mails doordat de kans kleiner wordt dat e-mails in de primaire inbox van de beoogde ontvangers terechtkomen.
De validator beoordeelt het SPF-beleid van links naar rechts en wanneer een match op het IP-adres van de afzender is gevonden, stopt het proces. Afhankelijk van de afzender bereikt een validator nu niet altijd de lookup-limiet, zelfs als het SPF-beleid meer dan 10 lookups vereist om volledig te evalueren. Dit maakt het moeilijk om problemen met de bezorgbaarheid van e-mail in verband met de SPF-recordlimiet op te sporen.
Hoe het aantal vereiste opzoekingen verminderen?
Het is voor sommige domeineigenaren moeilijk om binnen de SPF-limiet van 10 lookups te blijven, omdat de gewoonten bij het uitwisselen van e-mail aanzienlijk zijn veranderd sinds 2006 (toen RFC4408 werd geïmplementeerd). Nu gebruiken bedrijven meerdere cloudgebaseerde programma's en diensten met één domein. Hieronder volgen enkele manieren om deze veel voorkomende SPF-beperking te omzeilen.
-
Ongebruikte diensten verwijderen
Beoordeel uw SF record en kijk of er ongebruikte of niet vereiste diensten zijn. Controleer het voor de 'include' of andere mechanismen die domeinen tonen van diensten die niet langer in gebruik zijn.
-
De standaard SPF-waarden verwijderen
Het standaard SPF-beleid is gewoonlijk ingesteld op 'v=spf1 a mx. Aangezien de meeste A en AAAA records gebruikt worden voor webservers die geen e-mails mogen versturen, vandaar de 'a' en 'mx' mechanisme niet nodig.
-
Vermijd het gebruik van de ptr mechanisme
De ptr mechanisme wordt sterk afgeraden wegens zwakke beveiliging en onbetrouwbaarheid. Het mechanisme veroorzaakt het SPF-limietprobleem doordat er meer lookups nodig zijn. Daarom moet het zoveel mogelijk worden vermeden.
-
Vermijd het gebruik van de mx Mechanisme
De mx mechanisme wordt gebruikt voor het ontvangen van e-mails, en niet noodzakelijk voor het verzenden ervan. Daarom kunt u vermijden het te gebruiken om binnen de SPF record limiet te blijven die is ingesteld op lookups. Als u een gebruiker bent van een cloud-gebaseerde e-maildienst, gebruik dan de 'include' mechanisme.
-
Gebruik IPv6 of IPv4
De IPv4 en IPv6 hebben geen extra lookups nodig, wat betekent dat ze u helpen de SPF-limiet van niet meer dan 10 lookups niet te overschrijden. U moet de twee mechanismen echter regelmatig bijwerken en onderhouden, omdat ze vatbaarder zijn voor fouten wanneer ze niet opnieuw worden geconditioneerd.
-
Vlak SPF Records niet uit
Sommige bronnen beweren dat hoe platter (of korter) het SPF-beleid, hoe beter de domeinreputatie. Zij suggereren deze methode om binnen de SPF record limieten te blijven die zijn ingesteld op lookups. Afvlakken wordt echter afgeraden, omdat het uw record vatbaarder maakt voor fouten en regelmatige updates vereist.
De rol van DMARC bij het overwinnen van SPF-beperkingen
DMARC pakt de SPF-beperking van het menselijk leesbare Van-adres aan door een overeenkomst of afstemming te eisen tussen het menselijk leesbare Van-veld en de door SPF geauthenticeerde server.
Dus, als een e-mail de SPF-controles doorstaat maar het domein niet hetzelfde is als het Van-adres, overschrijft DMARC die authenticatie. Dit betekent dat de e-mail de authenticatietest niet doorstaat.
Hoe helpt SPF record flattening de 10 DNS lookup limiet te omzeilen
SPF record afvlakking is een techniek die wordt gebruikt om SPF-records (Sender Policy Framework) te optimaliseren om de 10 DNS-opzoeklimiet voor SPF te omzeilen. De 10 DNS lookup limiet is een beperking opgelegd door vele DNS resolvers, die het aantal DNS queries beperkt die kunnen worden uitgevoerd bij het verifiëren van een SPF record voor een domein.
Wanneer een e-mail wordt ontvangen, bevraagt de mailserver van de ontvanger het DNS-domein van de afzender op zijn SPF-record om te controleren of de afzender gemachtigd is om e-mails van dat domein te verzenden. Als het SPF-record echter veel geneste insluitingen bevat, kan het snel de 10 DNS-zoeklimiet overschrijden, wat leidt tot mislukte SPF-verificaties en vals-positieve spammeldetecties.
Om deze beperking te ondervangen, wordt SPF record flattening gebruikt. SPF record flattening is een techniek die alle geneste include statements in een SPF record vervangt door hun corresponderende IP adressen of CIDR reeksen. Dit vermindert het aantal DNS-query's dat nodig is om het SPF-record te verifiëren, aangezien niet langer elk opgenomen domein afzonderlijk wordt bevraagd.
Door het SPF-record af te vlakken, wordt het aantal DNS-query's dat nodig is om het SPF-record te verifiëren aanzienlijk verminderd, waardoor e-mailberichten door de SPF-verificatie komen, zelfs als het oorspronkelijke record meer dan 10 DNS-zoekopdrachten had. Deze techniek vermindert ook het risico van mislukte SPF-recordvalidatie als gevolg van DNS-query time-outs of tijdelijke DNS-serverproblemen.
Uitdagingen van de implementatie van SPF in grote ondernemingen
SPF heeft de beperking van niet meer dan 10 lookups afgedwongen om DoS- en DDoS-aanvallen te voorkomen. Helaas kunnen deze lookups zeer snel oplopen, vooral in grote ondernemingen. Vroeger gebruikten bedrijven hun eigen mailservers, nu echter verzenders van derden. Dit creëert een probleem, aangezien elke server tot 3 of 4 servers kan nemen en u de limiet zeer snel bereikt.
