E-postsäkerhet för GDPR: SPF, DKIM och DMARC förklarat

E-postsäkerhet och GDPR-efterlevnad hänger ihop mer än de flesta organisationer inser. En angripare förfalskar din domän, skickar ett nätfiskemeddelande till dina kunder, stjäl deras inloggningsuppgifter och får åtkomst till personuppgifter. Du står nu inför ett dataintrång, och kedjan startade för att din domän saknade tre DNS-poster.

SPF, DKIM och DMARC är e-postautentiseringsprotokoll som förhindrar obehöriga parter från att skicka e-post som din domän. De är gratis att implementera, inbyggda i DNS och alltmer förväntade av tillsynsmyndigheter som grundläggande säkerhetsåtgärder.

Kedjan från spoofing till dataintrång

Utan e-postautentisering kan vem som helst skicka e-post som ser ut att komma från din domän. Den mottagande e-postservern har inget sätt att verifiera avsändarens identitet. Detta möjliggör en förutsägbar attackkedja.

1. Angriparen skickar ett nätfiskemeddelande från din-doman.se till dina kunder eller anställda
2. Mottagarna litar på e-postmeddelandet eftersom avsändaradressen matchar din riktiga domän
3. De klickar på en länk, anger inloggningsuppgifter på en falsk inloggningssida eller öppnar en skadlig bilaga
4. Angriparen får åtkomst till konton som innehåller personuppgifter
5. Du har nu ett dataintrång med GDPR-rapporteringsskyldigheter enligt artiklarna 33 och 34

GDPR artikel 32 kräver "lämpliga tekniska åtgärder" för att skydda personuppgifter. Att låta din domän förfalskas trivialt, när gratis branschstandardmässiga motåtgärder existerar, är svårt att försvara som "lämpligt."

SPF: deklarera vem som får skicka som din domän

Sender Policy Framework (SPF) är en DNS TXT-post som listar vilka e-postservrar som är auktoriserade att skicka e-post på uppdrag av din domän. När en mottagande server får ett e-postmeddelande som påstår sig vara från din domän kontrollerar den din SPF-post för att verifiera att den sändande servern finns med på listan.

• Publiceras som en DNS TXT-post på din domän (t.ex. v=spf1 include:_spf.google.com include:spf.protection.outlook.com -all)
• include: auktoriserar tredjepartse-posttjänster (Google Workspace, Microsoft 365, Mailchimp)
• -all betyder att e-post från servrar som inte finns med på listan ska avvisas — den striktaste och rekommenderade inställningen
• ~all (softfail) markerar obehöriga e-postmeddelanden som misstänkta men levererar dem ändå — svagare skydd
• +all tillåter vilken server som helst att skicka som din domän — använd aldrig detta

En vanlig felkonfiguration är att använda +all eller utelämna -all-kvalificeraren. Detta inaktiverar i praktiken SPF-skyddet samtidigt som det ser ut att vara konfigurerat. Vakteyes e-postsäkerhetsskanning kontrollerar specifikt detta.

DKIM: kryptografiska e-postsignaturer

DomainKeys Identified Mail (DKIM) lägger till en kryptografisk signatur på varje e-postmeddelande din server skickar. Den mottagande servern använder en publik nyckel publicerad i din DNS för att verifiera signaturen, vilket bekräftar att e-postinnehållet inte har ändrats under transport och att det kommer från en auktoriserad avsändare.

• Din e-postserver signerar varje e-postmeddelande med en privat nyckel
• Motsvarande publika nyckel publiceras som en DNS TXT-post (selector._domainkey.dindomän.se)
• Mottagande servrar verifierar signaturen mot den publika nyckeln
• Om e-postmeddelandet ändrades under transport, även med ett enda tecken, misslyckas verifieringen
• DKIM-selektorer bör roteras regelbundet för att begränsa påverkan av nyckelkompromettering

DKIM ger integritetsverifiering som SPF inte kan. SPF bekräftar att e-postmeddelandet kom från en auktoriserad server. DKIM bekräftar att e-postinnehållet är autentiskt och oförändrat. Tillsammans täcker de både avsändaren och meddelandet.

DMARC: tillämpningslagret

Domain-based Message Authentication, Reporting, and Conformance (DMARC) knyter ihop SPF och DKIM och talar om för mottagande servrar vad de ska göra när autentisering misslyckas. Utan DMARC loggas SPF- och DKIM-fel men e-postmeddelanden levereras ofta ändå.

DMARC kräver också alignment: domänen i den synliga From-headern måste matcha domänen som validerats av SPF eller DKIM. Detta stänger kryphålet där en angripare klarar SPF med sin egen server men förfalskar From-headern.

