Begriff · SMTP-Port

Welchen SMTP-Port sollte eine Anwendung für E-Mails verwenden?

Die meisten Anwendungen sollten den von ihrem E-Mail-Provider dokumentierten Submission-Endpunkt und Port verwenden. Port 587 ist der Standardport für Nachrichtensubmission und beginnt üblicherweise mit einfachem SMTP vor einem STARTTLS-Upgrade. Port 465 ist Nachrichtensubmission mit implizitem TLS; der TLS-Handshake beginnt daher sofort. Port 25 ist vor allem für SMTP-Relay zwischen Servern bestimmt, nicht für die übliche authentifizierte Anwendungs-Submission. Eine funktionierende Konfiguration muss vier Dinge gemeinsam abgleichen: Hostname, Port, TLS-Modus und Authentifizierungsmethode.

Ein SMTP-Port legt eine Protokollrolle und einen Verbindungsmodus fest

Eine Portnummer ist nicht bloß eine austauschbare Tür zum selben Dienst. Sie hilft zu erkennen, welche SMTP-Rolle der Server anbietet und wie die Verbindung beginnt. Die Einlieferung (Submission) ist die erste Übergabe von einer Anwendung oder einem User Agent an einen Submission-Dienst. Relay ist die Weiterleitung von E-Mails zwischen Mailservern. Standards trennen diese Aufgaben, weil die Submission Authentifizierung, Absenderautorisierung und Richtlinienprüfungen der Nachricht verlangen kann, die für öffentliches Mail-Relay nicht auf dieselbe Weise gelten. Der Port kann außerdem anzeigen, ob der Client mit SMTP-Befehlen beginnt und später per STARTTLS upgradet oder sofort einen TLS-Handshake startet. Behandeln Sie Hostname, Port, TLS-Modus und Authentifizierungsanweisungen des Providers als ein zusammengehöriges Konfigurations-Tupel. Wer einen Port von einem fremden Provider übernimmt oder nach einem Fehler nur den Port ändert, kann aus einem Netzwerkproblem einen TLS- oder Authentifizierungsfehler machen, ohne die ursprüngliche Ursache zu beheben.

Port 25 dient hauptsächlich dem Relay zwischen Mailservern

Port 25 ist der übliche SMTP-Relay-Port, über den ein Message Transfer Agent E-Mails an einen anderen übergibt. RFC 6409 belässt das Relay auf Port 25 und verlagert die Einlieferung neuer Nachrichten auf Port 587. Eine Anwendung sollte daher nicht davon ausgehen, dass direkte Verbindungen zu Empfänger-Mailservern auf Port 25 der normale Weg sind, Produkt-E-Mails zu senden. Direktes Relay erfordert Warteschlangen, DNS-Routing, Bounce-Verarbeitung, Missbrauchskontrollen, Reputationsmanagement und standardkonformes Wiederholungsverhalten. Netzwerke und Hosting-Provider können ausgehenden Port 25 außerdem einschränken. AWS dokumentiert zum Beispiel, dass E-Mail-Traffic von Amazon EC2 auf Port 25 standardmäßig gedrosselt wird. Port 25 kann bei einem Provider oder in kontrollierter Infrastruktur weiterhin eine dokumentierte Option sein, doch seine Verfügbarkeit macht ihn nicht zur bevorzugten Wahl für die Einlieferung. Verwenden Sie ihn nur, wenn der zuständige Dienst diesen Endpunkt, den Sicherheitsmodus und das Betriebsmodell ausdrücklich dokumentiert.

Port 587 ist der Standardport für die Einlieferung von Nachrichten

RFC 6409 reserviert Port 587 für die Einlieferung von Nachrichten und beschreibt einen Submission-Dienst, der nicht autorisierte E-Mails ablehnen, Authentifizierung verlangen und Richtlinien durchsetzen kann, bevor er eine neue Nachricht annimmt. Eine typische Sitzung auf Port 587 beginnt als SMTP, meldet nach `EHLO` die STARTTLS-Erweiterung, wechselt die Verbindung auf TLS, wiederholt `EHLO`, authentifiziert sich und übermittelt dann die Nachricht. Das Wort „typisch“ ist wichtig: Die genauen Authentifizierungsmechanismen und Anforderungen ergeben sich aus der aktuellen Dokumentation des Providers und den Fähigkeiten des Servers. Ein sicherer Client sollte das erwartete TLS-Upgrade verlangen und das Serverzertifikat validieren, statt nach einer gescheiterten Aushandlung im Klartext weiterzumachen. Verwechseln Sie eine anfängliche unverschlüsselte Protokollbegrüßung nicht mit einer ungeschützten authentifizierten Sitzung; STARTTLS ist dafür ausgelegt, die Verbindung zu upgraden, bevor Zugangsdaten und Nachrichtendaten gesendet werden. Port 587 kennzeichnet den Submission-Dienst, ob TLS erfolgreich durchgesetzt wird, hängt aber von der korrekten Client-Richtlinie ab.

