SMTP-Monitoring: Mailserver-Erreichbarkeit, Banner und Handshake
SMTP-Monitoring hilft dabei zu bestaetigen, dass ein Mailserver erreichbar ist und wirklich das Protokoll spricht, das Clients und andere Mailserver erwarten. Wenn E-Mail fuer Ihr Produkt wichtig ist, reicht es nicht, dass TCP 25 oder 587 offen ist. Sie wollen auch wissen, dass der Maildienst korrekt antwortet und bereit ist, die SMTP-Konversation fortzusetzen.
Was SMTP-Monitoring tatsaechlich validiert
SMTP-Monitoring prueft, ob ein Mailserver eine Verbindung annimmt und sich wie ein echter SMTP-Dienst verhaelt. Dazu gehoert haeufig die Kontrolle des initialen 220-Banners und die Faehigkeit, auf EHLO oder andere Startkommandos korrekt zu reagieren.
Das ist wichtig, weil ein offener TCP-Port noch keinen gesunden Maildienst beweist. Ein Dienst kann falsch konfiguriert, ueberlastet, gefiltert oder auf Protokollebene fehlerhaft sein, obwohl der Port Verbindungen annimmt.
Wann Teams SMTP ueberwachen
E-Mail ist geschaeftskritisch
Passwort-Resets, Alerts, Rechnungen, Onboarding-Mails und transaktionale Nachrichten haengen alle davon ab, dass SMTP irgendwo in der Kette sauber funktioniert.
Ein Mailserver muss mehr koennen als nur lauschen
Sie wollen sicher sein, dass der SMTP-Prozess korrekt antwortet und nicht nur, dass der Port technisch offen ist.
Sie wollen stille Mail-Probleme frueh erkennen
Mail-Stoerungen fallen oft erst durch Support-Tickets auf, besonders wenn Queues auflaufen oder nur einzelne Server betroffen sind.
Sie betreiben eigene oder hybride Mail-Infrastruktur
Individuelle SMTP-Setups, Relays und gemischte Cloud-/On-Prem-Pfade profitieren von aktiven Checks, die bestaetigen, dass der Dienst auf dem Endpoint wirklich SMTP spricht.
So funktioniert ein einfacher SMTP-Handshake
Der Client verbindet sich mit dem SMTP-Port
Typischerweise ist das TCP 25 fuer Server-zu-Server-Transport oder TCP 587 fuer authentifizierte Client-Submission.
Der Server liefert einen 220-Banner
Ein gesunder SMTP-Server beginnt die Verbindung meist mit einer 220-Antwort, die signalisiert, dass er bereit fuer die Sitzung ist.
Der Client sendet EHLO oder HELO
Damit startet die SMTP-Sitzung und der Server kann Faehigkeiten bekanntgeben und die Kommunikation fortsetzen.
Ein protokollbewusster Check beweist mehr als Port-Erreichbarkeit
Wenn der Server keinen erwarteten Banner liefert oder danach nicht korrekt weiterarbeitet, kann der Dienst ungesund sein, obwohl der TCP-Port offen ist.
Wie typische SMTP-Signale zu lesen sind
Bei SMTP-Diagnosen dreht sich viel um Antworten wie diese:
220 mail.example.com ESMTP ready 250 OK 250-STARTTLS 421 Service not available 450 Requested action not taken 550 Requested action not taken: mailbox unavailable
220-Banner
Das ist das klassische Signal dafuer, dass der SMTP-Server nach dem Verbindungsaufbau bereit fuer die Sitzung ist.
250-Antworten
Diese bedeuten meist, dass der vorherige Befehl akzeptiert wurde und die Kommunikation fortgesetzt werden kann.
4xx temporaere Fehler
Sie deuten oft auf zeitweilige Probleme wie Ueberlastung, Throttling oder nicht verfuegbare Abhaengigkeiten hin.
5xx dauerhafte Fehler
Diese sprechen eher fuer eine haertere Stoerung oder Policy-Ablehnung als fuer eine temporaere Retry-Situation.
Warum SMTP mehr als einen Port-Check braucht
Ein Mailserver kann TCP 25 offen haben und trotzdem keinen korrekten SMTP-Banner liefern oder danach nicht sauber weiterarbeiten. Das ist ein reales Zustellungsrisiko, auch wenn ein einfacher Port-Check gesund aussieht.
Protokollbewusstes SMTP-Monitoring liefert ein staerkeres Signal, weil es bestaetigt, dass sich der Dienst wirklich wie SMTP verhaelt und nicht nur irgendetwas auf dem Port lauscht.
SMTP-Monitoring vs TCP-Port-Monitoring
| Thema | SMTP-Check | TCP-Port-Check |
|---|---|---|
| Zentrale Frage | Antwortet der Maildienst wie SMTP und setzt den Handshake korrekt fort? | Ist der Port erreichbar und nimmt TCP-Verbindungen an? |
| Am besten geeignet fuer | Mailserver-Verhalten, Banner-Validierung und Gesundheitszustand des E-Mail-Dienstes auf Protokollebene. | Grundlegende Listener-Verfuegbarkeit auf Port 25, 465 oder 587. |
| Was es uebersehen kann | Es beweist noch nicht automatisch endgueltige Inbox-Zustellung von Anfang bis Ende. | Es beweist nicht, dass der Dienst nach dem Connect korrekt SMTP spricht. |
Sie brauchen auch die Transportgrundlagen hinter SMTP?
SMTP baut auf TCP-Port-Erreichbarkeit auf, bevor die Protokollkonversation beginnt. TCP-Port-Monitoring bleibt deshalb eine wichtige Basis unterhalb von Mail-Checks.
Zum TCP/UDP-Leitfaden βTypische Situationen richtig deuten
TCP 25 ist offen, aber es kommt kein 220-Banner
Etwas lauscht, aber der SMTP-Dienst kann haengen, falsch konfiguriert, gefiltert oder schlicht nicht gesund sein.
Der Banner erscheint, aber spaetere Kommandos scheitern
Der Listener lebt, aber die Anwendung kann trotzdem Protokoll-, Auth-, Policy- oder Backend-Probleme haben.
Mail-Verzoegerungen treten nur gelegentlich auf
Temporaeres 4xx-Verhalten kann auf Throttling, Queue-Druck, Abhaengigkeitsprobleme oder ueberlastete Infrastruktur hindeuten.
Submission funktioniert, aber eingehender Relay nicht
TCP 587 und TCP 25 haben unterschiedliche Rollen. Deshalb ist es wichtig, genau den SMTP-Endpoint zu pruefen, der zur jeweiligen Delivery-Strecke gehoert.
Wichtige Einschraenkungen
- β SMTP-Monitoring beweist nicht automatisch die vollstaendige Inbox-Zustellung oder Akzeptanz bei jedem externen Provider.
- β Ein gesunder SMTP-Handshake garantiert nicht, dass nachgelagerte Queues, Relays oder Empfaenger-Policies gesund sind.
- β Unterschiedliche Ports wie 25, 465 und 587 haben verschiedene Rollen und sollten oft getrennt geprueft werden.
- β Mail-Systeme bestehen meist aus mehreren Ebenen, daher beweist ein erfolgreicher Endpoint noch keinen gesunden Gesamtfluss.
Wie SMTP manuell getestet wird
telnet mail.example.com 25 Hilfreich, um zu sehen, ob der Server nach dem Connect den erwarteten 220-SMTP-Banner liefert.
nc -vz mail.example.com 25 Ein schneller Test fuer grundlegende TCP-Erreichbarkeit vor tieferen SMTP-Pruefungen.
openssl s_client -starttls smtp -connect mail.example.com:587 Nuetzlich, wenn Sie SMTP ueber TLS auf Submission-Endpoints genauer ansehen wollen.
Haeufige Fragen
Ein offener Mail-Port ist noch kein gesunder Maildienst.
nsmon hilft Ihnen, SMTP-Endpoints zu ueberwachen, damit sichtbar wird, wenn ein Mailserver nicht mehr korrekt antwortet, bevor Passwort-Resets, Alerts oder transaktionale E-Mails in Produktion scheitern. Erstellen Sie ein kostenloses Konto und ueberwachen Sie die SMTP-Dienste, auf die Ihr Geschaeft angewiesen ist.