Zum Hauptinhalt springen

STARTTLS, SSL/TLS und SMTP: welche Verschlüsselung für deine E-Mails?

Von CaptainDNS
Veröffentlicht am 17. Februar 2026

SMTP-Verschlüsselung: STARTTLS, TLS 1.2, TLS 1.3, DANE und MTA-STS
TL;DR
  • SSL ist seit 2015 veraltet (RFC 7568): der korrekte Begriff ist TLS. STARTTLS ist kein Verschlüsselungsprotokoll, sondern ein Befehl, der TLS auf einer bestehenden Verbindung aktiviert
  • STARTTLS ist anfällig für Downgrade-Angriffe: ein Netzwerk-Angreifer kann die STARTTLS-Ankündigung entfernen und die Kommunikation im Klartext erzwingen. MTA-STS und DANE beheben diese Schwachstelle
  • TLS 1.3 ist der empfohlene Standard für SMTP in 2026: schnellerer Handshake (1-RTT), sicherere Cipher Suites, Forward Secrecy obligatorisch
  • Konfiguriere deinen MTA mit obligatorischem TLS für ausgehende Verbindungen (smtp_tls_security_level = encrypt bei Postfix) und setze MTA-STS ein, um eingehende E-Mails zu schützen

Werden deine E-Mails wirklich verschlüsselt übertragen? 2024 berichtet Google, dass über 95 % der von Gmail empfangenen E-Mails TLS verwenden. Aber diese Zahl verbirgt eine differenziertere Realität: STARTTLS ist standardmäßig opportunistisch, Downgrade-Angriffe sind dokumentiert, und viele Server akzeptieren noch TLS 1.0 oder schwache Cipher Suites.

Dieser Leitfaden geht über den einfachen Vergleich STARTTLS vs. Implicit TLS hinaus. Er erklärt, wie die TLS-Verschlüsselung auf Handshake-Ebene funktioniert, warum TLS 1.3 für SMTP einen Wendepunkt darstellt, welche Schwachstellen Angreifer ausnutzen und wie du eine robuste Verschlüsselung auf den gängigsten MTAs (Postfix, Exim, Exchange) konfigurierst. Ob du einen Mailserver verwaltest oder eine E-Mail-Infrastruktur auditierst: du wirst mit konkreten Handlungsempfehlungen nach Hause gehen.

SSL, TLS, STARTTLS: die Terminologie klären

Die Begriffe SSL, TLS und STARTTLS werden in der E-Mail-Branche austauschbar verwendet. Das führt zu erheblicher Verwirrung, denn sie bezeichnen grundlegend verschiedene Dinge.

SSL ist tot, TLS hat es ersetzt

SSL (Secure Sockets Layer) ist der Vorgänger von TLS. Die letzte Version, SSL 3.0, wurde 1996 veröffentlicht und 2015 durch RFC 7568 offiziell aufgegeben, aufgrund kritischer Schwachstellen (POODLE, BEAST). Wenn ein E-Mail-Anbieter 2026 "SSL" erwähnt, meint er in Wirklichkeit TLS.

ProtokollJahrStatus 2026
SSL 2.01995Verboten (RFC 6176)
SSL 3.01996Verboten (RFC 7568)
TLS 1.01999Veraltet (RFC 8996)
TLS 1.12006Veraltet (RFC 8996)
TLS 1.22008Akzeptabel
TLS 1.32018Empfohlen

In der Praxis: Wenn dein SMTP-Server noch SSL 3.0 oder TLS 1.0 akzeptiert, ist er anfällig für bekannte Angriffe. Deaktiviere diese Protokolle.

STARTTLS ist kein Verschlüsselungsprotokoll

STARTTLS ist ein SMTP-Befehl (definiert in RFC 3207), der den Server auffordert, eine Klartextverbindung auf eine TLS-verschlüsselte Verbindung umzuschalten. Es ist weder SSL noch TLS, noch ein eigenständiges Protokoll: es ist ein Upgrade-Mechanismus für eine bestehende Verbindung.

