E-mailkryptering: TLS, ende-til-ende og GDPR

E-mails sammenlignes ofte med postkort: Alle, der læser med undervejs, kan se alt. E-mailkryptering afgør, om det passer. Her beskrives, hvad transportkryptering og ende-til-ende-kryptering kan, hvad domstole og tilsynsmyndigheder har sagt om dem, og hvilken teknik der gør forskellen i praksis.

Indlægget tager højde for domme, teknik og kravene fra store mailudbydere frem til udgangen af oktober 2026.

Indlæggets opbygning følger en mails vej. Først kommer målestokken og begreberne, derefter retspraksis og tilsynsmyndighedernes syn. Så handler det om teknikken: transportkryptering, kontrol af mailheaderen, beskyttelse mod forfalskede afsendere og ende-til-ende-metoder som S/MIME og OpenPGP. Til sidst følger en beslutningshjælp, der viser, hvilken kryptering der passer til hvilken slags mail.

E-mailkryptering og GDPR: hvad er målestokken

Personoplysninger skal behandles på en måde, der beskytter dem mod uautoriseret adgang. Det fremgår af art. 5, stk. 1, litra f, i GDPR. Efter stk. 2 skal den dataansvarlige også kunne påvise det. Hvordan beskyttelsen konkret skal se ud, fastlægges i art. 32 i GDPR: Der skal træffes foranstaltninger i overensstemmelse med det aktuelle tekniske niveau, som står i et rimeligt forhold til risikoen. Bestemmelsen foreskriver ikke en bestemt metode. Kryptering nævnes blot som en mulig foranstaltning.

Særlige kategorier af oplysninger som helbredsoplysninger falder under art. 9 i GDPR. Her er beskyttelsesbehovet fra starten højere. Men også tilsyneladende uskyldige mails indeholder personoplysninger: Allerede en afsenderadresse med fuldt navn er nok.

Retsstillingen kan i 2026 opsummeres sådan: Der er ingen generel pligt til ende-til-ende-kryptering af hver eneste mail. Der er heller ikke en generel frikendelse for ukrypterede mails. Det afgørende er risikoen for de registrerede og spørgsmålet om, hvad der er rimeligt efter det aktuelle tekniske niveau. Den, der sender personoplysninger pr. mail, har derfor brug for en begrundet beslutning, som i tvivlstilfælde kan fremlægges.

Transportkryptering, ende-til-ende og signatur holdt ordentligt ude fra hinanden

I hverdagen blandes tre ting sammen, som gør hver sit.

Transportkryptering sikrer forbindelsen mellem to stationer. Den bruger TLS (Transport Layer Security), efterfølgeren til SSL. På hver delstrækning overføres indholdet krypteret. På selve mailserveren ligger det derimod i klartekst, for serveren skal jo behandle og gemme mailen.

Ende-til-ende-kryptering (E2E) krypterer indholdet allerede i afsenderens mailprogram. Kun modtageren kan dekryptere det. Servere undervejs ser kun data, som de ikke kan bruge til noget. S/MIME og OpenPGP har slået igennem til det formål.

Signaturen er noget andet: Den krypterer ingenting, men dokumenterer, hvem en mail stammer fra, og at den ikke er ændret undervejs. Ved udveksling af nøgler spiller den en vigtig rolle, fordi de offentlige nøgler som regel gives videre via signerede mails.

En begrænsning har begge metoder til fælles: Emnelinje, afsender og modtager forbliver som regel læselige. Datatilsynenes fælles vejledning (DSK) peger på, at også disse omstændigheder ved kommunikationen kan have brug for beskyttelse.

Retspraksis om e-mailkryptering: hvornår transportkryptering er nok

Domstolene har afgjort spørgsmålet flere gange i de seneste år med tilsyneladende modstridende resultater. Ved nærmere eftersyn følger dommene én linje: Jo større den mulige skade, desto højere krav.

