Begriff · SMTP-Mailprotokoll

Was ist das Mailprotokoll SMTP, und wie wirkt es sich auf Anwendungs-E-Mails aus?

SMTP (Simple Mail Transfer Protocol) ist das standardisierte Protokoll, mit dem Mailsysteme ausgehende E-Mails einliefern, weiterleiten und übergeben. Eine Anwendung übergibt in der Regel eine fertige Nachricht an einen authentifizierten Submission-Dienst; die Mailserver bringen sie dann mithilfe von SMTP-Befehlen und DNS-Routing zu jedem Empfänger. SMTP-Antworten zeigen, ob ein bestimmter Hop einen Empfänger angenommen oder abgelehnt hat, doch Annahme ist nicht dasselbe wie Platzierung im Posteingang. Anwendungen brauchen weiterhin dauerhafte Warteschlangen, sichere Wiederholungen, Nachrichtenkennungen, Authentifizierung und Bounce-Verarbeitung.

SMTP überträgt E-Mails zwischen verantwortlichen Systemen

SMTP ist ein Store-and-Forward-Übertragungsprotokoll. Ein Client öffnet eine Sitzung mit einem Server, identifiziert sich, nennt einen Envelope-Absender, schlägt einen oder mehrere Envelope-Empfänger vor und überträgt den Nachrichteninhalt, nachdem der Server den Empfang zugesagt hat. Der Server kann einige Empfänger annehmen und andere ablehnen; der Status gehört daher zu einem Empfänger und einer Transaktion und nicht nur zur Nachricht als Ganzem. Sobald ein Server die Verantwortung übernommen hat, kann er lokal zustellen oder die Nachricht an ein anderes System weiterleiten, das über DNS-MX-Einträge (Mail Exchanger) ermittelt wird. Wegen dieses Hop-für-Hop-Aufbaus sollte eine Anwendung den E-Mail-Zustand nicht auf ein einziges „gesendet“-Flag reduzieren. Anwendung, Submission-Dienst, Relay, empfangender Server und das Filtersystem des Postfachs kennen jeweils nur einen Teil des Ergebnisses. SMTP bewegt die Nachricht zwischen Systemen, während Datensätze auf Produktebene und Provider-Events diese Bewegung für Nutzer und Betreiber nachvollziehbar machen.

Submission und Relay sind unterschiedliche Protokollrollen

RFC 6409 trennt die Nachrichteneinlieferung (Submission) vom Nachrichten-Relay. Submission ist die erste Übergabe von einem autorisierten Nutzer oder einer Anwendung an einen Message Submission Agent, normalerweise über Port 587. Relay ist die Übertragung zwischen Message Transfer Agents und verwendet üblicherweise Port 25. Submission-Dienste können eine Authentifizierung verlangen, Nachrichtenfelder prüfen oder ergänzen und Absenderrichtlinien durchsetzen, weil sie wissen, wer neue E-Mails einliefert. Öffentliche Relay-Server müssen mit anderen Domains zusammenarbeiten und folgen anderen Vertrauensregeln. Anwendungscode sollte sich daher mit dem dokumentierten Submission-Endpunkt eines Providers verbinden oder dessen HTTP-API nutzen und nicht beliebige Verbindungen über Port 25 zu Zielservern öffnen. Diese Trennung verdeutlicht auch die Rolle der Zugangsdaten: Ein SMTP-Benutzername oder -Token berechtigt zur Einlieferung bei einem bestimmten Dienst; er gibt keine Befugnis über die Zieldomain. Halten Sie Submission-Zugangsdaten serverseitig, beschränken Sie sie auf die sendende Workload, soweit der Provider das unterstützt, und rotieren Sie sie, ohne sie in Nachrichteninhalte oder Client-Software einzubetten.

Der SMTP-Envelope unterscheidet sich von den sichtbaren Nachrichten-Headern