Die Verwirrung kommt vom Namen: "STARTTLS" enthält "TLS", gibt aber nicht an, welche TLS-Version verwendet wird. Die ausgehandelte Version hängt von der Konfiguration des Clients und des Servers ab.

Implicit TLS vs. Explicit TLS (STARTTLS)

Es gibt zwei Möglichkeiten, TLS auf einer SMTP-Verbindung herzustellen:

MethodeTypischer PortFunktionsweiseWeb-Analogie
Explicit TLS (STARTTLS)25, 587Klartextverbindung, dann Upgrade per STARTTLS-BefehlHTTP dann Umleitung auf HTTPS
Implicit TLS465TLS-Verbindung ab dem ersten ByteNatives HTTPS auf Port 443

Bei Explicit TLS gibt es immer einen Moment, in dem die Kommunikation im Klartext erfolgt (die EHLO-Phase vor STARTTLS). Bei Implicit TLS findet nie eine Klartextkommunikation statt. Dieser Unterschied hat erhebliche Auswirkungen auf die Sicherheit.

Wie funktioniert die SMTP-Verschlüsselung in der Praxis?

Ob du STARTTLS oder Implicit TLS verwendest, die Verschlüsselung basiert auf einem TLS-Handshake. Dieser Aushandlungsprozess bestimmt die Protokollversion, die verwendete Cipher Suite und den Schlüsselaustausch.

Der TLS-Handshake Schritt für Schritt

Hier ist, was passiert, wenn ein SMTP-Server TLS aushandelt (nach dem STARTTLS-Befehl oder direkt bei der Verbindung auf Port 465):

Mit TLS 1.2 (4 Austausche, 2-RTT):

  1. ClientHello: Der Client sendet die unterstützten TLS-Versionen und Cipher Suites
  2. ServerHello: Der Server wählt die TLS-Version und die Cipher Suite, sendet sein Zertifikat
  3. Schlüsselaustausch: Der Client generiert ein Pre-Master-Secret und verschlüsselt es mit dem öffentlichen Schlüssel des Servers
  4. Finished: Beide Seiten bestätigen, dass der Kanal verschlüsselt ist

Mit TLS 1.3 (2 Austausche, 1-RTT):

  1. ClientHello: Der Client sendet die TLS-Versionen, Cipher Suites und seine Diffie-Hellman-Schlüssel
  2. ServerHello + Finished: Der Server wählt die Parameter, sendet sein Zertifikat und bestätigt die Verschlüsselung

TLS 1.3 fasst Schritte zusammen: der Handshake geht von 2-RTT auf 1-RTT, was die Verbindungsaufbau-Latenz reduziert. Für einen MX-Server, der Tausende von Verbindungen pro Stunde verarbeitet, ist diese Optimierung signifikant.

Vergleich des TLS 1.2 vs. TLS 1.3 Handshakes bei einer SMTP-Verbindung

TLS 1.2 vs. TLS 1.3: welche Unterschiede für SMTP?

KriteriumTLS 1.2TLS 1.3
Handshake2-RTT1-RTT
Forward SecrecyOptional (abhängig vom Cipher)Obligatorisch
Cipher Suites37 Suites (darunter schwache)5 Suites (alle robust)
KompressionUnterstützt (anfällig für CRIME)Entfernt
RenegotiationUnterstützt (Angriffsvektor)Entfernt
0-RTT ResumptionNeinJa (mit Vorsichtsmaßnahmen)
RFCRFC 5246RFC 8446

Der Kernpunkt für SMTP: TLS 1.3 eliminiert schwache Cipher Suites und macht Forward Secrecy obligatorisch. Bei TLS 1.2 kann ein Server RSA ohne Diffie-Hellman-Austausch aushandeln, was bedeutet, dass ein Angreifer, der den privaten Schlüssel des Servers erlangt, alle vergangenen Kommunikationen entschlüsseln kann. Bei TLS 1.3 verwendet jede Sitzung ephemere Schlüssel: selbst wenn der private Schlüssel kompromittiert wird, bleiben vergangene Sitzungen geschützt.

Empfohlene Cipher Suites für 2026