Den ældste sag i rækken stammer fra 2020. Forvaltningsdomstolen i Mainz (Verwaltungsgericht Mainz) afgjorde den 17. december 2020 (sagsnr. 1 K 778/19.MZ), om en advokat må sende e-mails til klienter alene med transportkryptering. Afgørelsen indplaceres efter art. 32 og art. 5 i GDPR. Ifølge retsgrundsætningen er transportkryptering tilstrækkelig i advokaters e-mailkommunikation. Ende-til-ende er dermed kun nødvendig i enkelttilfælde med forhøjet risiko.

Ofte citeret, men kun i begrænset omfang relevant, er også den tyske forbundsdomstols (Bundesgerichtshof) kendelse af 22. marts 2021 (AnwZ (Brfg) 2/20). Den angår advokaternes særlige elektroniske postkasse (beA). Dens sikkerhedsarkitektur bygger på egne hardwaresikkerhedsmoduler. Der er ikke noget krav på ende-til-ende-kryptering dér. Den kan næppe overføres til almindelige e-mails.

Sagen ved Oberlandesgericht (OLG) Karlsruhe viser forretningslivets linje. En hacker havde overtaget en autoforhandlers mailkonto og sendt køberen en manipuleret faktura med et andet kontonummer. Køberen betalte til den forkerte konto. Retten fastslog den 27. juli 2023 (sagsnr. 19 U 83/22), at de nødvendige beskyttelsesforanstaltninger afhænger af forretningspartnernes berettigede sikkerhedsforventninger. Betalingen til svindleren frigjorde ikke køberen, han måtte betale en gang til. Landgericht Mosbach havde som første instans afgjort sagen anderledes.

Oberlandesgericht Schleswig nåede i december 2024 til et andet resultat. Også her drejede det sig om en manipuleret faktura, denne gang over for en forbruger og på omkring 15.000 euro. Ifølge rettens pressemeddelelse skulle fakturaen have været sendt med ende-til-ende-kryptering, fordi et hackerangreb er en forudsigelig risiko. Kunden kunne over for betalingskravet gøre et erstatningskrav gældende og skulle ikke betale igen. Retten havde tilladt revision, men ifølge dens pressemeddelelse er dommen alligevel endelig. En vurdering af disse afgørelser, herunder en dom fra Verwaltungsgericht Düsseldorf af 2. april 2026 (29 K 7351/23), findes i indlægget Sikkerhedsforanstaltninger ved afsendelse af e-mails.

Hvordan hænger det sammen? Afgørende er åbenbart beskyttelsesbehovet og skadespotentialet. Mellem virksomheder accepterede domstolene hidtil snarere standardforanstaltninger. Hvor en forbruger overfører et stort beløb til en konto, som kun oplyses i en ubeskyttet mail, kræves der mere. Sagens betegnelse er underordnet. Det vigtige er, at foranstaltningen faktisk reducerer den konkrete risiko. Det er fx stadig uafklaret, om modtagerens samtykke til svagere kryptering er nok. Der foreligger endnu ingen pålidelig afgørelse herom.

DSK's vejledning og BSI: tilsynsmyndighedernes målestok

Konferencen af de uafhængige tyske datatilsynsmyndigheder (DSK) vedtog den 27. maj 2021 vejledningen „Foranstaltninger til beskyttelse af personoplysninger ved transmission pr. e-mail“, version af 16.06.2021. Bayern stemte imod. Papiret er offentligt tilgængeligt og gør en klar skelnen.

Ved normal risiko kræver vejledningen obligatorisk transportkryptering med udgangspunkt i BSI's tekniske retningslinje TR-03108-1. Ved høj risiko skal dataansvarlige regelmæssigt anvende ende-til-ende-kryptering og en kvalificeret transportkryptering, altså fx med DANE eller DNSSEC. En tavshedspligt gælder her som indikation på en høj risiko, som skal vurderes i det enkelte tilfælde.

