Förstå begränsningarna med SPF för autentisering av e-post
Ramverk för sändarpolicy eller SPF räcker inte till när det gäller att skydda företags e-post från phishing och spamming attacker. SPF:s begränsning av det maximala antalet DNS-uppslag och ojämnheter i From-adressen och domänen orsakar implementeringsfel som leder till problem med leverans av e-postmeddelanden. I den här bloggen diskuteras dessa problem och hur DMARC hjälper till att övervinna dessa SPF-begränsningar.
Vad är begränsningarna för SPF-poster?
Det finns två stora begränsningar för SPF som gör det lite svårt att implementera och underhålla.
1. SPF 10-Lookup Limit
När en användare frågar DNS-servern används dess valideringsresurser som bandbredd, tid, CPU och minne. För att undvika belastning på validatorn finns det en SPF-gräns på 10 ytterligare sökningar. DNS-förfrågan för själva SPF-politiken räknas dock inte in i denna gräns.
Enligt RFC7208 avsnitt 4.6.4ska mottagarens e-postserver inte behandla ytterligare uppgifter när gränsen på 10 sökningar har uppnåtts. I ett sådant fall avvisar e-postmeddelandet SPF-validering med ett Permerror-fel. SPF Permerror är ett av de meddelanden som ofta förekommer i SPF-implementeringsprocessen. Det leder till att e-postmeddelanden inte levereras och uppstår om flera SPF-poster finns på en domän, om ett syntaxfel dyker upp eller om gränserna för SPF-poster har överskridits.
Du kan använda den kostnadsfria SPF-postkontrollant för att eliminera det här felet och garantera säkra e-postkonversationer.
Enligt RFC ska dessutom en DNS-förfrågan om ett värdnamn som finns i en MX-post bör inte generera mer än 10 A-poster eller AAAA-poster. Om en DNS PTR-förfrågan genererar mer än 10 resultat, visas och används endast de 10 första resultaten.
2. Den människoläsbara adressen från
Den andra SPF-begränsningen är att SPF-poster gäller specifika Return-Path-domäner och inte From-adressen. Mottagarna bryr sig i allmänhet inte så mycket om Return-Path-adressen utan fokuserar bara på From-adressen när de öppnar ett e-postmeddelande. Hackare utnyttjar detta kryphål för att försöka utföra nätfiskeattacker genom att förfalska From-adressen.
Effekten av SPF-postens storlek på e-postleveransen
När en mottagare överskrider gränsen för SPF-poster misslyckas SPF-kontrollerna och en Permerror uppstår. Du kan observera det här felet när du använder DMARC-övervakning. Mottagaren kan välja hur hanteringen av e-postmeddelanden med Permerror-fel ska gå till. De kan välja att avvisa posten, vilket innebär att e-postmeddelandet kommer att studsa tillbaka. Vissa mottagare konfigurerar den så att den visar ett "neutralt" SPF-resultat (som om ingen SPF används). De kan också välja "fail" eller "softfail", vilket innebär att e-postmeddelanden som misslyckas med SPF-autentiseringskontrollen inte avvisas utan hamnar i skräppostmappen.
Dessa resultat bestäms också genom att beakta resultaten av DMARC, DKIM och skräppostklassificering. Överskridande av SPF-gränsen påverkar leveransbarheten genom att minska sannolikheten för att e-postmeddelanden hamnar i de avsedda mottagarnas primära inkorgar.
Validator bedömer SPF-policyn från vänster till höger och när en matchning av avsändarens IP-adress hittas stannar processen. Beroende på avsändaren kan det hända att en validator inte alltid når upp till gränsen för antalet sökningar, även om SPF-policyn kräver mer än 10 sökningar för att utvärderas fullständigt. Det skapar svårigheter när det gäller att identifiera SPF-postgränsrelaterade problem med e-postleveranserna.
Hur kan man minska antalet nödvändiga sökningar?
Det är svårt för vissa domänägare att hålla sig inom SPF-gränsen på 10 sökningar eftersom vanorna för e-postutbyte har förändrats avsevärt sedan 2006 (då RFC4408 infördes). Nu använder företagen flera molnbaserade program och tjänster med en enda domän. Nedan följer några sätt att övervinna denna vanliga SPF-begränsning.
-
Ta bort oanvända tjänster
Se över ditt SF-register och titta om det finns några oanvända eller obehövliga tjänster. Kontrollera om det finnsinkludera' eller andra mekanismer som visar domäner för tjänster som inte längre används.
-
Ta bort standardvärdena för SPF
SPF-principen som standard är vanligtvis inställd på 'v=spf1 a mx'. Eftersom de flesta A- och AAAA-poster används för webbservrar som kanske inte skickar e-post, varför 'a' och 'mx' mekanismen inte behövs.
-
Undvik att använda ptr Mekanismen
The ptr mekanismen är starkt avrådd på grund av den svaga säkerheten och otillförlitligheten. Mekanismen orsakar SPF-begränsningsproblemet genom att den kräver fler sökningar. Därför bör den undvikas så mycket som möjligt.
-
Undvik att använda mx Mekanism
The mx mekanismen används för att ta emot e-post och inte nödvändigtvis för att skicka den. Det är därför du kan undvika att använda den för att hålla dig inom den SPF-postgräns som fastställts för sökningar. Om du använder en molnbaserad e-posttjänst ska du använda 'include'. mekanismen i stället.
-
Använd IPv6 eller IPv4
IPv4 och IPv6 behöver inga ytterligare sökningar, vilket innebär att de hjälper dig att inte överskrida SPF-gränsen på högst 10 sökningar. Du måste dock hålla dig uppdaterad och underhålla de två mekanismerna regelbundet eftersom de är mer benägna att göra fel när de inte är omarbetade.
-
Platta inte ut SPF-skivor
Vissa källor hävdar att ju mer utjämnad (eller kortare) SPF-politiken är, desto bättre är domänens rykte. De föreslår denna metod för att hålla sig inom de SPF-postgränser som fastställts för sökningar. Det avråds dock från att göra det plattare eftersom det gör din post mer utsatt för fel och kräver regelbundna uppdateringar.
DMARC:s roll för att övervinna SPF-begränsningar
DMARC åtgärdar SPF-begränsningen av den människoläsbara Från-adressen genom att kräva en matchning eller anpassning mellan det människoläsbara Från-fältet och den server som autentiserats av SPF.
Om ett e-postmeddelande klarar SPF-kontrollerna men domänen inte är densamma som från-adressen, åsidosätter DMARC denna autentisering. Detta innebär att e-postmeddelandet inte klarar autentiseringstestet.
Hur hjälper SPF-record flattening till att övervinna gränsen på 10 DNS-sökningar?
Plattning av SPF-posterna är en teknik som används för att optimera SPF-poster (Sender Policy Framework) för att komma över gränsen på 10 DNS-sökningar för SPF. Begränsningen på 10 DNS-uppslag är en begränsning som införs av många DNS-upplösare och som begränsar antalet DNS-frågor som kan utföras när en SPF-post för en domän verifieras.
När ett e-postmeddelande tas emot frågar mottagarens e-postserver efter SPF-posten i avsändarens DNS-domän för att kontrollera om avsändaren har tillstånd att skicka e-post från den domänen. Om SPF-posten innehåller många inbäddade inkluderingar kan den dock snabbt överskrida gränsen på 10 DNS-sökningar, vilket leder till att SPF-verifieringen misslyckas och att falskt positiv skräppost upptäcks.
För att komma till rätta med denna begränsning används SPF-record flattening (utjämning av SPF-poster). SPF record flattening är en teknik som ersätter alla inbäddade include-angivelser i en SPF-post med motsvarande IP-adresser eller CIDR-områden. Detta minskar antalet DNS-frågor som krävs för att verifiera SPF-posten, eftersom varje inkluderad domän inte längre behöver frågas ut individuellt.
Genom att plana ut SPF-posten minskas antalet DNS-frågor som krävs för att verifiera SPF-posten avsevärt, vilket gör att e-postmeddelanden kan godkännas för SPF-verifiering även om den ursprungliga posten hade mer än 10 DNS-uppslag. Denna teknik minskar också risken för att valideringen av SPF-posterna misslyckas på grund av tidsuttag för DNS-frågor eller tillfälliga problem med DNS-servern.
Utmaningar med att införa SPF i stora företag
SPF har tvingat fram en begränsning på högst 10 sökningar för att förhindra att DoS- och DDoS-attacker. Tyvärr kan dessa sökningar bli mycket snabba, särskilt i stora företag. Tidigare drev företagen sina egna e-postservrar, men nu använder de sig av tredjepartsavsändare. Detta skapar problem eftersom varje server kan ta upp till 3 eller 4 servrar och man når gränsen mycket snabbt.
- De 5 bästa tjänsterna för hantering av cybersäkerhet 2023 - 29 maj 2023
- Hur planerar man en smidig övergång från DMARC None till DMARC Reject? - 26 maj 2023
- Hur kontrollerar jag din domäns hälsa? - 26 maj 2023