Für SMTP konfiguriere deinen Server mit diesen Cipher Suites, in dieser Reihenfolge:

TLS 1.3 (keine Konfiguration nötig, alle 5 Suites sind sicher):

  • TLS_AES_256_GCM_SHA384
  • TLS_CHACHA20_POLY1305_SHA256
  • TLS_AES_128_GCM_SHA256

TLS 1.2 (auf Suites mit Forward Secrecy beschränken):

  • ECDHE-ECDSA-AES256-GCM-SHA384
  • ECDHE-RSA-AES256-GCM-SHA384
  • ECDHE-ECDSA-CHACHA20-POLY1305
  • ECDHE-RSA-CHACHA20-POLY1305
  • ECDHE-ECDSA-AES128-GCM-SHA256
  • ECDHE-RSA-AES128-GCM-SHA256

Zu verbietende Cipher Suites: alles, was RC4, DES, 3DES, MD5, NULL, EXPORT oder RSA ohne ECDHE/DHE enthält (keine Forward Secrecy).

Die Schwachstellen von STARTTLS und wie du dich schützt

STARTTLS ist der am weitesten verbreitete Verschlüsselungsmechanismus für SMTP-Verbindungen zwischen Servern (Port 25). Aber sein opportunistisches Design führt zu ausnutzbaren Schwachstellen.

Der STARTTLS-Downgrade-Angriff

Wenn ein SMTP-Client sich mit einem Server auf Port 25 verbindet, sendet er EHLO und wartet auf die Liste der Erweiterungen. Wenn der Server 250-STARTTLS ankündigt, weiß der Client, dass er auf TLS umschalten kann. Das Problem: dieser Austausch findet im Klartext statt.

Ein Angreifer, der sich zwischen Client und Server positioniert (Man-in-the-Middle), kann die EHLO-Antwort modifizieren und die Zeile 250-STARTTLS entfernen. Der Client, der die STARTTLS-Erweiterung nicht sieht, kommuniziert weiter im Klartext. Der Angreifer kann dann alle E-Mails bei der Übertragung lesen und modifizieren.

# Legitime Antwort des Servers
250-mx1.captaindns.com
250-STARTTLS        <-- Der Angreifer entfernt diese Zeile
250 OK

# Was der Client nach dem Angriff sieht
250-mx1.captaindns.com
250 OK              <-- Kein STARTTLS, Klartextverbindung

Der STRIPTLS-Angriff

STRIPTLS ist eine ausgeklügeltere Variante. Anstatt die STARTTLS-Ankündigung des Servers zu entfernen, fängt der Angreifer den STARTTLS-Befehl des Clients ab und gibt einen falschen Fehler zurück (z.B. 454 TLS not available). Der Client gibt TLS auf und kommuniziert weiter im Klartext, in der Annahme eines temporären Problems.

Diese beiden Angriffe sind dokumentiert und wurden auf nationaler Ebene beobachtet. 2014 zeigten Forscher, dass mehrere Länder STRIPTLS auf internationalen SMTP-Verbindungen praktizierten.

MTA-STS: TLS für eingehende E-Mails erzwingen

MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) ist die Antwort der IETF auf Downgrade-Angriffe auf SMTP. Das Prinzip: die Empfänger-Domain veröffentlicht eine Richtlinie, die besagt: "Alle Server, die mir E-Mails senden, müssen TLS mit einem gültigen Zertifikat verwenden".

So funktioniert es:

  1. Die Domain captaindns.com veröffentlicht einen DNS-TXT-Eintrag _mta-sts.captaindns.com mit einer Richtlinien-ID
  2. Die Domain hostet eine Datei https://mta-sts.captaindns.com/.well-known/mta-sts.txt mit der Richtlinie
  3. Der sendende Server konsultiert diese Richtlinie bevor er sich mit dem MX verbindet
  4. Wenn die Richtlinie im Modus enforce steht, verweigert der sendende Server die Zustellung im Klartext
# DNS-Eintrag
_mta-sts.captaindns.com.  TXT  "v=STSv1; id=20260217"

