So testest du die SMTP-Konnektivität deiner MX-Server
Von CaptainDNS
Veröffentlicht am 17. Februar 2026
- Ein gültiger MX-Eintrag beweist nicht, dass dein Mailserver funktioniert: teste die TCP-Verbindung, das Banner, STARTTLS und das TLS-Zertifikat
- Verwende
telnetzur Prüfung der Konnektivität auf Port 25 und des SMTP-Banners, dannopenssl s_clientzur Inspektion von STARTTLS und Zertifikat - Häufige Probleme (Port 25 blockiert, abgelaufenes Zertifikat, falsch konfiguriertes STARTTLS) sind still: nur ein aktiver Test erkennt sie
- Automatisiere die Diagnose mit dem SMTP/MX Connectivity Tester von CaptainDNS, um alle deine MX in einer einzigen Abfrage zu testen
Deine SPF-, DKIM- und DMARC-Einträge sind korrekt konfiguriert. Deine Domain besteht alle DNS-Tests. Trotzdem kommen manche E-Mails nicht an oder werden ohne TLS-Verschlüsselung übertragen. Das Problem liegt nicht in der DNS-Konfiguration, sondern auf der Transportebene: der SMTP-Verbindung zwischen den Servern.
Diese Anleitung zeigt dir, wie du die SMTP-Konnektivität deiner MX-Server testest, von der DNS-Auflösung bis zur Inspektion des TLS-Zertifikats. Jeder Befehl ist reproduzierbar von einem Linux-, macOS- oder WSL-Terminal. Ob du ein Zustellproblem diagnostizierst oder die Sicherheit deiner E-Mail-Infrastruktur auditierst: du wirst genau wissen, was du prüfen musst und wie du die Ergebnisse interpretierst.
Warum die SMTP-Konnektivität deiner MX testen?
Die DNS-Konfiguration (MX-, SPF-, DKIM-, DMARC-Einträge) ist eine notwendige, aber keine hinreichende Bedingung. Drei Kategorien von Problemen entgehen klassischen DNS-Prüftools.
Die Zustellbarkeit hängt vom Transport ab
Wenn dein MX-Server auf Port 25 nicht erreichbar ist, erhalten die sendenden Server einen "connection timed out"-Fehler und versuchen es 24 bis 48 Stunden lang erneut, bevor sie aufgeben. Die Nachricht geht verloren, und der Absender erhält einen verspäteten Bounce. Diese Art von Ausfall ist von deiner Seite unsichtbar, solange du nicht aktiv testest.
TLS-Verschlüsselung ist nicht garantiert
2024 werden über 95 % der von Gmail empfangenen E-Mails über TLS übertragen (Google Transparency Report). Aber STARTTLS ist opportunistisch: wenn die Verhandlung stillschweigend fehlschlägt, läuft die Verbindung unverschlüsselt weiter. Ein abgelaufenes Zertifikat oder eine fehlerhafte TLS-Konfiguration kann die Sicherheit aller eingehenden Datenströme verschlechtern, ohne dass eine Warnung ausgelöst wird.
Ein Open Relay zerstört deine Reputation
Ein SMTP-Server, der E-Mails für beliebige Empfänger weiterleitet, ist ein Open Relay. Spammer nutzen ihn innerhalb weniger Stunden aus, und deine IP landet auf Blacklists (Spamhaus, Barracuda, SpamCop). Alle deine ausgehenden E-Mails werden dann abgelehnt.
Was ein vollständiger SMTP-Test prüft
Ein vollständiger SMTP-Konnektivitätstest deckt sieben Punkte ab, in dieser Reihenfolge.
| Schritt | Prüfung | Tool |
|---|---|---|
| 1 | DNS-MX-Auflösung | dig oder nslookup |
| 2 | TCP-Verbindung Port 25 | telnet |
| 3 | SMTP-Banner (220) | telnet |
| 4 | EHLO-Erweiterungen | telnet |
| 5 | STARTTLS und TLS-Version | openssl s_client |
| 6 | TLS-Zertifikat (Gültigkeit, Ablauf, SAN) | openssl s_client |
| 7 | Open-Relay-Test | telnet |
Jeder Schritt kann unabhängig fehlschlagen. Ein Server kann auf Port 25 antworten, STARTTLS in EHLO ankündigen, aber bei der TLS-Verhandlung wegen eines abgelaufenen Zertifikats scheitern.
Schritt 1: MX-Einträge auflösen
Bevor du die Konnektivität testest, identifiziere die MX-Server deiner Domain. Der Befehl dig gibt die MX-Einträge sortiert nach Priorität zurück:
$ dig captaindns.com MX +short
10 mx1.captaindns.com.
20 mx2.captaindns.com.
Die Zahl (10, 20) ist die Priorität: sendende Server kontaktieren zuerst den MX mit dem niedrigsten Wert. Teste alle deine MX, nicht nur den primären. Ein schlecht konfigurierter sekundärer MX ist trotzdem erreichbar und kann E-Mails ohne TLS annehmen.
Wenn dig kein Ergebnis liefert, liegt das Problem beim DNS: deine Domain hat keinen MX-Eintrag oder der DNS antwortet nicht.
Schritt 2: TCP-Verbindung und Banner mit telnet testen
Der Befehl telnet testet zwei Dinge in einem Vorgang: das Öffnen des TCP-Ports 25 und den Empfang des SMTP-Banners.
$ telnet mx1.captaindns.com 25
Trying 203.0.113.10...
Connected to mx1.captaindns.com.
Escape character is '^]'.
220 mx1.captaindns.com ESMTP Postfix
Ergebnis interpretieren
| Ergebnis | Bedeutung | Aktion |
|---|---|---|
Connected + 220 ... | Server erreichbar, Banner OK | Test fortsetzen |
Connection refused | Port 25 geschlossen oder Dienst gestoppt | Firewall und SMTP-Dienst prüfen |
Connection timed out | Port 25 blockiert (ISP, Firewall) | Von einem anderen Netzwerk testen |
220 ohne Hostname | Banner falsch konfiguriert | MTA-Konfiguration korrigieren |
EHLO-Erweiterungen erfassen
Nach dem Banner sendest du den Befehl EHLO, um die Fähigkeiten des Servers zu ermitteln:
EHLO test.captaindns.com
250-mx1.captaindns.com
250-PIPELINING
250-SIZE 52428800
250-STARTTLS
250-8BITMIME
250-SMTPUTF8
250 OK
Suche nach 250-STARTTLS in der Antwort: das ist die Zeile, die bestätigt, dass der Server TLS-Verschlüsselung unterstützt. Fehlt sie, akzeptiert der Server nur unverschlüsselte Verbindungen.
Schritt 3: STARTTLS und TLS-Zertifikat mit openssl testen
telnet kann keine TLS-Verhandlung initiieren. Um STARTTLS zu testen und das Zertifikat zu inspizieren, verwende openssl s_client:
$ openssl s_client -connect mx1.captaindns.com:25 -starttls smtp
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = mx1.captaindns.com
verify return:1
---
Certificate chain
0 s:CN = mx1.captaindns.com
i:C = US, O = Let's Encrypt, CN = R3
1 s:C = US, O = Let's Encrypt, CN = R3
i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
---
[...]
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
[...]
Die wichtigsten Informationen prüfen
TLS-Version: suche die Zeile New, TLSv1.X. TLS 1.3 ist optimal, TLS 1.2 ist akzeptabel. TLS 1.0 und 1.1 sind veraltet und anfällig.
Zertifikatskette: verify return:1 auf jeder Ebene bedeutet, dass die Kette gültig ist. verify return:0 weist auf ein Problem hin (abgelaufenes Zertifikat, unbekannter Aussteller, fehlender SAN).
Zertifikatssubjekt: der CN oder die SANs müssen mit dem Hostname des MX übereinstimmen. Ein Zertifikat für mail.captaindns.com ist nicht gültig für mx1.captaindns.com.
Ablaufdatum prüfen
$ openssl s_client -connect mx1.captaindns.com:25 -starttls smtp 2>/dev/null | openssl x509 -noout -dates
notBefore=Jan 15 00:00:00 2026 GMT
notAfter=Apr 15 23:59:59 2026 GMT
Wenn notAfter in der Vergangenheit liegt, ist das Zertifikat abgelaufen. Sendende Server, die Zertifikate prüfen (via MTA-STS oder DANE), werden die Verbindung ablehnen.
Schritt 4: Open Relay testen
Ein Open Relay akzeptiert die Weiterleitung von E-Mails an externe Empfänger ohne Authentifizierung. Um es zu erkennen, versuche eine E-Mail an eine Domain zu senden, die dein Server nicht verwaltet:
$ telnet mx1.captaindns.com 25
220 mx1.captaindns.com ESMTP
EHLO test.captaindns.com
250 OK
MAIL FROM:<test@captaindns.com>
250 OK
RCPT TO:<test@domaine-externe.example>
550 5.7.1 Relaying denied
QUIT
Ergebnis interpretieren
| Antwort auf RCPT TO | Bedeutung |
|---|---|
550 Relaying denied | Server korrekt konfiguriert (kein Open Relay) |
250 OK | Open Relay erkannt, sofortige Korrektur erforderlich |
450 oder 451 | Greylisting aktiv (normal, kein Open Relay) |
554 | Aus anderem Grund abgelehnt (Blacklist, Policy) |
Wenn dein Server 250 OK auf ein RCPT TO an eine externe Domain antwortet, ist er als Open Relay konfiguriert. Korrigiere sofort die Konfiguration deines MTA (Postfix: smtpd_relay_restrictions, Exchange: Receive Connectors).
Häufige Probleme diagnostizieren
Port 25 blockiert
Symptom: telnet mx1.captaindns.com 25 gibt "Connection timed out" zurück.
Mögliche Ursachen:
- Lokale Firewall oder Netzwerk blockiert Port 25 ausgehend
- Cloud-Hoster (AWS, Google Cloud, Azure) blockiert Port 25 standardmäßig
- ISP blockiert Port 25 bei Privatkunden-Anschlüssen
Diagnose: teste von einem Server außerhalb deines Netzwerks. Wenn der Test von außen funktioniert, aber lokal fehlschlägt, liegt die Blockierung auf der Netzwerk-/ISP-Seite. Weitere Details zur Port-25-Blockierung findest du in unserer Anleitung zu den SMTP-Ports.
Abgelaufenes TLS-Zertifikat
Symptom: openssl s_client zeigt verify return:0 und certificate has expired.
Auswirkung: Server, die MTA-STS anwenden, werden die Zustellung verweigern. Server ohne MTA-STS stellen trotzdem zu (opportunistisches STARTTLS), aber die Verbindung ist nicht authentifiziert.
Lösung: erneuere das Zertifikat (Let's Encrypt: certbot renew), dann lade den SMTP-Dienst neu.
STARTTLS angekündigt, aber fehlgeschlagen
Symptom: der Server kündigt 250-STARTTLS in EHLO an, aber openssl s_client -starttls smtp schlägt mit einem Handshake-Fehler fehl.
Mögliche Ursachen:
- Zertifikat in der MTA-Konfiguration referenziert, aber Datei fehlt oder ist unlesbar
- Falsche Berechtigungen für die Private-Key-Dateien
- TLS-Version zu alt (TLS 1.0 vom Client abgelehnt)
Diagnose:
$ openssl s_client -connect mx1.captaindns.com:25 -starttls smtp -debug 2>&1 | head -30
Verbindungs-Timeout (langsamer Server)
Symptom: die TCP-Verbindung wird aufgebaut, aber das Banner erscheint erst nach über 30 Sekunden.
Auswirkung: manche sendende Server geben nach einem Timeout auf (in der Regel 5 Minuten für das Banner, RFC 5321 Abschnitt 4.5.3.2). Ein langsamer MX verursacht Zustellverzögerungen und unnötige Wiederholungsversuche.
Lösung: prüfe die Serverlast, aggressive Greylisting-Regeln oder langsame DNS-Reverse-Lookups (PTR) in der MTA-Konfiguration.
SMTP-Tests automatisieren
Die Befehle telnet und openssl sind für eine einmalige Diagnose nützlich, aber sie haben Einschränkungen: sie testen nur einen Server gleichzeitig, liefern keinen strukturierten Bericht und sind für regelmäßiges Monitoring unpraktisch.
Bash-Skript zur Schnellprüfung
#!/bin/bash
# Einfacher SMTP-Test für alle MX einer Domain
DOMAIN="captaindns.com"
echo "=== MX von $DOMAIN ==="
dig $DOMAIN MX +short | sort -n | while read priority mx; do
mx="${mx%.}" # Abschließenden Punkt entfernen
echo ""
echo "--- $mx (Priorität $priority) ---"
# Port-25-Verbindung testen
timeout 10 bash -c "echo QUIT | telnet $mx 25 2>&1" | head -5
# STARTTLS + Zertifikat testen
echo | timeout 10 openssl s_client -connect $mx:25 -starttls smtp 2>/dev/null | \
openssl x509 -noout -subject -dates 2>/dev/null || echo "STARTTLS: Fehler oder nicht unterstützt"
done
Dieses Skript testet jeden MX der Domain: TCP-Verbindung, Banner und TLS-Zertifikat. Es deckt den Open-Relay-Test nicht ab (der eine komplexere SMTP-Interaktion erfordert).
Online-Tool CaptainDNS
Für eine vollständige Diagnose ohne Installation testet der SMTP/MX Connectivity Tester von CaptainDNS automatisch alle MX einer Domain in einer einzigen Abfrage: DNS-Auflösung, Verbindung auf Port 25, Banner, EHLO, STARTTLS, TLS-Zertifikat und Open-Relay-Erkennung. Die Ergebnisse werden mit einem Scoring pro Server und eindeutigen Diagnosecodes präsentiert.
Teste die SMTP-Konnektivität deiner MX-Server: Verwende unseren SMTP/MX Connectivity Tester, um in wenigen Sekunden alle deine MX zu diagnostizieren, mit TLS-Zertifikatvalidierung und Open-Relay-Erkennung.
FAQ
Wie teste ich, ob ein SMTP-Server auf Port 25 antwortet?
Verwende den Befehl telnet hostname 25. Wenn die Verbindung aufgebaut wird und du eine Zeile erhältst, die mit 220 beginnt, ist der Server erreichbar und der SMTP-Dienst funktioniert. Wenn du "Connection refused" oder "Connection timed out" erhältst, ist der Port geschlossen oder blockiert.
Wie prüfe ich die STARTTLS-Unterstützung eines MX-Servers?
Verbinde dich mit telnet hostname 25, sende EHLO dein.hostname und suche nach 250-STARTTLS in der Antwort. Um die tatsächliche TLS-Verhandlung zu testen, verwende openssl s_client -connect hostname:25 -starttls smtp. Wenn die Verhandlung erfolgreich ist, funktioniert STARTTLS.
Wie inspiziere ich ein SMTP-TLS-Zertifikat mit openssl?
Führe openssl s_client -connect hostname:25 -starttls smtp 2>/dev/null | openssl x509 -noout -text aus. Dieser Befehl zeigt das Subjekt, den Aussteller, die Gültigkeitsdaten, die SANs (Subject Alternative Names) und den Schlüsseltyp an. Prüfe, ob der CN oder ein SAN mit dem Hostname des MX übereinstimmt.
Wie erkenne ich, ob ein Server ein Open Relay ist?
Verbinde dich mit dem Server, sende MAIL FROM:<test@captaindns.com>, dann RCPT TO:<test@domaine-externe.example>. Wenn der Server 250 OK auf RCPT TO für eine Domain antwortet, die er nicht verwaltet, ist es ein Open Relay. Ein korrekt konfigurierter Server antwortet mit 550 Relaying denied.
Warum ist mein MX-Server auf Port 25 nicht erreichbar?
Die häufigsten Ursachen: Firewall blockiert Port 25, Cloud-Hoster blockiert Port 25 standardmäßig (AWS, GCP, Azure), SMTP-Dienst gestoppt oder MX-Eintrag zeigt auf eine falsche IP. Teste von einem anderen Netzwerk, um die Ursache einzugrenzen.
Welche TLS-Version ist für einen MX-Server akzeptabel?
TLS 1.2 ist das akzeptable Minimum in 2026. TLS 1.3 wird für optimale Sicherheit und bessere Performance empfohlen (schnellerer Handshake). TLS 1.0 und 1.1 sind veraltet (RFC 8996) und sollten nicht mehr aktiviert sein.
Welche Online-Tools testen die SMTP-Konnektivität?
Der SMTP/MX Connectivity Tester von CaptainDNS testet automatisch alle MX einer Domain: Banner, EHLO, STARTTLS, TLS-Zertifikat und Open Relay. Andere Tools wie MXToolbox SMTP Test oder CheckTLS bieten ähnliche Funktionen, aber mit weniger Details zum Zertifikat.
Glossar
- SMTP-Banner: Erste Antwort des Servers (Code 220) bei der TCP-Verbindung. Enthält den Hostname und manchmal die MTA-Software (Postfix, Exchange, Exim).
- EHLO: Extended HELO. SMTP-Befehl, der den Client identifiziert und den Server auffordert, seine Erweiterungen aufzulisten (STARTTLS, SIZE, PIPELINING usw.).
- STARTTLS: SMTP-Erweiterung (RFC 3207), die es ermöglicht, eine unverschlüsselte Verbindung über einen expliziten Befehl auf eine TLS-verschlüsselte Verbindung umzustellen.
- Open Relay: SMTP-Server, der E-Mails an externe Empfänger ohne Authentifizierung weiterleitet. Spam-Vektor, führt schnell zu Blacklisting.
- SAN: Subject Alternative Name. Feld im TLS-Zertifikat, das die Hostnamen auflistet, für die das Zertifikat gültig ist.
- MTA: Mail Transfer Agent. Server-Software, die E-Mails transportiert (Postfix, Exim, Exchange, Sendmail).
- Greylisting: Anti-Spam-Technik, die E-Mails unbekannter Absender vorübergehend ablehnt (Code 450). Der legitime Server versucht es erneut, der Spammer nicht.
📚 Verwandte SMTP- und E-Mail-Konnektivitäts-Leitfäden
- Die SMTP-Ports erklärt: 25, 465, 587, 2525: Rolle, Verschlüsselung und Anwendungsfälle jedes SMTP-Ports
- STARTTLS, SSL/TLS und SMTP: Welche Verschlüsselung für deine E-Mails?: Protokolle, Postfix/Exim/Exchange-Konfiguration und Downgrade-Schutz
- Port 25 blockiert: Diagnose und Lösungen nach Hoster (demnächst)
