E-postkryptering: TLS, end-to-end och GDPR

E-post liknas ofta vid ett vykort: den som läser med på vägen ser allt. E-postkrypteringen avgör om det stämmer. Inlägget beskriver vad transportkryptering och end-to-end-kryptering ger, vad domstolar och tillsynsmyndigheter har sagt om dem och vilken teknik som gör skillnad i praktiken.

Inlägget tar hänsyn till domar, teknik och krav från stora e-postleverantörer fram till slutet av oktober 2026.

Inlägget följer ett e-postmeddelandes väg. Det börjar med måttstocken och begreppen, följt av rättspraxis och tillsynsmyndigheternas syn. Sedan går det över till tekniken: transportkryptering, kontroll av e-postrubriken, skydd mot förfalskade avsändare och end-to-end-metoder som S/MIME och OpenPGP. Till sist finns ett beslutsstöd som visar vilken kryptering som passar vilken typ av e-post.

E-postkryptering och GDPR: vad som är måttstocken

Personuppgifter måste behandlas så att de skyddas mot obehörig åtkomst. Det anges i artikel 5.1 f GDPR. Enligt punkt 2 måste den personuppgiftsansvarige också kunna visa detta. Hur skyddet ska se ut i konkreta termer regleras i artikel 32 GDPR: åtgärder som motsvarar den senaste tekniken och är lämpliga för risken ska vidtas. Bestämmelsen föreskriver inget visst förfarande. Kryptering nämns där bara som en möjlig åtgärd.

Särskilda kategorier av uppgifter, som hälsouppgifter, omfattas av artikel 9 GDPR. Där är skyddsbehovet från början högre. Men även till synes harmlösa e-postmeddelanden innehåller personuppgifter: redan en avsändaradress med fullständigt namn räcker.

Rättsläget 2026 kan sammanfattas så här: Någon generell skyldighet till end-to-end-kryptering för varje e-postmeddelande finns inte. Inte heller finns någon generell frikännande för okrypterade meddelanden. Avgörande är risken för de registrerade och frågan om vad som är rimligt enligt den senaste tekniken. Den som skickar personuppgifter via e-post behöver därför ett motiverat beslut som går att visa upp vid behov.

Transportkryptering, end-to-end och signatur skilda åt

I vardagen blandas tre saker ihop som gör olika saker.

Transportkryptering skyddar anslutningen mellan två stationer. Den bygger på TLS (Transport Layer Security), efterträdaren till SSL. På varje delsträcka överförs innehållet krypterat. På själva e-postservern ligger det däremot i klartext, eftersom servern måste bearbeta och lagra meddelandet.

End-to-end-kryptering (E2E) krypterar innehållet redan i avsändarens e-postprogram. Bara mottagaren kan dekryptera det. Servrarna däremellan ser bara data som de inte kan göra något med. För detta har S/MIME och OpenPGP etablerat sig.

Signaturen är något annat: Den krypterar ingenting, utan visar vem ett meddelande kommer från och att det inte har ändrats på vägen. Vid utbyte av nycklar spelar den en viktig roll, eftersom de offentliga nycklarna oftast delas via signerade meddelanden.

En gräns har båda metoderna gemensamt: Ämnesrad, avsändare och mottagare förblir i regel läsbara. Dataskyddskonferensens vägledning påpekar att även dessa omständigheter kring kommunikationen kan vara skyddsvärda.

Rättspraxis om e-postkryptering: när transportkryptering räcker

Domstolar har avgjort frågan flera gånger de senaste åren, med till synes motstridiga resultat. Vid närmare granskning följer domarna en linje: Ju större möjlig skada, desto högre krav.

Det äldsta fallet i raden är från 2020. Förvaltningsdomstolen i Mainz avgjorde den 17 december 2020 (mål 1 K 778/19.MZ) om en advokat får skicka e-post till klienter med enbart transportkryptering. Avgörandet bedöms enligt artiklarna 32 och 5 GDPR. I domskälen anges att transportkryptering räcker för advokaters e-postkommunikation. End-to-end krävs alltså bara vid förhöjd risk i det enskilda fallet.

Likaså ofta citerat, men bara i begränsad mån relevant, är beslutet från Bundesgerichtshof (förbundsdomstolen) den 22 mars 2021 (AnwZ (Brfg) 2/20). Det gäller den särskilda elektroniska advokatbrevlådan. Dess säkerhetsarkitektur bygger på egna hårdvarusäkerhetsmoduler. Någon rätt till end-to-end-kryptering finns inte där. På vanlig e-post går det knappast att överföra.