# Richtliniendatei (HTTPS obligatorisch)
version: STSv1
mode: enforce
mx: mx1.captaindns.com
mx: mx2.captaindns.com
max_age: 604800

Einschränkung: MTA-STS ist auf HTTPS angewiesen, um die Richtlinie zu verteilen. Wenn der Angreifer den HTTPS-Zugriff auf die Richtliniendatei blockiert, kann der sendende Server die Richtlinie nicht abrufen und fällt möglicherweise auf Klartext zurück. Das ist ein TOFU-Problem (Trust On First Use): die Richtlinie ist erst nach dem ersten erfolgreichen Abruf sicher.

DANE (TLSA): das Zertifikat über DNS authentifizieren

DANE (DNS-based Authentication of Named Entities, RFC 7672 für SMTP) löst das Problem anders. Anstatt eine Richtlinie über HTTPS zu veröffentlichen, veröffentlicht die Domain einen TLSA-Eintrag im DNS, der den Fingerabdruck des erwarteten TLS-Zertifikats enthält.

# TLSA-Eintrag für den MX (Port 25)
_25._tcp.mx1.captaindns.com.  TLSA  3 1 1 a0b1c2d3e4f5...

Vorteile von DANE:

  • Keine Abhängigkeit von HTTPS (im Gegensatz zu MTA-STS)
  • Authentifiziert das Server-Zertifikat über DNSSEC (nicht nur "TLS obligatorisch", sondern "TLS mit diesem Zertifikat")
  • Schützt gegen Downgrade-Angriffe und gefälschte Zertifikate

Voraussetzung: DANE erfordert DNSSEC auf der Domain. Ohne DNSSEC sind TLSA-Einträge nicht authentifiziert und DANE ist wirkungslos. Das ist die Hauptbremse bei der Verbreitung: nur ca. 5 % der Domains nutzen DNSSEC im Jahr 2026.

MechanismusSchützt vor DowngradeAuthentifiziert das ZertifikatVoraussetzung
STARTTLS alleinNeinNeinKeine
MTA-STSJa (nach erstem Fetch)Ja (öffentliche CA)HTTPS + DNS TXT
DANEJaJa (exakter Fingerabdruck)DNSSEC + DNS TLSA
MTA-STS + DANEJa (doppelter Schutz)Ja (CA + Fingerabdruck)DNSSEC + HTTPS

Schutzmechanismen gegen STARTTLS-Downgrade-Angriffe

TLS-Verschlüsselung auf deinem SMTP-Server konfigurieren

Die Theorie ist klar. Kommen wir zur konkreten Konfiguration auf den drei am häufigsten eingesetzten MTAs.

Postfix: TLS aktivieren und härten

Postfix ist der am weitesten verbreitete MTA auf Linux-Servern. Die TLS-Konfiguration erfolgt in main.cf.

Eingehendes TLS (Server, E-Mail-Empfang):

# TLS für eingehende Verbindungen aktivieren
smtpd_tls_cert_file = /etc/letsencrypt/live/mx1.captaindns.com/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/mx1.captaindns.com/privkey.pem
smtpd_tls_security_level = may

# Mindestens TLS 1.2 erzwingen
smtpd_tls_mandatory_protocols = >=TLSv1.2
smtpd_tls_protocols = >=TLSv1.2

# Cipher Suites (TLS 1.2)
smtpd_tls_mandatory_ciphers = high
smtpd_tls_exclude_ciphers = aNULL, MD5, DES, 3DES, RC4

Ausgehendes TLS (Client, E-Mail-Versand):

# TLS für ausgehende Verbindungen aktivieren
smtp_tls_security_level = may
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

# Mindestens TLS 1.2 für ausgehende Verbindungen erzwingen
smtp_tls_mandatory_protocols = >=TLSv1.2
smtp_tls_protocols = >=TLSv1.2

# TLS-Verbindungen protokollieren (nützlich für Audits)
smtp_tls_loglevel = 1