Eine SMTP-Transaktion trägt einen Envelope mit `MAIL FROM` und einem oder mehreren `RCPT TO`-Befehlen. Der übertragene Inhalt folgt getrennt davon dem in RFC 5322 definierten Internet Message Format mit Feldern wie From, To, Date, Subject und Message-ID sowie einem Body. MIME-Standards erweitern diesen Inhalt um HTML, alternative Teile, Anhänge und Nicht-ASCII-Daten. Der Envelope-Absender ist die Adresse für Transportfehler und kann vom sichtbaren From-Autor abweichen. Envelope-Empfänger können sich ebenfalls von den sichtbaren Feldern To und Cc unterscheiden, etwa bei Bcc. Bauen Sie diese Strukturen nicht durch Verketten nicht vertrauenswürdiger Strings zusammen. Verwenden Sie eine gepflegte Nachrichtenbibliothek, validieren Sie Adressen, verhindern Sie das Einschleusen von Zeilenumbrüchen in Header-Felder und behalten Sie eine stabile Message-ID bei. Prüfen Sie bei der Fehlersuche beide Ebenen: Ein korrektes sichtbares From-Feld kann eine nicht autorisierte Envelope-Identität nicht heilen, und ein gültiger Envelope sorgt nicht dafür, dass fehlerhaftes MIME korrekt angezeigt wird.

Die Transaktion als Zustandsautomat lesen

Eine einfache Extended-SMTP-Sitzung beginnt mit der Begrüßung durch den Server, gefolgt von `EHLO`, damit der Server Erweiterungen ankündigen kann. Für die Submission kann der Client TLS und Authentifizierung aushandeln. Eine Mailtransaktion nutzt dann `MAIL FROM`, ein `RCPT TO` je Ziel, `DATA`, die vollständige, nach SMTP-Framing abgeschlossene Nachricht und `QUIT`. Verstehen Sie das Beispiel nicht als Anlass, das Wire-Protokoll selbst zu implementieren; ausgereifte SMTP-Bibliotheken behandeln Zeilenenden, Dot-Transparenz, Aushandlung von Fähigkeiten, Authentifizierung und TLS-Zustand sicherer. Instrumentieren Sie die Bibliothek auf Ebene der Befehlskategorie und des Antwortcodes, ohne Zugangsdaten oder vollständige Nachrichten-Bodys zu protokollieren. Halten Sie fest, welcher Empfänger in welcher Phase fehlgeschlagen ist und ob der Server nach den Nachrichtendaten die Verantwortung übernommen hatte. Diese Grenze entscheidet, ob ein Wiederholungsversuch angemessen ist, ob ein Duplikat möglich ist und ob der Fehler über eine spätere Delivery-Status-Notification statt über eine sofortige Antwort gemeldet wird.

Antwortcodes klassifizieren, bevor Sie über Wiederholungen entscheiden

SMTP-Antwortklassen geben eine Handlungsempfehlung vor. Eine 2xx-Antwort zeigt an, dass der jeweilige Befehl erfolgreich abgeschlossen wurde. Eine 4xx-Antwort ist ein vorübergehender negativer Abschluss, sodass ein Sender mit Warteschlange es nach einer Wartezeit erneut versuchen darf. Eine 5xx-Antwort ist ein dauerhafter negativer Abschluss für den versuchten Befehl und erfordert in der Regel Korrektur, Sperrung oder menschliche Untersuchung statt wiederholter Versuche. Erweiterte Statuscodes ergänzen eine strukturierte Diagnose der Form `X.Y.Z` für Adress-, Postfach-, System-, Routing-, Protokoll-, Inhalts- oder Sicherheits- und Richtlinienbedingungen. Bewahren Sie sowohl den numerischen Code als auch den Servertext auf, weil beide diagnostischen Wert haben können, machen Sie rohe Antworten mit Empfängerdaten aber nicht breit zugänglich. Wenden Sie bei vorübergehenden Fehlern exponentiellen Backoff mit Jitter und eine maximale Lebensdauer in der Warteschlange an. Wiederholen Sie nie so aggressiv, dass aus einem vorübergehenden Problem beim Ziel missbräuchlicher Datenverkehr wird. Bei einem dauerhaften Adressfehler beenden Sie automatische Sendungen an dieses Ziel und aktualisieren den Sperrstatus. Bei Richtlinien- oder Authentifizierungsfehlern beheben Sie erst Identität, DNS, Zugangsdaten oder Inhalt, bevor Sie es erneut versuchen.

Verschlüsselte, authentifizierte Submission verwenden