Fallet från Oberlandesgericht (överdomstolen) i Karlsruhe visar linjen i näringslivet. En hackare hade tagit över en bilhandlares e-postkonto och skickat köparen en manipulerad faktura med ett annat kontonummer. Köparen betalade till fel konto. Domstolen slog den 27 juli 2023 (mål 19 U 83/22) fast att de nödvändiga skyddsåtgärderna avgörs av affärspartnernas berättigade säkerhetsförväntningar. Betalningen till bedragaren befriade inte köparen, som fick betala en andra gång. Landgericht (tingsrätten) i Mosbach hade som första instans bedömt saken annorlunda.

Oberlandesgericht i Schleswig kom i december 2024 till ett annat resultat. Även här gällde det en manipulerad faktura, denna gång mot en konsument och på cirka 15 000 euro. Enligt domstolens pressmeddelande hade fakturan behövt skickas med end-to-end-kryptering, eftersom ett hackerangrepp är en förutsebar risk. Kunden kunde invända ett skadeståndsanspråk mot betalningskravet och behövde inte betala igen. Domstolen hade medgivit revision, men enligt pressmeddelandet har domen ändå vunnit laga kraft. En genomgång av dessa avgöranden, inklusive en dom från förvaltningsdomstolen i Düsseldorf den 2 april 2026 (29 K 7351/23), finns i inlägget Sicherheitsvorkehrungen beim Versand von E-Mails.

Hur hänger det ihop? Avgörande är uppenbarligen skyddsbehov och skadepotential. Mellan företag har domstolarna hittills snarare godtagit standardåtgärder. Där en konsument överför en hög summa till ett konto som bara anges i ett oskyddat e-postmeddelande krävs mer. Förfarandets namn är underordnat. Viktigt är att åtgärden faktiskt minskar den konkreta risken. Öppet är till exempel om mottagarens samtycke till svagare kryptering räcker. Det finns ännu inget hållbart avgörande om det.

DSK:s vägledning och BSI: tillsynsmyndigheternas måttstock

Konferensen för de oberoende dataskyddsmyndigheterna (DSK) beslutade den 27 maj 2021 vägledningen ”Åtgärder för att skydda personuppgifter vid överföring via e-post”, version 16 juni 2021. Bayern röstade emot. Dokumentet är offentligt tillgängligt och gör en tydlig åtskillnad.

Vid normal risk kräver vägledningen obligatorisk transportkryptering enligt BSI:s tekniska riktlinje TR-03108-1. Vid hög risk bör de ansvariga regelmässigt använda end-to-end-kryptering och en kvalificerad transportkryptering, alltså till exempel med DANE eller DNSSEC. Tystnadsplikt anses då vara ett tecken på hög risk, vilket måste prövas i det enskilda fallet.

Sanktionsavgifter för okrypterad e-post är ovanliga, och tillsynsmyndigheterna verkar mindre genom sanktioner än genom dokument som detta. Som måttstock har vägledningen ändå tyngd: I tvisterna om manipulerade fakturor diskuterades om myndigheternas anvisningar kan åberopas. Oberlandesgericht i Karlsruhe ansåg dem inte vara tillämpliga i det aktuella fallet. Vägledningen är inte bindande. Den som avviker från den bör dock kunna motivera det.

BSI beskriver i TR-03108 säker e-posttransport för leverantörer, inklusive certifiering. För den som driver e-postservrar är den den tekniska mätlatten. Dessutom finns med TR-03182 en rekommendation om autentisering av e-post.

Genomföra transportkryptering rätt: TLS 1.3, port 465, MTA-STS och DANE

E-postprogram och servrar talar flera protokoll. SMTP (Simple Mail Transfer Protocol) används sedan 1982 och överför e-post. ESMTP är den utökade varianten. Förkortningarna i e-postrubriken visar vad som hände på respektive delsträcka: ESMTPS betyder att TLS förhandlades fram. ESMTPSA innebär dessutom att avsändaren loggade in med användarnamn och lösenord.

Vid förhandlingen finns två vägar. Vid implicit TLS börjar anslutningen krypterad direkt. För att skicka e-post från programmet är enligt RFC 8314 port 465 avsedd, för hämtning IMAP via port 993 eller POP3 via port 995. Vid STARTTLS startar anslutningen okrypterad, och båda sidor förhandlar först därefter om övergången. Detta steg kan störas av angripare. Studien ”Why TLS is better without STARTTLS” (USENIX Security 2021) beskriver downgrade- och injektionsattacker. Därför gäller implicit TLS som det bättre valet, även om port 587 med STARTTLS på många håll erbjuds parallellt.

