E-Mail ist eines der ältesten produktiven Internet-Protokolle — und eines, das nicht für Sicherheit gebaut wurde. Verschlüsselung kam erst Jahrzehnte später dazu, als zusätzliche Schicht über einem im Kern offenen Protokoll. Wer E-Mail im Alltag verstehen will, sollte den Unterschied zwischen Transport-Verschlüsselung, Absender-Authentizität und Inhalts-Verschlüsselung kennen — und wo das System strukturell limitiert bleibt. Dieser Artikel ordnet die Schichten und legt die Sprache für die folgenden Artikel.

01 · Abschnitt

Wie E-Mail historisch entstand

SMTP (Simple Mail Transfer Protocol) wurde 1982 von Jonathan Postel als RFC 821 spezifiziert — in einer Zeit, in der das Internet 200 vernetzte Universitäts-Hosts hatte, sich alle Teilnehmer:innen persönlich kannten und Verschlüsselung weder verfügbar noch nötig schien. Die Konzept-Entscheidungen aus dieser Zeit prägen E-Mail bis heute:

  • Klartext-Protokoll. Mail-Inhalte wurden unverschlüsselt zwischen Servern übertragen.
  • Frei wählbarer Absender. Wer eine Mail verschickte, konnte angeben, wer sie verschickt hat — kein eingebauter Authentizitäts-Check.
  • Store-and-Forward zwischen mehreren Servern. Eine Mail von Hamburg nach Berlin lief oft über mehrere Hops; an jedem Hop war sie lesbar.
  • Globale Adressierung über DNS. MX-Records im DNS leiten die Mail zum Empfangs-Server der Empfänger-Domain.

Dieser Aufbau ist brillant in der Verfügbarkeit — E-Mail funktioniert immer noch, wenn ein Provider down ist, der Mail-Server kommt aus dem Cache zurück, der Absender kann zwischenzeitlich anders heißen. Dieselbe Offenheit ist heute die Wurzel aller E-Mail-Sicherheits-Themen.

Sicherheit wurde nachgerüstet — in mehreren Schichten:

  • Transport-Verschlüsselung (TLS für SMTP) seit den 1990ern.
  • Absender-Authentizität (SPF, DKIM, DMARC) ab den 2000ern.
  • Inhalts-Verschlüsselung (PGP, S/MIME) optional seit den 1990ern, aber nie Mainstream.
02 · Abschnitt

TLS für den Transport

Wenn dein Mail-Client eine Mail abschickt, baut er mehrere TLS-Verbindungen auf — eine pro Hop:

  1. Mail-Client zum Submission-Server (deinem Provider) — TLS auf Port 587 oder 465, immer Standard.
  2. Submission-Server zum Empfangs-Server der Ziel-Domain — TLS auf Port 25, opportunistisch: wenn beide Seiten TLS unterstützen, läuft die Übertragung verschlüsselt; sonst klartext.
  3. Empfangs-Server bis zur Mail-App des Empfängers — TLS auf IMAP/POP3, Standard.

Wichtig: Hop 2 ist der Schwachpunkt. Opportunistisches TLS heißt, dass ein Server-zu-Server-Hop ohne TLS funktioniert, wenn die Gegenseite es nicht anbietet — und ein Angreifer dazwischen kann das aktiv unterbinden (Downgrade-Angriff).

Drei Ergänzungen schließen die Lücke:

  • MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461). Mail-Server publishen über DNS und HTTPS, dass sie immer TLS verlangen. Downgrade-Angriffe werden erkennbar.
  • DANE/TLSA (DNS-based Authentication of Named Entities). Veröffentlicht Zertifikats-Hashes per DNSSEC — Empfangs-Server prüft, dass das TLS-Zertifikat zum hinterlegten Hash passt.
  • DNSSEC als Grundlage für DANE.

Stand 2026: die meisten großen Provider (Google, Microsoft, Apple, Posteo, Mailbox.org, Proton) setzen MTA-STS oder DANE ein. Kleinere und alte Server-Konfigurationen oft nicht. Wer testen will: checktls.com oder hardenize.com.