Bøder for ukrypterede mails er sjældne, tilsynsmyndighederne virker mindre gennem sanktioner end gennem papirer som dette. Som målestok har vejledningen alligevel vægt: I tvisterne om manipulerede fakturaer blev det drøftet, om tilsynsmyndighedernes anvisninger kan inddrages. Oberlandesgericht Karlsruhe fandt dem ikke relevante i den pågældende sag. Vejledningen er ikke bindende. Men den, der afviger fra den, bør kunne begrunde det.

BSI beskriver i TR-03108 den sikre e-mailtransport for udbydere, herunder certificering. For mailserveroperatører er den den tekniske målestok. Som supplement findes TR-03182, en anbefaling om e-mailautentificering.

Gennemfør transportkryptering rigtigt: TLS 1.3, port 465, MTA-STS og DANE

Mailprogrammer og servere taler flere protokoller. SMTP (Simple Mail Transfer Protocol) har været i brug siden 1982 og overfører mails. ESMTP er den udvidede variant. Forkortelserne i mailheaderen viser, hvad der skete på den enkelte delstrækning: ESMTPS betyder, at TLS blev forhandlet. ESMTPSA betyder desuden, at afsenderen loggede ind med brugernavn og adgangskode.

Ved forhandlingen er der to veje. Ved implicit TLS er forbindelsen krypteret fra første øjeblik. Til afsendelse af mail fra programmet er efter RFC 8314 port 465 beregnet, til hentning IMAP over port 993 eller POP3 over port 995. Ved STARTTLS starter forbindelsen ukrypteret, og begge sider forhandler først derefter skiftet. Dette trin kan forstyrres af angribere. Undersøgelsen „Why TLS is better without STARTTLS“ (USENIX Security 2021) beskriver downgrade- og injection-angreb. Derfor anses implicit TLS for det bedre valg, selv om port 587 med STARTTLS mange steder fortsat tilbydes parallelt.

Om versionerne: TLS 1.0 og 1.1 er siden RFC 8996 (marts 2021) officielt udfaset. TLS 1.2 er den nedre grænse, TLS 1.3 er målet, også i BSI's tekniske retningslinje TR-02102-2.

Et problem består mellem serverne. Dér sker krypteringen som regel via STARTTLS og er ofte kun opportunistisk: Lykkes det ikke, falder forbindelsen tilbage til ukrypteret. Mange mailservere har en tilstand, der afviser leveringen, hvis der ikke kommer TLS i stand. Det sker som regel også via STARTTLS og er ikke implicit TLS.

To metoder lukker hullet:

• MTA-STS (RFC 8461): Modtagerdomænet offentliggør en politik om, at TLS med gyldigt certifikat er obligatorisk. Afsendende servere retter sig efter den. Der kræves ikke DNSSEC. Der findes tilstandene testing og enforce. Rapporter om problemer leverer TLS-RPT.
• DANE: I DNS fastlægges med en TLSA-post, hvilket certifikat modtagerserveren bruger. Det forudsætter DNSSEC. DANE sikrer modtagerserverens ægthed mod downgrade og man-in-the-middle.

For Exchange Online er indgående SMTP med DANE ifølge Microsoft generelt tilgængeligt siden 22.10.2024, men som standard slået fra. MTA-STS understøttes ifølge Microsofts dokumentation. Om ens eget domæne offentliggør sådanne politikker, kan kontrolleres med onlineværktøjer, mere herom i næste afsnit.

Kontrollér kryptering: læs mailheaderen og test modtagerserveren

Om en mail faktisk kom frem krypteret, fremgår af mailheaderen. I klassiske Outlook-versioner åbner man mailen med et dobbeltklik, derefter Filer, Egenskaber, feltet Internetoverskrifter. I det nye Outlook og i webmail ser vejen anderledes ud. Menuerne ændrer sig fra version til version, så det er værd at kigge i det pågældende programs hjælp.