Om versionerna: TLS 1.0 och 1.1 är sedan RFC 8996 (mars 2021) officiellt utfasade. TLS 1.2 är den nedre gränsen, TLS 1.3 målet, så även i BSI:s tekniska riktlinje TR-02102-2.

Ett problem kvarstår mellan servrarna. Där sker krypteringen oftast via STARTTLS och är ofta bara opportunistisk: Om det inte fungerar faller anslutningen tillbaka till okrypterat. Många e-postservrar erbjuder ett läge som avvisar leveransen om ingen TLS kommer till stånd. Även det går som regel via STARTTLS och är inte implicit TLS.

Två metoder täcker luckan:

• MTA-STS (RFC 8461): Mottagardomänen publicerar en policy om att TLS med giltigt certifikat är obligatoriskt. Sändande servrar håller sig till den. DNSSEC behövs inte. Det finns lägena testing och enforce. Rapporter om problem levereras av TLS-RPT.
• DANE: I DNS anges med en TLSA-post vilket certifikat mottagarservern använder. Det förutsätter DNSSEC. DANE säkrar mottagarserverns äkthet mot downgrade och man-in-the-middle.

För Exchange Online är inkommande SMTP med DANE enligt Microsoft allmänt tillgängligt sedan den 22 oktober 2024, men som standard avstängt. MTA-STS stöds enligt Microsofts dokumentation. Om den egna domänen publicerar sådana policyer kan kontrolleras med onlineverktyg, mer om det i nästa avsnitt.

Kontrollera krypteringen: läsa e-postrubriken och testa mottagarservern

Om ett meddelande verkligen kom fram krypterat framgår av e-postrubriken. I klassiska Outlook-versioner öppnar man meddelandet med dubbelklick, sedan Arkiv, Egenskaper, fältet Internetrubriker. I nya Outlook och i webbmailen ser vägen annorlunda ut. Menyerna ändras mellan versionerna, så det lönar sig att titta i hjälpen för respektive program.

I rubrikraderna är Received-raderna intressanta. Varje server som vidarebefordrar meddelandet lägger till en. Moderna servrar skriver där in protokollversion och metod, till exempel TLSv1.3 och TLS_AES_256_GCM_SHA384. Utdraget nedan är återskapat, med platshållare i stället för riktiga adresser.

Rubriken är dock inget heltäckande bevis i den mening som avses i artikel 5.2. Den visar bara de delsträckor där en server har lagt till raden. Där vidarebefordringar eller gateways ingår finns en lucka. Som byggsten i en dokumentation duger den ändå.

Före sändning kan man testa vad en mottagarserver klarar. CheckTLS frågar efter funktionerna utan att skicka något e-postmeddelande och visar bland annat om TLS erbjuds och om det finns en TLSA-post för DANE. Resultatet ”no TLSA” är vanligt hos många domäner. Tjänsten internet.nl kontrollerar STARTTLS, DANE samt SPF, DKIM och DMARC. MTA-STS ingår enligt dokumentationen inte i bedömningen.

Vid ett negativt TLS-resultat hjälper ett meddelande till mottagaren. Alternativt kan en portal eller en krypterad bilaga komma i fråga, mer om det längre ner. För den egna webbplatsen och dess skyddsåtgärder ger DSGVO Webseiten-Check en första orientering. Säkerhetskontroller för domäner, inklusive e-postautentisering, finns hos Web Security Checks.

SPF, DKIM och DMARC: skydd mot förfalskade avsändare

Kryptering skyddar mot att någon läser med, inte mot förfalskning. Just det var kärnan i fakturafallen: En angripare skickar ett meddelande som ser ut att komma från den riktiga avsändaren, eller använder en kapad brevlåda. Mot förfalskade avsändare hjälper tre metoder som samverkar.

Trycket att införa dem har på senare tid kommit från de stora leverantörerna. Google och Yahoo kräver sedan den 1 februari 2024 av alla avsändare bland annat SPF eller DKIM, TLS och en låg spamfrekvens. Den som skickar mer än 5 000 meddelanden per dag till Gmail-adresser behöver SPF, DKIM och minst en DMARC-policy. Microsoft har för avsändare med hög volym till Outlook.com, Hotmail och Live infört liknande krav från och med den 5 maj 2025. Reglerna i detalj finns i Googles dokumentation.