Praktische Konsequenz für Nutzer:innen: auf reinen Transport-TLS verlassen ist eine Wette darauf, dass beide Server-Seiten ordentlich konfiguriert sind. Für sensible Inhalte ist Ende-zu-Ende-Verschlüsselung (PGP / S/MIME) die robustere Antwort — siehe pgp-und-s-mime.

03 · Abschnitt

SPF: wer darf für meine Domain Mails verschicken?

SPF (Sender Policy Framework, RFC 7208) löst eine bestimmte Frage: „Welche IP-Adressen sind autorisiert, im Namen einer Domain Mails zu versenden?"

Mechanik:

  • Domain-Inhaber publiziert einen SPF-Record im DNS (TXT-Record), z. B.: v=spf1 include:_spf.google.com include:mailgun.org ~all
  • Empfangs-Server prüft beim Eingang: kommt die Mail von einer im SPF-Record gelisteten IP?
  • Ist die Antwort „nein", entscheidet die SPF-Policy:
    • +all — alles erlauben (faktisch SPF aus).
    • ~all — soft fail (Mail durchlassen, aber markieren).
    • -all — hard fail (Mail ablehnen).

SPF allein hat Grenzen:

  • Forwarding bricht es. Wenn eine Mail über einen Mail-Server weitergeleitet wird, kommt die Mail aus einer IP, die nicht im SPF des ursprünglichen Absenders steht.
  • Nur die Envelope-Adresse wird geprüft, nicht der sichtbare From:-Header. Display-Name-Spoofing wird nicht gefangen.

Trotzdem: ein gut gesetzter SPF-Record blockt einen Großteil simpler Massen-Phishing-Angriffe.

04 · Abschnitt

DKIM: kryptographische Signatur

DKIM (DomainKeys Identified Mail, RFC 6376) löst eine andere Frage: „Wurde die Mail unterwegs manipuliert, und stammt sie kryptographisch nachweisbar vom angegebenen Absender?"

Mechanik:

  • Beim Versenden signiert der Mail-Server den Mail-Inhalt (Header + Body, in definierter Form) mit einem privaten Schlüssel.
  • Die Signatur landet als DKIM-Signature:-Header in der Mail.
  • Der Public Key liegt im DNS unter <selector>._domainkey.<domain> als TXT-Record.
  • Der Empfangs-Server holt sich den Public Key, verifiziert die Signatur — passt sie, ist die Mail authentisch und unverändert.

DKIM schließt zwei Lücken von SPF:

  • Forwarding-resistent. Die Signatur reist mit der Mail; sie funktioniert auch nach Weiterleitungen.
  • Manipulations-Erkennung. Wenn jemand unterwegs Header oder Body ändert, ist die Signatur ungültig.

Was DKIM nicht löst:

  • Es signiert nur, was beim Senden im Signatur-Algorithmus enthalten war — nicht alle Header.
  • Ein Angreifer mit Zugriff auf den DNS oder den DKIM-Schlüssel umgeht es.
05 · Abschnitt

DMARC: die Policy-Klammer

DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) führt SPF und DKIM in einer Policy zusammen:

  • Domain-Inhaber publiziert einen DMARC-Record im DNS (TXT auf _dmarc.<domain>).
  • Empfangs-Server prüft: sind SPF und/oder DKIM bestanden? Und stimmt der dort geprüfte Domain-Name mit dem sichtbaren From:-Header überein (alignment)?
  • Wenn ja: durchlassen.
  • Wenn nein: gemäß Policy handeln.

Drei Policy-Werte:

  • p=none — nur beobachten und Berichte sammeln, nichts ablehnen.
  • p=quarantine — verdächtige Mails in Spam-Ordner.
  • p=reject — fehlerhafte Mails komplett ablehnen.

Plus Reporting: DMARC kann konfiguriert werden, dass täglich aggregierte Berichte über die Authentizität-Prüfungen an eine vorgegebene Mail-Adresse gehen — sehr nützlich für Domain-Inhaber, um Spoofing-Versuche und eigene Mis-Konfigurationen zu erkennen.