Port 465 nutzt implizites TLS für die Einlieferung

Port 465 ist für die Einlieferung von Nachrichten über implizites TLS registriert. Bei implizitem TLS führt der Client den TLS-Handshake aus, sobald die TCP-Verbindung steht, und sendet SMTP-Befehle nur innerhalb des geschützten Kanals. Das unterscheidet sich von Port 587 mit STARTTLS, bei dem der Client zuerst eine SMTP-Begrüßung erhält und dann das Upgrade anfordert. RFC 8314 empfiehlt implizites TLS für die Einlieferung und beschreibt zugleich einen Übergang, in dem Provider und Clients sowohl Port 465 mit implizitem TLS als auch Port 587 mit STARTTLS unterstützen können. Laut RFC können korrekt implementierte Clients und Server mit beiden Modi im Wesentlichen gleichwertige Sicherheit bieten, sofern TLS zwingend ist. Die praktische Regel lautet, keinen Port pauschal für richtig zu erklären. Verwenden Sie genau den Endpunkt und Modus, den der Provider unterstützt. Wer STARTTLS gegen einen Listener mit implizitem TLS konfiguriert oder implizites TLS gegen einen STARTTLS-Listener, scheitert in der Regel schon vor der Authentifizierung.

Providerspezifische alternative Ports sind ausdrückliche Verträge

Einige Provider bieten alternative Ports an, um Netzwerkeinschränkungen zu umgehen, doch diese Nummern sind keine universellen SMTP-Standards für jeden Dienst. Amazon SES dokumentiert derzeit STARTTLS auf den Ports 25, 587 und 2587 sowie TLS Wrapper, seine Bezeichnung für implizites TLS, auf den Ports 465 und 2465. SES verlangt verschlüsselte Verbindungen und veröffentlicht regionsspezifische SMTP-Endpunkte. Das zeigt, warum ein Port der Dokumentation des gewählten Providers entnommen werden muss und nicht einer allgemeinen Liste. Port 2587 bedeutet nicht überall STARTTLS, und Port 2465 kennzeichnet nicht auf beliebigen Hosts einen Dienst mit implizitem TLS. Alternative Ports umgehen auch weder Absenderverifizierung noch Credential-Bereich, Kontingente oder Provider-Richtlinien. Halten Sie zur Produktivkonfiguration die Quell-URL und das Datum der Prüfung fest, damit ein Operator eine bewusste Provider-Einstellung von einer unerklärten magischen Zahl unterscheiden kann, die Jahre zuvor in eine Umgebungsvariable kopiert wurde.

Hostname, Port, TLS und Authentifizierung gemeinsam konfigurieren

Eine robuste SMTP-Konfiguration ist ein Bündel: Hostname des Providers, Port, Modus der Transportsicherheit, Richtlinie zur Zertifikatsprüfung, Authentifizierungsmechanismus, Benutzername, Geheimnis, Verbindungs-Timeout und Absenderidentität. Der Hostname zählt, weil das TLS-Zertifikat dagegen geprüft wird und weil Provider unterschiedliche regionale Endpunkte anbieten können. Port und TLS-Modus müssen zusammenpassen. Die Authentifizierung sollte erst erfolgen, wenn der vorgesehene geschützte Kanal steht, und Geheimnisse gehören in einen Secret Manager statt in Quellcode, Browser-Bundles, Logs oder Diagnoseausgaben. Trennen Sie Zugangsdaten und Konfiguration nach Umgebung, damit ein lokaler Test nicht versehentlich über die Produktion sendet. Setzen Sie endliche Timeouts für Verbindung und Befehle, überlassen Sie Wiederholungsversuche für Nachrichten aber einer dauerhaften Anwendungswarteschlange. Eine Bibliotheksoption namens `secure` kann in einem SDK implizites TLS bedeuten und in einem anderen lediglich STARTTLS verlangen. Prüfen Sie daher die Definition der Bibliothek und testen Sie das ausgehandelte Verhalten, statt sich auf den Optionsnamen zu verlassen.

Die Verbindung schichtweise testen, ohne Geheimnisse offenzulegen