Weiter härten: Ersetze smtp_tls_security_level = may durch encrypt, um jede Klartextverbindung beim Versand abzulehnen. Achtung: Einige kleine Server haben kein TLS, deine E-Mails an diese Server werden blockiert. Verwende dane, wenn DNSSEC verfügbar ist.

Wert security_levelVerhalten
noneKein TLS (nicht empfohlen)
mayOpportunistisches TLS (Standard, akzeptiert Klartext)
encryptObligatorisches TLS (lehnt Klartext ab)
daneTLS + DANE-Verifizierung über DNSSEC
verifyTLS + Hostname-Verifizierung des Zertifikats

Exim: TLS-Konfiguration

Exim verwendet eine modulare Konfiguration. Die TLS-Direktiven befinden sich im Hauptblock.

# Zertifikat und Schlüssel
tls_certificate = /etc/letsencrypt/live/mx1.captaindns.com/fullchain.pem
tls_privatekey = /etc/letsencrypt/live/mx1.captaindns.com/privkey.pem

# STARTTLS ankündigen
tls_advertise_hosts = *

# Mindestens TLS 1.2 erzwingen
openssl_options = +no_sslv2 +no_sslv3 +no_tlsv1 +no_tlsv1_1

# TLS für ausgehende Verbindungen erzwingen (optional)
tls_require_ciphers = ECDHE-ECDSA-AES256-GCM-SHA384:\
  ECDHE-RSA-AES256-GCM-SHA384:\
  ECDHE-ECDSA-AES128-GCM-SHA256:\
  ECDHE-RSA-AES128-GCM-SHA256

Um die Konfiguration zu überprüfen: exim -bV zeigt die kompilierten TLS-Fähigkeiten an.

Microsoft Exchange: TLS erzwingen

Bei Exchange (2019+) erfolgt die TLS-Konfiguration über die Empfangs- und Sendeconnectoren.

Empfangsconnector (eingehende E-Mails):

# TLS auf dem Empfangsconnector erzwingen
Set-ReceiveConnector "Default Frontend" -RequireTLS $true

# Veraltete Protokolle deaktivieren (über Windows-Registry)
# HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
# SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1 deaktivieren

Sendeconnector (ausgehende E-Mails an einen bestimmten Partner):