Stand 2026:

  • Microsoft, Google, Yahoo verlangen seit 2024 von Bulk-Sendern (>5 000 Mails/Tag) funktionierendes DMARC. Das hat in der Industrie eine breite SPF/DKIM/DMARC-Welle ausgelöst.
  • Banken, Behörden, große Konzerne haben p=reject als Standard.
  • Mittelstands- und Privat-Domains stehen oft noch auf p=none oder gar nicht — was Spoofing erlaubt.

Aus Nutzer-Sicht ist DMARC der Grund, warum viele klassische Banken-Spoofs heute weniger funktionieren als noch vor zehn Jahren. Mail von info@deinebank.de, die nicht vom echten Bank-Server kommt, wird heute meistens vom Empfangs-Server abgelehnt.

06 · Abschnitt

Was Mail-Provider im Klartext sehen

Ein Punkt, der oft übersehen wird: deine Mails liegen bei deinem Anbieter im Klartext (oder mit serverseitiger Verschlüsselung, zu der der Anbieter den Schlüssel hat). Wenn du nicht aktiv Inhalts-Verschlüsselung (PGP / S/MIME) nutzt, sieht der Anbieter:

  • Alle Inhalte deiner Mails (Body und Header).
  • Wer dir wann was geschickt hat.
  • Mail-Anhänge.
  • Adressbuch und Kontakte (oft serverseitig gespeichert).
  • Sortierungs- und Filter-Regeln.

Was bedeutet das?

  • Bei Gmail / Outlook: Inhalte werden auf den Anbieter-Servern verarbeitet. Google hat 2017 öffentlich erklärt, Inhalte nicht mehr für Werbe-Targeting zu nutzen — die infrastrukturelle Sichtbarkeit besteht aber weiter.
  • Bei Apple iCloud Mail: ähnlich; mit Advanced Data Protection ist die Verschlüsselung tiefer, aber Mail selbst ist davon ausgeklammert.
  • Bei Mailbox.org / Posteo / Proton Mail / Tutanota: deutlich datenschutz-freundlicher, manche bieten Spam-Filterung mit eigenem Schlüssel oder clientseitige Verschlüsselung zwischen eigenen Nutzer:innen.
  • Bei eigenem Mail-Server: du siehst alles, aber dein Provider sieht das auch (Hosting-Anbieter, ISP).

Rechtlich:

  • Innerhalb der EU greift die DSGVO + ePrivacy-Richtlinie. Provider haben Vertraulichkeits-Pflichten.
  • Strafverfolgung kann mit gerichtlicher Anordnung Mail-Inhalte anfordern (TKG, StPO).
  • Bei US-Providern (Google, Microsoft, Apple) kommt der CLOUD Act dazu — US-Behörden können auch Daten in europäischen Rechenzentren anfordern. Die Schrems-II-Entscheidung des EuGH (2020) zeigt die rechtliche Spannung.

Wer das nicht möchte: PGP / S/MIME für sensible Inhalte (Aufwand) oder andere Kommunikations-Kanäle für wirklich vertrauliche Inhalte (Signal, persönliches Gespräch). Vertieft in sichere-messenger.

07 · Abschnitt

Was du als Nutzer:in daraus ableitest

Pragmatische Reflexe:

  • Vertraue auf Transport-TLS für unkritische Mail. Wenn du in einem seriösen Provider Mail nutzt, ist Hop-zu-Hop-TLS heute Standard. Café-WLAN-Mitleser sieht den Mail-Verkehr nicht.
  • Verstehe, dass Inhalte beim Anbieter sichtbar bleiben. Bei wirklich sensiblen Inhalten (Gesundheits-Daten, juristische Korrespondenz, Quellen-Material) ist E2E-Verschlüsselung Pflicht oder anderer Kanal.
  • Achte auf Authentizitäts-Hinweise. Mail-Clients zeigen bei DMARC-Fehlern oft Warnungen oder „Diese Mail kommt von außerhalb"-Banner. Nicht reflexhaft wegklicken.
  • Eigene Domain mit korrektem SPF/DKIM/DMARC. Wer eine eigene Domain hat, sollte alle drei Records ordentlich konfigurieren — verhindert, dass die Domain für Spoofing genutzt wird.
  • Spam-Ordner ist nicht Müll. Manche legitime Mails landen dort wegen DMARC-Konfiguration des Absenders. Wer auf Mail wartet: nachsehen.

