Livet efter P=avslås

Livet efter PReject 01

Domänägare gör ofta misstaget att anta att deras autentiseringsresa för e-post slutar vid verkställandet. De vet inte att livet efter p=reject är en viktig fas som avgör den övergripande styrkan i deras domäns e-postsäkerhet. För fortsatt skydd mot spoofing- och phishing-attacker är det absolut nödvändigt att formulera en e-postsäkerhetsstrategi som bara börjar efter att du har uppnått enforcement.

Vad är P=Reject? 

DMARC-policy Det finns tre olika sätt att tillämpa den, nämligen:

  1. p=noll (ingen åtgärd vidtas)
  2. p=quarantine (karantän för e-postmeddelanden som inte klarar DMARC) 
  3. p=reject (avvisar e-postmeddelanden om det finns en DMARC misslyckas)

Reject är den maximala policyn för verkställighet av DMARC och hjälper domänägare att blockera falska eller phishing-e-postmeddelanden innan de når kundernas inkorgar. De som vill utnyttja DMARC för att skydda sina domäner mot e-postbaserade attackvektorer kan tycka att p=reject är ett lämpligt policyläge. 

Hur når man P=Reject Mode? 

Oftast försöker domänägare att skynda sig igenom processen för att införa protokollet och förväntar sig att det ska verkställas så snart som möjligt. Detta rekommenderas dock inte. Låt oss förklara varför: 

Risker i samband med DMARC vid avvisning

  • Om man övergår till verkställighet i mycket snabb takt kan det leda till problem med leverans av e-postmeddelanden. 
  • Det kan leda till att legitima e-postmeddelanden går förlorade. 
  • Det kan leda till DMARC-fel för e-postmeddelanden som skickas utanför din egen domän. 

Vad är den rekommenderade metoden?

Även om avvisningspolicyn kommer med sina egna varningar och friskrivningar, är dess effektivitet när det gäller att förhindra en mängd olika bedrägerier via e-post obestridlig. Så låt oss nu utforska hur du kan gå över till att avvisa på ett säkert sätt: 

  • Börja med p=none

Istället för att börja med en påtvingad policy uppmuntras man starkt att börja med något som ger mer flexibilitet och frihet, och det är precis vad p=none gör. Även om den här policyn inte gör särskilt mycket i fråga om skydd kan den fungera som ett utmärkt övervakningsverktyg för att hjälpa dig på din implementeringsresa. 

Genom att övervaka dina e-postkanaler kan du förhindra oönskade leveransfel på grund av felkonfigurerade protokoll. Det kan göra det möjligt för dig att visualisera och upptäcka fel och att felsöka dem snabbare. 

DMARC-rapportering kan hjälpa dig att identifiera effektiviteten i din policy för autentisering av e-post.

E-postautentisering är ingen patentlösning, men den kan vara ett effektivt verktyg i din säkerhetsarsenal. Med DMARC-rapportering kan du se om dina ansträngningar fungerar och var du kan behöva justera din strategi.

Det finns två typer av rapporter: 

  • Aggregate (RUA) är utformad för att hjälpa dig att spåra dina källor för e-postutskick, avsändarnas IP-adresser, organisationsdomäner och geografiska platser. 
  • Forensic (RUF) är utformad för att fungera som incidentvarningsrapporter när en forensisk händelse, t.ex. spoofing, inträffar.
  • Konfigurera både SPF och DKIM tillsammans med DMARC.

För många kockar förstör inte buljongen när det gäller DMARC-implementering. Säkerhetsexperter rekommenderar snarare att man kombinerar DMARC med både SPF och DKIM för att öka skyddet och för att minska risken för falska positiva resultat. Det kan också förhindra oönskade DMARC-fel. 

DMARC behöver antingen SPF eller DKIM för att klara autentisering.

Detta spelar en central roll för att hjälpa dig att på ett säkert sätt implementera en policy för avvisningar, vilket säkerställer att även om SPF misslyckas och DKIM godkänns eller tvärtom, kommer MARC att godkännas för det avsedda meddelandet.

  • Ange alla dina sändningskällor

Att missa sändningskällor i din SPF-post kan vara särskilt skadligt när du försöker undvika oönskade DMARC-fel. Det är viktigt att göra en lista över alla dina e-postkällor (vilket inkluderar tredjepartsleverantörer av e-post och tjänsteleverantörer som Gmail, Microsoft O365, Yahoo Mail, Zoho, etc.). 

Detta är särskilt viktigt om du endast använder SPF i kombination med DMARC. Varje gång du lägger till eller tar bort en sändningskälla måste SPF-posten återspegla samma ändringar. 

Att sammanfatta ditt liv efter p=reject

Att övervaka dina autentiseringsprotokoll för e-post är en viktig del av livet efter p=reject. Det säkerställer inte bara att dina säkerhetsåtgärder är effektiva utan ger dig också en djupare inblick i deras funktionalitet för att avgöra vad som fungerar bäst för dig. A DMARC-analysator hjälper dig att få en smidigare övergång från p=none till reject, undvika problem med leveransbarhet, övervaka dina e-postkanaler, uppdatera protokollpolicyer och felsöka problem på en enda plattform, enkelt.

Livet efter p=förkasta

Senaste inlägg av Ahona Rudra (se alla)
/av
Hot mot säkerheten för flyttbara medierHot mot säkerheten för flyttbara medier 01vad är en e-posthuvudparser 01 01Vad är en e-posthuvudparser?