# Sendeconnector mit obligatorischem TLS erstellen
New-SendConnector -Name "An captaindns.com (TLS)" `
  -AddressSpaces "captaindns.com" `
  -RequireTLS $true `
  -TlsAuthLevel DomainValidation

Hinweis: RequireTLS $true auf einem Sendeconnector bedeutet, dass Exchange den Versand im Klartext an dieses Ziel verweigert. Verwende es für Partner-Domains, die TLS unterstützen, nicht für einen Catch-All-Connector (Nachrichten würden blockiert).

Die Verschlüsselung deiner E-Mails überprüfen

TLS zu konfigurieren reicht nicht aus: du musst überprüfen, ob die Verschlüsselung tatsächlich funktioniert.

Über Gmail: Verschlüsselungsindikator

Gmail zeigt ein Schloss-Symbol im E-Mail-Header an. Ein graues Schloss bedeutet, dass die E-Mail per TLS übertragen wurde (Standard). Ein rotes Schloss mit Ausrufezeichen bedeutet, dass die E-Mail nicht verschlüsselt übertragen wurde.

Für die technischen Details klicke auf "Original anzeigen" in Gmail: der Received-Header enthält die verwendete TLS-Version und Cipher Suite.

Received: from mx1.captaindns.com (mx1.captaindns.com [203.0.113.10])
  by mx.google.com with ESMTPS id abc123
  (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384)

Per Kommandozeile: openssl s_client

Um die Verschlüsselung eines MX-Servers vom Terminal aus zu testen:

# Test STARTTLS auf Port 25
openssl s_client -connect mx1.captaindns.com:25 -starttls smtp \
  -servername mx1.captaindns.com 2>/dev/null | \
  grep -E "Protocol|Cipher|Verify"

# Erwartetes Ergebnis
Protocol  : TLSv1.3
Cipher    : TLS_AES_256_GCM_SHA384
Verify return code: 0 (ok)

Wenn Protocol TLSv1 oder TLSv1.1 anzeigt, verwendet dein Server ein veraltetes Protokoll. Wenn Verify return code ungleich 0 ist, hat das Zertifikat ein Problem.

Mit dem CaptainDNS-Tool

Der SMTP/MX Connectivity Tester von CaptainDNS testet automatisch alle MX-Einträge einer Domain und überprüft für jeden: die ausgehandelte TLS-Version, die Cipher Suite, die Zertifikatsgültigkeit (Ablauf, SAN, Vertrauenskette) und die STARTTLS-Unterstützung. Das Ergebnis enthält ein Scoring pro MX-Server mit eindeutigen Diagnosecodes.

🎯 Empfohlener Aktionsplan

  1. Auditiere deine aktuelle Konfiguration: Überprüfe die TLS-Version und die Cipher Suites jedes MX mit openssl s_client oder dem SMTP/MX Connectivity Tester
  2. Deaktiviere SSL 3.0, TLS 1.0 und TLS 1.1: Diese Protokolle sind veraltet (RFC 8996) und anfällig. TLS 1.2 ist das Minimum, TLS 1.3 wird empfohlen
  3. Schränke die Cipher Suites ein: Entferne RC4, DES, 3DES, MD5 und Suites ohne Forward Secrecy (ECDHE/DHE obligatorisch)
  4. Setze MTA-STS ein: Veröffentliche eine enforce-Richtlinie, um deine eingehenden E-Mails vor Downgrade-Angriffen zu schützen
  5. Aktiviere DANE, wenn DNSSEC verfügbar ist: Veröffentliche TLSA-Einträge, um die Zertifikate deiner MX-Server über DNS zu authentifizieren

FAQ

Was ist der Unterschied zwischen STARTTLS und SSL/TLS?

SSL und TLS sind Verschlüsselungsprotokolle (SSL ist der veraltete Vorgänger von TLS). STARTTLS ist weder SSL noch TLS: es ist ein SMTP-Befehl, der die TLS-Verschlüsselung auf einer zunächst unverschlüsselten Verbindung aktiviert. Nach STARTTLS nutzt die Verbindung TLS (1.2 oder 1.3), aber die anfängliche Phase vor dem Befehl bleibt anfällig für Downgrade-Angriffe.

Sollte man noch SSL für SMTP verwenden?

Nein. SSL 2.0 und 3.0 sind durch die RFCs 6176 und 7568 verboten. TLS 1.0 und 1.1 sind seit RFC 8996 veraltet. Jeder SMTP-Server muss mindestens TLS 1.2 verwenden, vorzugsweise TLS 1.3. Wenn ein Anbieter "SSL" erwähnt, meint er in Wirklichkeit TLS.

Wie erzwingt man TLS-Verschlüsselung für ausgehende E-Mails?

Bei Postfix konfiguriere smtp_tls_security_level = encrypt in main.cf, um jede Klartextverbindung beim Versand abzulehnen. Bei Exchange aktiviere RequireTLS auf dem Sendeconnector. Achtung: E-Mails an Server ohne TLS werden blockiert. Verwende den Modus dane oder may, wenn du an alle Empfänger zustellen musst.

Was ist DANE und wie sichert es SMTP ab?

DANE (DNS-based Authentication of Named Entities) ermöglicht es, den Fingerabdruck des TLS-Zertifikats eines MX-Servers in einem DNS-TLSA-Eintrag zu veröffentlichen. Der sendende Server überprüft, ob das präsentierte Zertifikat mit dem veröffentlichten Fingerabdruck übereinstimmt, was Angriffe mit gefälschten Zertifikaten und Downgrades verhindert. DANE erfordert DNSSEC, um die Authentizität der DNS-Einträge zu gewährleisten.

Wie überprüfe ich, ob meine E-Mails per TLS übertragen werden?

Drei Methoden: (1) Klicke in Gmail auf "Original anzeigen" und suche die Received-Header mit der TLS-Version, (2) verwende per Kommandozeile openssl s_client -connect mx:25 -starttls smtp, um die Aushandlung zu testen, (3) nutze den SMTP/MX Connectivity Tester von CaptainDNS für eine automatisierte Diagnose aller deiner MX-Server.

Welche Cipher Suites sollte man 2026 für SMTP verwenden?

Für TLS 1.3: alle Suites sind sicher (AES-256-GCM, AES-128-GCM, CHACHA20-POLY1305). Für TLS 1.2: verwende ausschließlich ECDHE-Suites mit AES-GCM (Forward Secrecy obligatorisch). Verbanne RC4, DES, 3DES, MD5, NULL-Suites, EXPORT-Suites und RSA-Austausch ohne ECDHE/DHE.

Was ist der Unterschied zwischen MTA-STS und DANE?

MTA-STS veröffentlicht eine TLS-Richtlinie über HTTPS (Datei .well-known/mta-sts.txt), die angibt, dass die Domain TLS erfordert. DANE veröffentlicht den Fingerabdruck des Zertifikats über einen DNS-TLSA-Eintrag, gesichert durch DNSSEC. MTA-STS ist einfacher zu implementieren (kein DNSSEC nötig), leidet aber unter dem TOFU-Problem (Trust On First Use). DANE bietet eine stärkere Authentifizierung, erfordert aber DNSSEC. Beide können gleichzeitig eingesetzt werden.

Vergleichstabellen herunterladen

Assistenten können die JSON- oder CSV-Exporte unten nutzen, um die Kennzahlen weiterzugeben.

📖 Glossar

  • TLS (Transport Layer Security): Protokoll zur Verschlüsselung der Netzwerkkommunikation. Nachfolger von SSL, aktuelle Versionen: TLS 1.2 und TLS 1.3 (RFC 8446).
  • STARTTLS: SMTP-Befehl (RFC 3207), der das Upgrade einer Klartextverbindung auf TLS anfordert. Kein eigenständiges Verschlüsselungsprotokoll.
  • Implicit TLS: Verbindungsmodus, bei dem TLS ab dem ersten Byte hergestellt wird, ohne Klartextphase. Verwendet auf Port 465 (SMTP) und Port 443 (HTTPS).
  • Forward Secrecy: Kryptografische Eigenschaft, die sicherstellt, dass die Kompromittierung eines privaten Schlüssels nicht das Entschlüsseln vergangener Sitzungen ermöglicht. Gewährleistet durch ECDHE/DHE-Schlüsselaustausch.
  • Cipher Suite: Kombination von Algorithmen für eine TLS-Sitzung: Schlüsselaustausch (ECDHE), Authentifizierung (RSA/ECDSA), Verschlüsselung (AES-GCM) und Hashing (SHA384).
  • DANE: DNS-based Authentication of Named Entities (RFC 7672 für SMTP). Ermöglicht die Authentifizierung des TLS-Zertifikats eines Servers über einen DNS-TLSA-Eintrag, gesichert durch DNSSEC.
  • MTA-STS: Mail Transfer Agent Strict Transport Security (RFC 8461). Über HTTPS veröffentlichte Richtlinie, die sendende Server zwingt, TLS mit einem gültigen Zertifikat zu verwenden.
  • Downgrade-Angriff: Netzwerkangriff, der eine Verbindung zur Nutzung eines weniger sicheren Protokolls zwingt, typischerweise durch Entfernen der STARTTLS-Ankündigung oder Manipulation der TLS-Aushandlung.
  • TOFU: Trust On First Use. Sicherheitsmodell, bei dem das Vertrauen bei der ersten Interaktion hergestellt wird. MTA-STS leidet unter diesem Problem: der erste Abruf der Richtlinie ist anfällig.

Überprüfe die TLS-Verschlüsselung deiner MX-Server: Nutze unseren SMTP/MX Connectivity Tester, um die TLS-Version, die Cipher Suites und die Zertifikatsgültigkeit jedes MX-Servers in wenigen Sekunden zu testen.

📚 Verwandte SMTP- und E-Mail-Konnektivitäts-Leitfäden

Quellen

Ähnliche Artikel