I headerne er det Received-linjerne, der er interessante. Hver server, der sender mailen videre, tilføjer en. Moderne servere skriver protokolversion og metode dér, fx TLSv1.3 og TLS_AES_256_GCM_SHA384. Udsnittet nedenfor er bygget efter, med pladsholdere i stedet for rigtige adresser.

Headeren er dog ikke et fuldstændigt bevis i art. 5, stk. 2's forstand. Den dokumenterer kun de delstrækninger, hvor en server har tilføjet linjen. Hvor videresendelser eller gateways er involveret, består et hul. Som byggesten i en dokumentation duer den alligevel.

Før afsendelsen kan man teste, hvad en modtagerserver kan. CheckTLS forespørger dens egenskaber uden at sende en mail og viser blandt andet, om der tilbydes TLS, og om der findes en TLSA-post til DANE. Resultatet „no TLSA“ er almindeligt for mange domæner. Tjenesten internet.nl kontrollerer STARTTLS, DANE samt SPF, DKIM og DMARC. MTA-STS indgår ifølge dokumentationen ikke i vurderingen.

Ved et negativt TLS-resultat hjælper en besked til modtageren. Alternativt kommer en portal eller en krypteret vedhæftning i betragtning, mere herom nedenfor. Til ens egen hjemmeside og dens beskyttelsesforanstaltninger giver GDPR-webstedstjekket en første orientering. Sikkerhedstjek af domæner, herunder e-mailautentificering, findes hos Web Security Checks.

SPF, DKIM og DMARC: beskyttelse mod forfalskede afsendere

Kryptering beskytter mod at blive læst med, ikke mod forfalskning. Det var netop det, fakturasagerne handlede om: En angriber sender en mail, der ligner den ægte afsenders, eller bruger en kapret postkasse. Mod forfalskede afsendere hjælper tre metoder, der virker sammen.

Presset for at indføre dem er på det seneste kommet fra de store udbydere. Google og Yahoo kræver siden 01.02.2024 af alle afsendere blandt andet SPF eller DKIM, TLS og en lav spamrate. Den, der sender mere end 5.000 mails om dagen til Gmail-adresser, har brug for SPF, DKIM og mindst en DMARC-politik. Microsoft har for højvolumenafsendere til Outlook.com, Hotmail og Live indført tilsvarende krav fra 05.05.2025. Reglerne i enkeltheder står i Googles dokumentation.

DSK's vejledning foreskriver, at DKIM og DMARC kontrolleres ved modtagelsen. Her tegner der sig en udvikling, som dataansvarlige helst ikke bør overse. Yderligere baggrund om forfalskede meddelelser giver indlægget E-mails, phishing og elektroniske meddelelsers ægthed. Om omgangen med ukendte afsendere og vedhæftninger findes et eget indlæg.

Ende-til-ende med S/MIME og OpenPGP: status i 2026

Den, der vil eller skal gå videre end transportkryptering, har to etablerede metoder. Begge krypterer indholdet i mailprogrammet. Begge kræver nøgler, som skal udveksles på forhånd. DSK's vejledning kalder ende-til-ende den „mest gennemgribende beskyttelse“, fordi den også beskytter data i hvile.

S/MIME

S/MIME arbejder med certifikater, som en certificeringsmyndighed udsteder. De kan bruges direkte i Outlook, Apple Mail og mange andre programmer. Modtagerens offentlige nøgle får afsenderen som regel via en signeret mail, hvorfra certifikatet kan overtages.

Ved certifikaterne har meget ændret sig siden 2021. De tidligere gængse klasser 1 til 4 er forældede. Siden 01.09.2023 gælder CA/Browser Forums Baseline Requirements med fire typer, der adskiller sig efter kontrollens omfang: Mailbox-, Organization-, Sponsor- og Individual-validated. Den aktuelle status for kravene offentliggør forummet selv.

OpenPGP