Was du nicht annehmen solltest:

  • „Meine Mails sind sicher, weil HTTPS". HTTPS ist nur zwischen deinem Browser und dem Webmail-Server. Hop 2 (zwischen den Mail-Servern) und Hop 3 (zum Empfänger-Client) sind separate Themen.
  • „Mit gutem Anbieter ist alles sicher". Provider haben weiter Sichtbarkeit. Sicherheit gegen den Anbieter selbst geht nur über E2E-Verschlüsselung.
08 · Abschnitt

Interessantes

SMTP-Sicherheits-Workshop seit Jahren

Die IETF arbeitet seit Jahrzehnten an Sicherheits-Verbesserungen für E-Mail. Ergebnisse: SPF (2014 RFC), DKIM (2011 RFC), DMARC (2015 RFC), MTA-STS (2018 RFC), ARC (2019 RFC für Forwarding-Probleme). Jede Schicht ist eine pragmatische Antwort auf eine konkrete Lücke. Vollständig sicher ist E-Mail noch immer nicht — die Protokoll-Architektur ist ein Kompromiss.

Authentication-Results-Header

Empfangs-Server fügen einen Authentication-Results:-Header an, der die Ergebnisse der SPF/DKIM/DMARC-Prüfungen zeigt — oft auf einer Zeile. Wer Mail-Header lesen kann, sieht hier sehr direkt, ob eine Mail authentisch ist. Vertieft im Artikel Mail-Header und Spoofing.

BIMI: das Markenzeichen-Programm

BIMI (Brand Indicators for Message Identification) ist eine relativ neue Ergänzung. Domains mit funktionierendem DMARC-p=reject und einem im DNS hinterlegten Logo bekommen in Gmail und einigen anderen Anbietern ein Marken-Logo neben der Mail angezeigt. Privatsphäre-Wirkung gering, aber Anti-Spoofing-Anreiz für Marken — und für Nutzer:innen ein zusätzliches Authentizitäts-Signal.

Forward Secrecy fehlt im klassischen SMTP-TLS

Klassisches SMTP-TLS nutzt oft keine Perfect Forward Secrecy. Wer den TLS-Schlüssel später bekommt (gerichtliche Anordnung, Schlüssel-Diebstahl), kann aufgezeichneten Mail-Verkehr rückwirkend entschlüsseln. Moderne Konfigurationen (mit ECDHE) lösen das, sind aber nicht überall Default. Für sensible Inhalte: zusätzliche E2E-Schicht.

Microsoft, Google, Yahoo Bulk-Sender-Anforderungen 2024

Seit Februar 2024 verlangen die drei großen Mail-Anbieter von Massen-Sendern (über 5 000 Mails/Tag) ordentliche DMARC-Konfiguration, einfache Unsubscribe-Mechanismen, und niedrige Spam-Beschwerde-Raten. Das hat eine Welle von SPF/DKIM/DMARC-Implementierungen ausgelöst — viele Mittelständler haben erst dadurch ihre Mail-Authentizität nachgerüstet.

DANE/TLSA in der Praxis

DANE ist technisch eleganter als MTA-STS, hat aber DNSSEC als Voraussetzung — und DNSSEC ist nur teils ausgerollt. In Deutschland nutzen Posteo, Mailbox.org, Strato, viele kleine Anbieter DANE. Die US-Großanbieter (Google, Microsoft, Apple) setzen auf MTA-STS statt DANE. Beide funktionieren — DANE strenger, MTA-STS einfacher zu betreiben.

Mail-Adresse ist ein quasi-Identifier

Auch wenn du keinen Klar-Account hast: deine Mail-Adresse ist über die meisten Online-Dienste der gemeinsame Identifier. Datenleck-Datenbanken verknüpfen alles, was unter einer Mail-Adresse aufgetaucht ist. Wer für unterschiedliche Aktivitäten unterschiedliche Mail-Adressen nutzt (Aliase, siehe nächster Artikel), reduziert dieses Risiko erheblich.

Weiterführende Ressourcen

Externe Quellen

/ Weiter

Zurück zu E-Mail & Messaging

Zur Übersicht