Beginnen Sie mit der DNS-Auflösung und der TCP-Erreichbarkeit aus demselben Laufzeitnetzwerk wie die Anwendung. Ein Timeout vor dem Verbindungsaufbau deutet auf Routing, Firewall, Egress-Richtlinie des Providers, falschen Hostnamen oder einen geschlossenen Port hin. Testen Sie als Nächstes den erwarteten TLS-Modus. Bei implizitem TLS sollte ein TLS-Client ein Zertifikat und danach eine SMTP-Begrüßung erhalten. Bei STARTTLS sollte ein SMTP-fähiger Client die Begrüßung erhalten, `EHLO` senden, die Ankündigung von STARTTLS sehen, das Upgrade anfordern, das Zertifikat validieren und nach TLS erneut `EHLO` senden. RFC 3207 verlangt, dass Client und Server vor dem Handshake gewonnene Informationen verwerfen; deshalb ist das zweite `EHLO` wichtig. Testen Sie erst dann die Authentifizierung mit einem kontrollierten Konto. Schwärzen Sie Benutzernamen, Tokens, Empfängeradressen, vollständige Server-Transkripte und Nachrichteninhalte, bevor Sie Logs teilen. Für einen Konnektivitätstest ist weder ein Produktivversand noch eine echte Kundenadresse nötig.

Fehler nach der Phase klassifizieren, in der sie tatsächlich auftraten

Eine abgelehnte Verbindung („Connection refused“) bedeutet, dass das TCP-Ziel die Verbindung aktiv abgewiesen hat; ein Timeout bedeutet, dass innerhalb des Limits keine brauchbare Antwort eintraf. Ein TLS-Handshake-Fehler deutet auf einen Modus-Konflikt, ein Zertifikatsproblem, eine Protokollinkompatibilität, ein Abfangen der Verbindung oder einen falschen Endpunkt hin. Ein Authentifizierungsfehler tritt später auf und sollte als Problem bei Credential, Mechanismus, Konto oder Autorisierungskonfiguration untersucht werden, nicht durch wahlloses Ändern von Ports. SMTP-Antwortcodes bei `MAIL FROM`, `RCPT TO` oder `DATA` beschreiben noch spätere Entscheidungen zu Richtlinie und Nachricht. Bewahren Sie Phase, Zeitstempel, Endpunkt, Anzahl der Versuche, numerische Antwort und eine datenschutzbereinigte Antwort auf. Eine 4xx-SMTP-Antwort ist normalerweise vorübergehend und eine 5xx-Antwort normalerweise permanent für den versuchten Befehl, doch Wiederholungsversuche müssen begrenzt und empfängerbezogen sein. Hat der Provider die Nachrichtendaten angenommen, senden Sie nicht blind ein Duplikat, weil eine spätere Anfrage der Anwendung in ein Timeout lief; gleichen Sie stattdessen anhand der Provider-Kennung und des Event-Verlaufs ab.

Ein erfolgreicher Port-Test bedeutet weder Zustellung noch Platzierung im Posteingang

Eine erfolgreiche TCP-Verbindung belegt nur, dass ein Listener geantwortet hat. Ein erfolgreicher TLS-Handshake belegt eine geschützte Verbindung zum authentifizierten Endpunkt, sofern die Zertifikatsprüfung gelingt. Die Authentifizierung belegt, dass der Server die vorgelegte Client-Identität für diese Sitzung akzeptiert hat. Eine SMTP-Antwort `250` nach den Nachrichtendaten bedeutet, dass der antwortende Server nach dem Protokoll die Verantwortung übernommen hat, nicht dass eine Person die Nachricht erhalten oder gelesen hat. Ein späteres Relay kann noch scheitern, und ein empfangendes System kann eine E-Mail annehmen und sie außerhalb des Haupt-Posteingangs einsortieren. Halten Sie diese Status in Anwendungsdatensätzen und Monitoring getrennt. Netzwerkverfügbarkeit, TLS-Aushandlung, Authentifizierung, Annahme durch den Provider, Annahme durch den Zielserver, Bounce, Beschwerde und Interaktion sind verschiedene Beobachtungen. Diese Trennung verhindert, dass ein Port-Test fälschlich als Zustelltest gemeldet wird, und verhindert, dass eine angenommene Nachricht nur deshalb wiederholt wird, weil sich die Platzierung im Posteingang nicht belegen lässt.

SMTP-Submission oder E-Mail-API bewusst wählen