DSK:s vägledning föreskriver att DKIM och DMARC kontrolleras vid mottagandet. Här tecknar sig en utveckling som ansvariga helst inte bör blunda för. Ytterligare bakgrund om förfalskade meddelanden ger inlägget E-Mails, Phishing und die Echtheit elektronischer Nachrichten. Om hanteringen av okända avsändare och bilagor finns ett eget inlägg.

End-to-end med S/MIME och OpenPGP: läget 2026

Den som vill eller måste gå längre än transportkryptering har två etablerade metoder. Båda krypterar innehållet i e-postprogrammet. Båda kräver nycklar som utbyts i förväg. DSK:s vägledning kallar end-to-end det ”mest genomgripande skyddet”, eftersom det också skyddar data i vila.

S/MIME

S/MIME arbetar med certifikat som utfärdas av en certifikatutfärdare. De kan användas direkt i Outlook, Apple Mail och många andra program. Mottagarens offentliga nyckel får avsändaren oftast via ett signerat meddelande, ur vilket certifikatet kan hämtas.

Mycket har förändrats i fråga om certifikat sedan 2021. De tidigare vanliga klasserna 1 till 4 är förlegade. Sedan den 1 september 2023 gäller CA/Browser Forums Baseline Requirements med fyra typer som skiljer sig åt i granskningens omfattning: Mailbox-, Organization-, Sponsor- och Individual-validated. Det aktuella läget för kraven publicerar forumet självt.

OpenPGP

OpenPGP fungerar utan central certifikatutfärdare. Var och en skapar ett eget nyckelpar. Äktheten kontrolleras via fingeravtryck eller intygande av tredje part. DSK påpekar uttryckligen att enbart publicering av en nyckel på en nyckelserver inte är något tecken på att den är äkta. Praktiskt är Web Key Directory, via vilken en domän själv tillhandahåller sina nycklar. En introduktion till signering ger inlägget E-Mails mit PGP signieren und verschicken.

Standarden har förändrats: RFC 9580 (juli 2024) ersätter RFC 4880. Den för med sig nya nyckelformat, moderna metoder som X25519 och Ed25519 samt autentiserad kryptering. Vid sidan av det driver GnuPG-projektet med LibrePGP en avvikande linje. Det komplicerar läget. Thunderbird använder ett eget bibliotek kallat RNP i stället för GnuPG, och Mozilla dokumenterar problem med nycklar som har egenskaper som RNP inte stöder. Nycklar flyttas alltså inte alltid friktionsfritt mellan programmen.

Praktik med Outlook och Thunderbird

I praktiken syns ofta en skillnad mellan drift med ett konto och med flera konton. Tillägget GpgOL ur paketet Gpg4win kan ställas in i Outlook och fungerar med ett konto. Med flera konton dyker däremot en fråga upp vid varje sändning, och tilldelningen av nycklar kan bli rörig. För miljöer med många konton är det ett hinder.

För närvarande finns Gpg4win i version 5.1.1 (utgiven den 23 september 2026), vilket projektsidan visar. GpgOL fungerar i klassiska Outlook. Om och när det kommer att stödja nya Outlook är enligt ett inlägg i GnuPG-forumet öppet. I Thunderbird är OpenPGP inbyggt sedan version 78, något tilläggsprogram behövs inte. Inställningen görs i kontoinställningarna under end-to-end-kryptering. Den som bara använder ett konto kommer snabbt i mål.

BSI undersökte i december 2025 tolv kostnadsfria e-postprogram. Enligt pressmeddelandet skiljer sig programmen åt i stödet för end-to-end-kryptering. Säkerhetsfunktioner är ofta inte aktiva från start.

En bisak är attacken Efail från 2018. Den utnyttjade aktivt HTML-innehåll i e-post för att leda dekrypterade texter utåt. Som motåtgärd gäller aktuella program och avstängd HTML-visning för krypterade meddelanden. En förklaring finns på sidan efail.de. Panik är inte på sin plats, men exemplet visar att även god kryptografi kan haverera i genomförandet.

Portaler, gateways och Microsofts kryptering som alternativ

Det största hindret för end-to-end är nyckelutbytet med varje motpart. Därför satsar många organisationer på lösningar där arbetet ligger hos avsändaren.