OpenPGP arbejder uden central certificeringsmyndighed. Enhver opretter sit eget nøglepar. Ægtheden kontrolleres via fingeraftryk eller tredjeparters bekræftelse. DSK understreger udtrykkeligt, at selve offentliggørelsen af en nøgle på en nøgleserver ikke er en indikation på dens ægthed. Praktisk er Web Key Directory, hvormed et domæne selv stiller sine nøgler til rådighed. En introduktion til signering giver indlægget Signér og send e-mails med PGP.

Standarden har ændret sig: RFC 9580 (juli 2024) afløser RFC 4880. Den bringer nye nøgleformater, moderne metoder som X25519 og Ed25519 samt autentificeret kryptering. Ved siden af plejer GnuPG-projektet med LibrePGP en afvigende linje. Det komplicerer situationen. Thunderbird bruger et eget bibliotek kaldet RNP i stedet for GnuPG, og Mozilla dokumenterer problemer med nøgler med egenskaber, som RNP ikke understøtter. Nøgler flytter sig altså ikke altid gnidningsfrit mellem programmerne.

Praksis med Outlook og Thunderbird

I praksis viser der sig ofte en forskel mellem drift med én og flere konti. Plugin'et GpgOL fra pakken Gpg4win kan sættes op i Outlook og fungerer med én konto. Ved flere konti dukker der derimod en forespørgsel op ved hver afsendelse, og tildelingen af nøgler kan gå i vasken. I miljøer med mange konti er det en hindring.

Aktuelt fås Gpg4win i version 5.1.1 (udgivet 23.09.2026), som projektsiden viser. GpgOL kører i klassisk Outlook. Om og hvornår det understøtter det nye Outlook, er ifølge et indlæg i GnuPG-forummet uvist. I Thunderbird er OpenPGP indbygget siden version 78, så et tilføjelsesprogram er overflødigt. Opsætningen sker i kontoindstillingerne under ende-til-ende-kryptering. Den, der kun bruger én konto, er hurtigt i mål.

BSI undersøgte i december 2025 tolv gratis mailprogrammer. Ifølge pressemeddelelsen adskiller programmerne sig i understøttelsen af ende-til-ende-kryptering. Sikkerhedsfunktioner er ofte ikke aktive fra start.

Et sidespor er angrebet Efail fra 2018. Det udnyttede aktivt HTML-indhold i mails til at lede dekrypterede tekster ud. Som modforanstaltning gælder aktuelle programmer og deaktiveret HTML-visning ved krypterede mails. En forklaring findes på siden efail.de. Panik er der ikke grund til, men eksemplet viser, at også god kryptografi kan slå fejl i gennemførelsen.

Portaler, gateways og Microsoft-kryptering som alternativer

Den største hindring for ende-til-ende er nøgleudvekslingen med hver enkelt modpart. Derfor satser mange organisationer på løsninger, hvor arbejdet ligger hos afsenderen.

• Gateway-kryptering: En server i virksomheden overtager S/MIME eller PGP. Beskyttelsen rækker så til modtagerens gateway. I postkassen ligger mailen, afhængigt af opsætningen, dekrypteret. Spørgsmålet om tillid flytter sig til gatewayens operatør.
• Portal: Mailen indeholder kun en henvisning. Beskeden hentes i browseren efter login. Også DSK's vejledning nævner en webportal som kommunikationsvej over for registrerede.
• Microsoft Purview Message Encryption: Kan bruges i det nye Outlook med passende licens. Modtagere uden for Microsoft får en vejledning til at åbne mailen. På samme besked kan den ikke kombineres med S/MIME.
• Adgangskodebeskyttet vedhæftning: Et arkiv med AES-256, fx lavet med 7-Zip, fungerer som kuvert. Adgangskoden sendes via en anden kanal, fx telefonisk (mediebrud). SMS er omstridt som kanal og bør kun bruges med forbehold.