SMTP entstand als Transportprotokoll über Netze mit unterschiedlichen Vertrauensannahmen; sichere Submission beruht daher auf Erweiterungen und der Deployment-Richtlinie. STARTTLS stuft eine SMTP-Verbindung auf TLS hoch, danach muss der Client die vor dem Handshake ermittelten Fähigkeiten verwerfen und erneut `EHLO` senden. RFC 8314 aktualisiert die Leitlinien zur Submission, indem es Klartextzugriff und -Submission als veraltet einstuft und implizites TLS für die Submission beschreibt. SMTP AUTH, standardisiert in RFC 4954, lässt einen Submission-Server einen Client über angekündigte Mechanismen authentifizieren. Verwenden Sie den aktuellen Hostnamen, Port, TLS-Modus und die Authentifizierungsanweisungen Ihres Providers, statt eine Kombination zu raten. Validieren Sie das Serverzertifikat und fallen Sie nicht stillschweigend auf Klartext zurück, wenn die Workload geschützte Submission verlangt. Bewahren Sie Passwörter oder Tokens in einem Secret-Manager auf, verwenden Sie je Umgebung getrennte Zugangsdaten und deaktivieren Sie veraltete Authentifizierungsmechanismen. TLS schützt einen Verbindungs-Hop; es authentifiziert den Nachrichtenautor nicht gegenüber jedem nachgelagerten Empfänger und ersetzt weder SPF, DKIM noch das DMARC-Identitäts-Alignment.

Einen Fehler bei Anwendungs-E-Mails Hop für Hop diagnostizieren

Beginnen Sie mit dem dauerhaften Ausgangsdatensatz der Anwendung: War das Produkt-Event autorisiert, und hat nur ein Job aus der Warteschlange es beansprucht? Prüfen Sie als Nächstes die Submission: DNS-Auflösung, TCP-Verbindung, TLS-Aushandlung, Zertifikatsvalidierung, Authentifizierung, Autorisierung des Envelope-Absenders, Antworten pro Empfänger und die abschließende DATA-Antwort. Hat der Submission-Dienst die Nachricht angenommen, hören Sie auf, die Anfrage blind erneut abzuspielen, und folgen Sie stattdessen ihrer Nachrichtenkennung und dem Event-Stream. Unterscheiden Sie einen vom Provider verarbeiteten Zustand von der Annahme durch den empfangenden Server. Ein späterer Bounce kann auch nach der ersten Annahme noch einen dauerhaften Fehler melden. Hat der empfangende Server die Nachricht angenommen, untersuchen Sie Authentifizierungsergebnisse, Reputation, Empfängerrichtlinie, Inhalt und Postfachklassifizierung, statt von einem SMTP-Transportfehler zu sprechen. Prüfen Sie sowohl Envelope- als auch Header-Identitäten und behalten Sie Zeitstempel, Antwortcodes, die Anzahl der Zustellversuche in der Warteschlange und Provider-Kennungen. Testen Sie mit kontrollierten Empfängern. Fügen Sie niemals produktive SMTP-Zugangsdaten oder vollständige Kundennachrichten in Tickets, Prompts, Terminal-Verläufe oder öffentliche Diagnose-Tools ein.

Annahme, Zustellung und Inbox Placement trennen

Protokollgenauigkeit ist in Produktoberflächen wichtig. Annahme durch die Anwendung heißt, dass das lokale System eine Anfrage erfasst hat. Annahme bei der Submission heißt, dass der erste Mailservice die Verantwortung für die Verarbeitung übernommen hat. Zustellung an den empfangenden Server heißt, dass der Ziel-SMTP-Server die Übergabe mit Erfolg beantwortet hat. Die Platzierung im Posteingang ist eine spätere Richtlinien- und Klassifizierungsentscheidung innerhalb der Empfängerumgebung. Eine Nachricht kann eine Stufe bestehen und an der nächsten scheitern oder anders eingeordnet werden. SMTP liefert direkte Nachweise zur aktuellen Transaktion und kann spätere Delivery-Status-Notifications erzeugen, gibt aber den endgültigen Ordner des Empfängers nicht preis. Speichern Sie diese Zustände unabhängig voneinander, statt jede 250-Antwort als Zustellung in den Posteingang zu bezeichnen. Ein Provider-Event mit der SMTP-Erfolgsantwort des Ziels kann den Zustand „an den Server zugestellt“ stützen. Ein Bounce stützt die Behandlung als Fehler oder Sperrung. Keines von beiden trägt ein Versprechen über Sichtbarkeit, Lesen oder Engagement. Dieses Modell hält den Status wahrheitsgemäß und verhindert unsichere Wiederholungen, nachdem die Verantwortung bereits übergegangen ist.