• Gateway-kryptering: En server i företaget tar över S/MIME eller PGP. Skyddet når då fram till mottagarens gateway. I brevlådan ligger meddelandet, beroende på inställning, dekrypterat. Förtroendefrågan flyttas till gatewayns operatör.
• Portal: Meddelandet innehåller bara en notis. Själva meddelandet hämtas i webbläsaren efter inloggning. Även DSK:s vägledning nämner en webbportal som kommunikationsväg gentemot registrerade.
• Microsoft Purview Message Encryption: Kan användas i nya Outlook med lämplig licens. Mottagare utanför Microsoft får en öppningsanvisning. På samma meddelande kan den inte kombineras med S/MIME.
• Lösenordsskyddad bilaga: Ett arkiv med AES-256, till exempel skapat med 7-Zip, fungerar som kuvert. Lösenordet går via en annan kanal, till exempel per telefon (mediebrott). SMS är omstritt som kanal och bör bara användas med förbehåll.

Den som driver en gateway eller portal hos en tjänsteleverantör ingår i regel ett personuppgiftsbiträdesavtal enligt artikel 28 GDPR. Risker med själva kontot som hör ihop med Microsoft 365 beskrivs i inlägget om token spraying.

Avvägningen är nykter: Den som skyr nyckelhanteringen får med portal eller gateway en praktikabel medelväg. Den innebär avkall jämfört med äkta end-to-end-kryptering, men är klart bättre än ett klartextmeddelande med känsligt innehåll.

Kvantsäker kryptografi i e-post: vad som redan räknas i dag

End-to-end har en egenskap som ofta förbises: Perfect Forward Secrecy finns där inte från början. DSK skriver att avlyssnade meddelanden kan sparas och dekrypteras senare om den privata nyckeln röjs. Med framtida kvantdatorer skulle detta scenario kunna inträffa även utan nyckelförlust.

Standardiseringen pågår. Med RFC 9936 (mars 2026) finns en standard för ML-KEM i CMS, grunden för S/MIME. För TLS 1.3 föreskriver BSI TR-02102-2 hybridmetoder som kombinerar klassiska och kvantsäkra metoder. I vardagen innebär det inget tvång att agera. Den som skickar innehåll som måste vara konfidentiellt även om 15 år bör ändå hålla ämnet under uppsikt.

Felsändning, dataintrång och telefax: krypteringens gränser

En nackdel med transportkryptering gäller än i dag: Vid fel mottagaradress hjälper den inte. Meddelandet hamnar krypterat på fel server och ligger där i klartext. Vid end-to-end är det annorlunda, förutsatt att det adresserades till den avsedda mottagaren. DSK nämner uttryckligen individuell adressering som åtgärd.

Därför räknas den organisatoriska delen. Hit hör avstängd automatisk komplettering för känsliga mottagare, fyraögonprincip för känsligt innehåll och kontroll av adressen före sändning. Om en felsändning ska anmälas som personuppgiftsincident beror på risken och hör hemma i ett eget förfarande.

Även telefaxen dyker upp i den här debatten. Delstatens dataskyddsombud i Bremen har på en sida med vägledningar jämfört fax med okrypterad e-post. Oberverwaltungsgericht (högre förvaltningsdomstolen) i Lüneburg ansåg i ett beslut från 2020 (11 LA 104/19) att en prövning i det enskilda fallet var nödvändig för särskilt känsliga uppgifter.

Vilken kryptering för vilket e-postmeddelande: beslutsstöd

Av domarna och riktlinjerna går det att härleda en tumregel. Ju högre skadepotential och sekretessbehov, desto hellre kommer end-to-end eller en portal i fråga. För fakturor gäller dessutom: En ändring av bankuppgifter bekräftas via en andra kanal, till exempel per telefon.

Tabellen är till för orientering och utgör inte juridisk rådgivning. Riskbedömningen ligger hos den personuppgiftsansvarige och bör dokumenteras. Då hjälper en kort prövning: Vilken är den värsta realistiska skadan för de registrerade? Hur sannolik är den? Vilken åtgärd minskar den märkbart?

Slutsats

Transportkryptering är obligatorisk och enligt DSK och rättspraxis oftast tillräcklig vid normal risk, om den är genomförd konsekvent och enligt den senaste tekniken. Hit hör TLS 1.2 eller helst 1.3, implicit TLS i e-postprogrammet samt MTA-STS eller DANE på serversidan. Vid hög risk förväntas end-to-end eller en likvärdig lösning.

E-postkryptering förblir ett ämne med avvägningar. Nyckelhantering är besvärlig, portaler är en pragmatisk medelväg, och mot bedrägeri hjälper SPF, DKIM, DMARC samt en andra kanal för betalningsuppgifter minst lika mycket som kryptografi.