Den, der driver en gateway eller portal hos en tjenesteudbyder, indgår som regel en databehandleraftale efter art. 28 i GDPR. Risici ved selve kontoen i forbindelse med Microsoft 365 beskriver indlægget om token spraying.

Afvejningen er nøgtern: Den, der skyr nøgleadministration, får med portal eller gateway en brugbar mellemvej. Den medfører afkald i forhold til ægte ende-til-ende-kryptering, men er klart bedre end en klartekstmail med følsomt indhold.

Post-kvantekryptografi ved e-mail: hvad der allerede tæller i dag

Ende-til-ende har en egenskab, der ofte overses: Perfect Forward Secrecy findes her ikke fra naturens hånd. DSK skriver hertil, at opsnappede mails kan gemmes og senere dekrypteres, hvis den private nøgle bliver afsløret. Med fremtidige kvantecomputere kunne dette scenarie også indtræffe uden tab af nøgle.

Standardiseringen er i gang. Med RFC 9936 (marts 2026) foreligger en standard for ML-KEM i CMS, grundlaget for S/MIME. For TLS 1.3 foreskriver BSI TR-02102-2 hybride metoder, der kombinerer klassiske og post-kvantemetoder. For hverdagen følger der heraf ingen handlepligt. Den, der sender indhold, som også om 15 år skal være fortroligt, bør dog holde øje med emnet.

Fejlsendelse, databrud og telefax: krypteringens grænser

En ulempe ved transportkryptering gælder fortsat: Ved en forkert modtageradresse hjælper den ikke. Mailen havner krypteret på den forkerte server og ligger dér i klartekst. Ved ende-til-ende er det anderledes, forudsat at den var adresseret til den tiltænkte modtager. DSK nævner udtrykkeligt individuel adressering som foranstaltning.

Derfor tæller den organisatoriske del. Til den hører slået-fra autofuldførelse ved følsomme modtagere, et fire-øjne-princip ved ømtålelige indhold og kontrol af adressen før afsendelsen. Om en fejlsendelse skal anmeldes som brud på persondatasikkerheden, afhænger af risikoen og hører hjemme i en egen procedure.

Også telefaxen dukker op i denne debat. Delstatens databeskyttelses- og informationsfrihedskommissær i Bremen har på en side med vejledninger sammenlignet fax med ukrypterede mails. Oberverwaltungsgericht Lüneburg har i en kendelse fra 2020 (11 LA 104/19) anset en vurdering i det enkelte tilfælde for nødvendig ved særligt følsomme oplysninger.

Hvilken kryptering til hvilken e-mail: beslutningshjælp

Af dommene og retningslinjerne kan der udledes en tommelfingerregel. Jo højere skadespotentiale og fortrolighedsbehov, desto mere kommer ende-til-ende eller en portal i betragtning. Ved fakturaer gælder desuden: En ændring af bankforbindelsen bekræftes via en anden kanal, fx telefonisk.

Tabellen er til orientering og er ikke juridisk rådgivning. Vurderingen af risikoen påhviler den dataansvarlige og bør dokumenteres. Her hjælper en kort prøvelse: Hvad ville være den værst tænkelige realistiske skade for de registrerede? Hvor sandsynlig er den? Hvilken foranstaltning sænker den mærkbart?

Konklusion

Transportkryptering er et mindstekrav og ved normal risiko efter DSK og retspraksis som regel tilstrækkelig, hvis den er sat konsekvent op og efter det aktuelle tekniske niveau. Dertil hører TLS 1.2 eller helst 1.3, implicit TLS i mailprogrammet samt MTA-STS eller DANE på serversiden. Ved høj risiko forventes ende-til-ende eller en tilsvarende løsning.

E-mailkryptering forbliver et emne med afvejninger. Nøgleadministration er besværlig, portaler er en pragmatisk mellemvej, og mod svindel hjælper SPF, DKIM, DMARC og en anden kanal ved betalingsoplysninger mindst lige så meget som kryptografi.