Verwenden Sie SMTP-Submission, wenn ein System bereits einen ausgereiften SMTP-Client hat, eine erforderliche Plattform SMTP als unterstützte Integration anbietet oder Protokollkontrollen ausdrücklich nötig sind. Eine HTTPS-E-Mail-API kann eine bessere Anwendungsgrenze sein, wenn strukturierte Anfragen, eingeschränkte Token, Idempotenz, Batch-Ressourcen und maschinenlesbare Event-Aufzeichnungen zur Arbeitslast passen. Der Provider kann weiterhin SMTP nachgelagert für Empfänger-Mailsysteme verwenden; eine API schafft Mailtransport also nicht ab. Sie verlagert die Verantwortung für Port, TLS, Authentifizierung und Wiederholung bei der Provider-Übergabe aus der SMTP-Konfiguration der Anwendung.

Häufig gestellte Fragen

Sollte meine Anwendung SMTP-Port 587 oder 465 verwenden?

Verwenden Sie den Port und den TLS-Modus, die Ihr Provider dokumentiert. Port 587 nutzt normalerweise STARTTLS, Port 465 implizites TLS. Beide können die Einlieferung schützen, wenn sie korrekt implementiert und verlangt werden; die Client-Konfiguration muss zum Listener des Servers passen.

Warum ist SMTP-Port 25 blockiert oder läuft in ein Timeout?

Eine Hosting-Plattform, ein ISP, eine Firewall oder eine Richtlinie des Ziels kann Port 25 einschränken, weil er für das Relay zwischen Mailservern dient und häufig missbraucht wird. Prüfen Sie die Netzwerkrichtlinie und nutzen Sie den dokumentierten Submission-Endpunkt Ihres Providers, statt eine Einschränkung mit einem beliebigen Port zu umgehen.

Kann ich von Port 587 auf 465 wechseln, ohne etwas anderes zu ändern?

In der Regel nicht. Port 587 beginnt üblicherweise mit SMTP und wechselt per STARTTLS auf TLS, während Port 465 mit einem sofortigen TLS-Handshake beginnt. Ändern Sie Port und TLS-Modus des Clients gemeinsam und folgen Sie dabei der Dokumentation von Provider und Bibliothek.

Ist Port 587 standardmäßig verschlüsselt?

Der Port kennzeichnet die Einlieferung von Nachrichten, die Verschlüsselung hängt aber weiterhin von der STARTTLS-Aushandlung und der Client-Richtlinie ab. Konfigurieren Sie den Client so, dass er ein erfolgreiches Upgrade verlangt, das Zertifikat validiert und weder Zugangsdaten noch Nachrichtendaten sendet, wenn keine geschützte Einlieferung zustande kommt.

Was bedeutet „SMTP connection refused“?

Es bedeutet, dass das TCP-Ziel die Verbindung vor der SMTP-Aushandlung abgewiesen hat. Häufige Ursachen sind falscher Host oder Port, ein Dienst, der nicht lauscht, eine Ablehnung durch eine Firewall oder ein Provider-Endpunkt, der aus diesem Netzwerk nicht erreichbar ist.

Belegt ein erfolgreicher SMTP-Port-Test die Zustellung von E-Mails?

Nein. Er belegt nur die Phasen, die der Test tatsächlich abgeschlossen hat, etwa TCP oder TLS. Authentifizierung, Annahme der Nachricht, Annahme durch den Zielserver, Bounce-Verarbeitung, Postfachklassifizierung und Interaktion der Empfänger erfordern getrennte Nachweise und müssen getrennt berichtet werden.

Quellen

Weiterlernen

SMTP-Protokoll: Wie Anwendungs-E-Mails übertragen werdenErfahren Sie, wie SMTP-Submission, Relay, Envelopes, Antwortcodes, TLS, Wiederholungsversuche und Nachrichteninhalt einen E-Mail-Workflow in Anwendungen prägen.Einen SMTP-Relay-Dienst bewertenBewerten Sie SMTP-Relay-Dienste nach Submission-Sicherheit, Authentifizierung, Warteschlangen, Wiederholungsverhalten, Limits, Zustell-Events, Sperrlisten, Isolation und Eignung für die Migration.E-Mail-API integrieren: Leitfaden für ProduktteamsEntwerfen Sie eine sichere E-Mail-API-Integration mit verifizierten Domains, Versand über Warteschlangen, stabilen IDs, kontrollierten Wiederholungsversuchen, Zustell-Events, Sperrliste und Mandantentrennung.Einen Dienst für E-Mail-Zustellbarkeit bewertenBewerten Sie Dienste für E-Mail-Zustellbarkeit nach Umfang, Nachweisen, Authentifizierung, Feedback-Loops, Sperrlisten, Datenschutz, Portabilität und betrieblicher Eignung.