Dokumentierte API von SendHQ verwenden

Eine Anwendung kann SMTP über eine Provider-Bibliothek sprechen oder eine HTTP-E-Mail-API aufrufen, deren Provider darunter den Internet-Mailtransport übernimmt. SendHQ bietet eine auf den Workspace beschränkte E-Mail-API mit Prüfungen verifizierter Domains, Outbound- und Inbound-Nachrichtenressourcen, Events, Sperrlisten, Postfächern und Workspace-Ressourcengrenzen. Die HTTP-API kann strukturierte Anfragen, Kennungen und Events neben direkter SMTP-Submission bereitstellen. Sie verändert weder das Verhalten von Zielservern noch begründet sie SMTP-Annahme, Platzierung im Posteingang oder Empfänger-Engagement.

Häufig gestellte Fragen

Wofür steht SMTP?

SMTP steht für Simple Mail Transfer Protocol. Es legt fest, wie Mail-Clients und -Server ausgehende Nachrichten über Befehle, Antworten, Envelopes, Nachrichtendaten und Erweiterungen für Funktionen wie Authentifizierung und TLS einliefern und übertragen.

Wird SMTP verwendet, um E-Mails aus einem Posteingang zu lesen?

Nein. SMTP dient hauptsächlich dazu, ausgehende E-Mails einzuliefern und zu übertragen. Der Zugriff auf den Posteingang erfolgt über andere Schnittstellen wie IMAP, POP, eine providerspezifische Postfach-API oder eine E-Mail-API für Anwendungen, die gespeicherte eingehende Nachrichten bereitstellt.

Was ist der Unterschied zwischen den Ports 25, 587 und 465?

Port 25 wird üblicherweise für das Relay zwischen Servern verwendet. Port 587 ist der Standarddienst für die Nachrichteneinlieferung (Submission) und handelt häufig TLS aus. Port 465 ist für Submission über implizites TLS registriert. Halten Sie sich an den dokumentierten Endpunkt und den Sicherheitsmodus Ihres Providers, statt Ports probeweise zu wechseln.

Belegt ein SMTP-Erfolg, dass eine E-Mail im Posteingang angekommen ist?

Nein. Eine erfolgreiche Antwort belegt nur, dass der antwortende SMTP-Server den betreffenden Befehl oder die Verantwortung für die Nachricht akzeptiert hat. Das empfangende System kann anschließend noch Richtlinien anwenden, einen verzögerten Fehler erzeugen oder angenommene E-Mails außerhalb des Haupt-Posteingangs einordnen.

Sollte eine Anwendung jede 4xx-SMTP-Antwort wiederholen?

Ein 4xx-Code steht für ein vorübergehendes negatives Ergebnis, doch Wiederholungen sollten eine dauerhafte Warteschlange, exponentiellen Backoff mit Jitter, eine endliche Lebensdauer und empfängerbezogene Versuchsgrenzen verwenden. Untersuchen Sie wiederholte temporäre Fehler, statt unbegrenzt zu wiederholen.

Ist eine HTTP-E-Mail-API ein Ersatz für SMTP?

Sie kann SMTP im Anwendungscode ersetzen, der Provider verwendet für die Kommunikation mit den Mailsystemen der Empfänger aber normalerweise weiterhin SMTP. Eine API ergänzt oberhalb der Transportschicht strukturierte Authentifizierung, Payloads, Ressourcenberechtigungen, Kennungen und Event-Verarbeitung.

Quellen

Weiterlernen

Leitfaden zur E-Mail-API-Implementierung für ProduktteamsGestalten Sie eine sichere E-Mail-API-Integration mit verifizierten Domains, Sendungen über Warteschlangen, stabilen Kennungen, kontrollierten Wiederholungen, Zustell-Events, Sperrlisten und Mandantenisolation.