• p=none — enbart övervakning. E-postmeddelanden levereras oavsett autentiseringsresultat. Använd detta för att börja samla in data utan att blockera legitim e-post.
• p=quarantine — misslyckade e-postmeddelanden hamnar i skräppost. Ett bra mellansteg medan du verifierar att alla legitima sändningskällor är konfigurerade.
• p=reject — misslyckade e-postmeddelanden blockeras helt. Det starkaste skyddet, rekommenderat som slutmål.
• rua= — adress för aggregerade rapporter. Du får dagliga rapporter som visar vem som skickar e-post som din domän.
• ruf= — adress för forensiska rapporter. Detaljerade rapporter om enskilda autentiseringsmisslyckanden.

Rekommenderad väg: börja med p=none och rua-taggen för att ta emot rapporter. Analysera rapporterna i två till fyra veckor för att identifiera alla legitima sändningstjänster. Konfigurera SPF och DKIM för varje tjänst. Gå sedan vidare till p=quarantine, och slutligen p=reject.

Bonus: BIMI, din logotyp i inkorgen

Brand Indicators for Message Identification (BIMI) visar din organisations logotyp bredvid autentiserade e-postmeddelanden i e-postklienter som stöder det (Gmail, Apple Mail, Yahoo Mail). Det kräver DMARC med p=quarantine eller p=reject som förutsättning.

BIMI är inte ett säkerhetsprotokoll, utan en förtroendessignal. När kunder ser din verifierade logotyp kan de skilja dina riktiga e-postmeddelanden från potentiella förfalskningar. Det skapar också ett affärsincitament att upprätthålla stark DMARC-tillämpning, eftersom att lätta på policyn innebär att logotypen försvinner.

• Kräver DMARC-policy p=quarantine eller p=reject
• Publiceras som en DNS TXT-post (default._bimi.dindomän.se)
• Pekar på en SVG Tiny PS-logotypfil på din server
• Vissa leverantörer kräver ett Verified Mark Certificate (VMC) från en certifikatutfärdare

Varför e-postsäkerhet är en GDPR-skyldighet

GDPR artikel 32 kräver "lämpliga tekniska och organisatoriska åtgärder" för säkerhet vid behandling. E-postautentisering är branschstandard, gratis att implementera och förhindrar direkt en känd attackvektor som leder till dataintrång. Att utelämna det är svårt att motivera.

NIS2 artikel 21(2)(e) kräver säkerhet vid förvärv, utveckling och underhåll av nätverks- och informationssystem, inklusive sårbarhetshantering. En oskyddad e-postdomän är en känd sårbarhet.

Utöver regulatoriska krav finns en praktisk ansvarskedja. Om din domän förfalskas för att nätfiska dina kunder och ett intrång inträffar, har du rapporteringsskyldigheter enligt GDPR artiklarna 33 (till tillsynsmyndigheten inom 72 timmar) och 34 (till drabbade individer). Det faktum att den initiala förfalskningen var förebyggbar med standardmässiga DNS-poster kommer att vägas in i varje bedömning av dina säkerhetsåtgärder.

Vad Vakteye kontrollerar

Vakteyes e-postsäkerhetsskanning frågar din domäns DNS-poster och utvärderar hela autentiseringskedjan. Skanningen kontrollerar SPF, DKIM, DMARC och BIMI-konfiguration, och flaggar vanliga felkonfigurationer som undergräver skyddet.

• Saknad SPF-post eller alltför tillåtande kvalificerare (+all, ~all istället för -all)
• DMARC saknas helt, eller satt till p=none utan plan att eskalera
• DKIM-poster inte publicerade eller med svaga nyckellängder
• BIMI-beredskapsbedömning baserad på nuvarande DMARC-policy
• Varje fynd kopplat till GDPR artikel 32 och NIS2-krav med specifika åtgärdssteg

Alla fynd inkluderar de exakta DNS-poster du behöver lägga till eller ändra. Du får TXT-postvärdena redo att klistra in hos din DNS-leverantör.

Kom igång redan idag

E-postautentisering tar en eftermiddag att konfigurera och ger omedelbar effekt. Tre DNS-poster skyddar din domän och din GDPR-efterlevnad.

1. Kontrollera din nuvarande konfiguration. Kör en Vakteye-skanning eller använd gratisverktyg för att inspektera dina DNS-poster
2. Lägg till SPF om det saknas. Lista alla tjänster som skickar e-post som din domän, avsluta med -all
3. Aktivera DKIM. De flesta e-postleverantörer (Google Workspace, Microsoft 365) har inbyggd DKIM-konfiguration
4. Publicera DMARC med p=none och rua= för att börja samla rapporter omedelbart
5. Analysera rapporter i 2-4 veckor för att identifiera alla legitima avsändare
6. Eskalera till p=quarantine, sedan p=reject för att slutföra tillämpningskedjan

Varje vecka utan DMARC-tillämpning är ytterligare en vecka angripare kan skicka e-post som din domän. Implementeringen tar en eftermiddag.