Generellt
Säkert levererad e-post är ett av de viktigaste kommunikationsverktygen för organisationer och företag. På grund av det stora antalet spam- och phishing-attacker är det dock oerhört viktigt att kunna identifiera avsändaren. Ett sätt att göra detta är att använda de vanliga autentiseringsprotokollen för e-post SPF, DKIM och DMARC.
Olika e-postleverantörer har alla sin egen uppsättning regler som avgör vilka e-postmeddelanden som placeras i mottagarens inkorg och vilka som tillhör skräppost, så reglerna tillämpas i mottagarens ände. Därför rekommenderar vi starkt att alla våra kunder ställer in dessa autentiseringsmetoder för att säkerställa att deras e-postmeddelanden levereras och inte märks som skräppost eller blockeras av mottagarens e-posttjänst. Mer detaljerade anvisningar om hur du gör detta, samt anvisningar om hur du distribuerar SPF och DKIM, finns i Ange e-postadresser och autentiseringsmetoder.
För DMARC i allmänhet, se slutet av den här artikeln. Mer information om DNS finns i artikeln Vad DNS betyder.
SPF
Sender Policy Framework (SPF) verifierar att avsändarens IP-adress matchar listan över domänens auktoriserade IP-adresser. Listan över auktoriserade sändande värdar för en domän publiceras i DNS-posterna (Domain Name System) för den domänen. Om IP-adressen matchar en auktoriserad sändande värdadress anses e-postmeddelandet vara legitimt och det är mer sannolikt att det levereras till mottagarens inkorg. Om IP-adressen inte matchar kommer e-postmeddelandet antingen att blockeras eller sättas i karantän (skickas till skräppostmappen).
Du kan se SPF som en gästlista på en fest – om du finns med på listan släpper säkerhetsvakten in dig (e-postmeddelandet levereras). Om du inte finns med på listan blir du avvisad (blockerad) eller så får du vänta på dörren tills festens värd kommer för att se om du får komma in (karantän).
DKIM
DomainKeys Identified Mail (DKIM) är en krypterad privat nyckel som är kopplad till domänen. När e-postmeddelandet skickas bifogas alltså nyckeln till e-postmeddelandet och den mottagande servern jämför sedan nyckeln med den offentliga DNS-posten för avsändarens domän. Om nyckeln matchar DNS-posten bekräftas att e-postmeddelandet verkligen har skickats av den auktoriserade domänen och att det inte har manipulerats under processen.
DKIM och SPF fungerar tillsammans, och DKIM ensamt kan inte användas för att göra den fullständiga verifieringsprocessen. Om du t.ex. ska gå på den fest som nämns i SPF-metaforen måste ditt namn finnas med på listan (SPF) så att säkerhetsvakten kan släppa in dig. Men för att vara säker på att det verkligen är du och att någon inte har stulit din identitet på vägen från ditt hem till festen, måste du också ge säkerhetsvakten en hemlig nyckel (DKIM) som du fick när du blev inbjuden till festen, annars får du inte komma in. Men du kan inte bara ge vakten en nyckel (DKIM) för att bli insläppt, du måste också uppge ett namn som finns på listan (SPF).
DMARC
DMARC (Domain-based Message Authentication, Reporting, and Conformance) används tillsammans med SPF och/eller DKIM. DMARC fastställer reglerna för hur e-post ska hanteras om den misslyckas med både SPF- och DKIM-kontrollerna. Alternativen för DMARC är att inte göra någonting (none), skicka e-postmeddelandet till skräppostmappen (quarantine) eller blockera e-postmeddelandet (reject).
Så hur kontrollerar DMARC att e-postmeddelandet som din domän skickar är äkta? Låt oss tänka oss att du måste checka in på ett hotell (mottagarens inkorg) med hjälp av två ID-handlingar, så du ger receptionisten (mottagande server) ditt ID-kort (SPF) och ditt pass (DKIM). Du kommer in om båda dina ID-handlingar är giltiga och stämmer överens med vem du säger att du är och vad receptionisten kan se i sina register (DNS). I fallet med e-postmeddelandet kommer det alltså att levereras.
Om båda ID-koderna inte klarar kontrollen kommer säkerhetsfunktionen (DMARC) att vidta lämpliga åtgärder enligt DMARC-reglerna i DNS. Du har en chans att komma in (DMARC none) men din inresa kan också nekas (DMARC reject). Eller så kan de ta dig till ett separat rum för utfrågning (DMARC quarantine).
Eftersom säkerheten på hotellet är rigorös räcker det inte med en giltig ID-handling. Så om ditt pass är giltigt men ditt ID-kort inte är det kommer du inte att kunna komma in och DMARC-reglerna kommer att tillämpas. Om båda dina ID-handlingar är giltiga men inte ger samma information, t.ex. om den ena säger att du är Mr Smith och den andra att du är Mr Blacksmith, kommer DMARC-reglerna att tillämpas.
Från och med februari 2024 har DMARC lagts till som ett krav för e-postleverantörer som Google och Yahoo. Det är därför vi rekommenderar våra kunder att konfigurera en DMARC för att säkerställa leveransen av e-postmeddelanden som de skickar. Detta är dock något som måste göras på hanteringssidan av din domänvärd, vilket innebär att CRM-service inte kan ställa in detta åt dig. Det måste göras av din IT-avdelning eller företaget som är värd för din domän, beroende på hur din webbplats är konfigurerad eftersom DNS-filen för din domän måste ändras för att ställa in DMARC.
Informationen nedan är bara ett exempel; du måste konfigurera DMARC så att det matchar din domäninformation och den funktionalitet du vill ha. DMARC är mycket domänspecifikt, så all information i exemplet är endast i demonstrationssyfte, och delar som yourcompany.com måste ersättas med din företagsinformation för att DMARC ska fungera.
Liksom DKIM och DMARC finns det dock ett visst format som DMARC måste följa. Följande är ett exempel på vilka delar DMARC-post har, ersätt bara parenteser och deras innehåll med informationen om din organisation:
_dmarc.(din domän)
v=DMARC1; p=none; rua=mailto:(önskad e-postadress);
I exemplet är _dmarc i början av DNS-värdnamnet, följt av domänen, som är den del där domänen för din webbplats där policyn kommer att läggas till. Denna del är alltid nödvändig eftersom det är namnet på TXT Record.
En annan konstant i DMARC Record är v=DMARC1; – den här delen indikerar att DNS har en DMARC-policy, och den här taggen krävs alltid. En annan obligatorisk del är p=, som i det här exemplet är p=none. Detta talar om för DMARC vad som ska göras om e-post misslyckas med SPF- och DKIM-kontrollerna. I den här delen betyder p=none att e-postmeddelandet fortfarande kommer att gå igenom, p=quarantine markerar e-postmeddelandet som skräppost och p=reject blockerar meddelandet.
Delen rua=mailto:(önskad e-postadress); är valfri, men vi rekommenderar den eftersom den underlättar felsökning om e-postmeddelandena av någon anledning inte når sin destination eller hamnar i skräppostmappen. Här anger rua= att du vill ta emot rapporter, och det följs av mailto: och e-postadressen där du vill ha rapporterna. Detta kan dock resultera i en mycket stor mängd rapportmeddelanden, och därför rekommenderar vi att du skapar en e-postadress som är dedikerad till DMARC-poster eller använder den e-postadress som används för att hantera stora mängder andra automatiserade e-postmeddelanden.
Under alla omständigheter är det aldrig rekommenderat att använda din personliga e-postadress eller någon annan e-postadress som används för kommunikation här, eftersom stora mängder rapportmeddelanden kan leda till att din inkorg fylls och hindrar dig från att skicka och ta emot e-post.
Andra valfria taggar kan användas i DMARC om du vill, men vi täcker inte dem här eftersom vi bara vill visa dig ett grundläggande exempel och inte överkomplicera den här delen.