376 Milliarden E-Mails wurden 2025 weltweit täglich verschickt, laut dem Report Email Statistics Report 2024-2028 der Radicati Group. Jede einzelne davon durchläuft denselben Textdialog, der seit 1982 weitgehend unverändert geblieben ist. SMTP (Simple Mail Transfer Protocol) ist das Protokoll, das eine E-Mail von der Software des Absenders zum Server des Empfängers transportiert, gestützt auf eine Reihe kurzer Befehle, die über eine TCP-Verbindung ausgetauscht werden. Es kümmert sich weder um den Empfang noch um die Speicherung der Nachricht, zwei Aufgaben, die anderen Protokollen obliegen.
Was SMTP tatsächlich leistet, beschränkt sich auf drei Schritte: eine Verbindung zum richtigen Server öffnen, den Umschlag übermitteln, der angibt, wer sendet und an wen, und schließlich den Inhalt der Nachricht ausliefern. Der Rest der Kette beruht auf Schichten, die erst nachträglich hinzugefügt wurden, lange nach der Veröffentlichung des ursprünglichen Protokolls. Authentifizierung und Verschlüsselung bilden die erste Schicht, Spamfilterung und Sortierung im Posteingang die zweite.
Die Rolle von SMTP beim Versand einer E-Mail
Eine E-Mail durchläuft vier Etappen, bevor sie einen Posteingang erreicht, und SMTP deckt davon nur zwei ab. Der MUA, die E-Mail-Software, mit der der Absender seine Nachricht verfasst (Outlook, Gmail, Thunderbird), übergibt die Nachricht an einen MSA, den Server, der die Übermittlung akzeptiert, nachdem er die Identität des Absenders geprüft hat. Der MSA reicht die Nachricht anschließend an einen MTA weiter, der sie von Server zu Server relayt, bis sie den Server erreicht, der das Postfach des Empfängers hostet. Dieser letzte Server übergibt die Nachricht schließlich an einen MDA, der sie im betreffenden Postfach ablegt. SMTP steuert die beiden mittleren Glieder: die Übermittlung durch den MSA und den Transfer durch den MTA. Dieselbe Server-Software (Postfix, Exim, Microsoft Exchange) übernimmt in der Praxis häufig beide Rollen gleichzeitig, was die Unterscheidung im Alltag verwischt, am eigentlichen Befehlsaustausch aber nichts ändert.
RFC 5321 und RFC 5322: der Umschlag und die Nachricht
„The objective of the Simple Mail Transfer Protocol (SMTP) is to transfer mail reliably and efficiently.“ RFC 5321, IETF, 2008.
Zwei getrennte Standards regeln eine E-Mail, und die Verwechslung der beiden erklärt einen Großteil der Missverständnisse zur Zustellbarkeit. Die RFC 5321 regelt SMTP selbst: Sie definiert die Befehle, die Antwortcodes und die Transportregeln für den Umschlag. Die RFC 5322, im selben Monat, Oktober 2008, veröffentlicht, regelt einen anderen Gegenstand: das Format der transportierten Nachricht mit ihren Headern From, To, Subject, Date und Message-ID. Diese Trennung geht auf den allerersten Vorläufer des Protokolls zurück, die RFC 821, die im August 1982 von Jonathan Postel am Information Sciences Institute der University of Southern California veröffentlicht wurde. Sie wurde 2001 durch die RFC 2821 ersetzt, die ihrerseits 2008 durch die aktuelle RFC 5321 abgelöst wurde. Seitdem hat nichts eine vollständige Neufassung des Transports selbst erfordert, nur schrittweise Erweiterungen, die auf dasselbe Grundgerüst von Befehlen aufgesetzt wurden.
Die konkrete Konsequenz liegt in einem oft übersehenen technischen Detail: Die im Befehl MAIL FROM angegebene Adresse (der Umschlag, genannt 5321.From) und die im From-Feld der Nachricht angezeigte Adresse (der Header, genannt 5322.From) müssen keineswegs übereinstimmen. Ein Mailinglisten-Dienst, ein Kampagnen-Tracking-Tool oder ein Weiterleitungsmechanismus ändern legitim die eine, ohne die andere zu berühren. Genau diese Abweichung prüft SPF auf Umschlagseite. DKIM und DMARC hingegen befassen sich mit dem für den Empfänger sichtbaren Header, was erklärt, warum sich die drei Mechanismen ergänzen, statt sich zu überschneiden.
Der SMTP-Dialog, Befehl für Befehl
Öffnet man eine Klartext-Sitzung auf dem Übermittlungsport eines Mailservers, gleicht der Dialog einem sehr streng choreografierten Austausch von Höflichkeiten. Der Server antwortet zunächst mit dem Code 220, dem Zeichen, dass er die Verbindung akzeptiert. Der Client sendet EHLO, gefolgt von seinem eigenen Domainnamen, was seine Fähigkeit ankündigt, die erweiterte Version des Protokolls (ESMTP) zu sprechen, und im Gegenzug die Liste der verfügbaren Erweiterungen auslöst, etwa SIZE für die maximale Nachrichtengröße oder AUTH für die Authentifizierung. Es folgt MAIL FROM, das den Absender des Umschlags angibt, dann RCPT TO, das so oft wiederholt wird, wie es Empfänger gibt. Der Befehl DATA öffnet daraufhin das Fenster für die Übertragung des eigentlichen Inhalts, abgeschlossen durch eine Zeile, die nur aus einem einzigen Punkt besteht. Der Client beendet die Sitzung höflich mit QUIT.
Jede Etappe liefert einen dreistelligen numerischen Code zurück, der als Urteil gilt. Ein Code, der mit 2 beginnt, bedeutet Erfolg (250 für einen akzeptierten Befehl). Ein Code mit 3 lädt zur Fortsetzung ein, wie die 354, die den Beginn des DATA-Blocks erlaubt. Ein Code mit 4 signalisiert einen vorübergehenden Fehlschlag, der später erneut versucht werden sollte. Ein Code mit 5 schließt die Tür endgültig, ohne Möglichkeit einer Rückkehr für diese Nachricht. Dieses Raster umfasst nur vier Familien, nicht mehr. Es hat sich seit der ersten Spezifikation des Protokolls nicht verändert, obwohl sich das Volumen der ausgetauschten E-Mails seit 1982 um ein Vielfaches erhöht hat.
Übermittlung und Transfer: der zweistufige Weg
Übermittlung und Transfer folgen entgegengesetzten Logiken. Die Übermittlung läuft über einen MSA, der eine Authentifizierung (Benutzername und Passwort oder Token) verlangt, bevor er auch nur eine Nachricht akzeptiert: Ohne sie könnte jeder eine Absenderadresse missbrauchen. Der Transfer zwischen MTAs hingegen erfordert traditionell keine derartige Authentifizierung. Diese historische Lücke füllen SPF, DKIM und DMARC nachträglich, Jahrzehnte nach der Verfassung des ursprünglichen Protokolls.
Den SMTP-Server seines E-Mail-Kontos finden
Der Name des im Mail-Client anzugebenden SMTP-Servers hängt vom verwendeten E-Mail-Anbieter ab und nicht von einem universellen Standard. Gmail, Outlook, IONOS oder ein Shared-Hosting-Anbieter veröffentlichen jeweils eigene Serveradressen, mit Varianten je nachdem, ob es sich um eine geschäftliche Adresse oder ein Privatkonto handelt, manchmal auch je nach Abrechnungsland des Kontos. Diese Einstellung findet sich selten an derselben Stelle der Oberfläche, weshalb viele Nutzer sie bei jedem Wechsel der E-Mail-Software erneut suchen müssen. Wie man den SMTP-Server seines E-Mail-Kontos findet listet diese Adressen anbieterweise auf, samt Anleitung, wie man sie findet, wenn sie nicht dokumentiert sind.
Den richtigen SMTP-Port wählen
SMTP stützt sich historisch auf vier Ports: 25 für den Transfer zwischen Servern, 587 für die authentifizierte Übermittlung, 465 für eine von Beginn an verschlüsselte Verbindung und 2525 als Alternative, wenn ein Zugangsanbieter die vorherigen blockiert. Insbesondere Port 25 bleibt bei den meisten Privatverbindungen und in vielen Unternehmensnetzwerken standardmäßig geschlossen, um den Versand von Spam von kompromittierten Rechnern ohne Wissen ihrer Besitzer einzudämmen. Die Wahl des richtigen Ports hängt also ebenso von der verwendeten Software wie vom Netzwerk ab, aus dem der Versand tatsächlich erfolgt. Wie man den richtigen SMTP-Port bestimmt erläutert die Einsatzfälle für jeden Port je nach Versandkontext.
Über ein SMTP-Relay versenden
Ein Versand über einen eigenen Server setzt einem Reputationsrisiko aus: Eine einzige falsch konfigurierte Adresse genügt, um die Zustellbarkeit der gesamten Domain einbrechen zu lassen. Die meisten Unternehmen vertrauen den Versand deshalb einem externen SMTP-Relay an (Twilio SendGrid, Brevo, Amazon SES), das einen bereits eingelaufenen IP-Pool bündelt und das IP-Warmup für sie übernimmt. Die Wahl zwischen dedizierter und geteilter IP hängt vor allem vom monatlich versendeten Volumen ab. Die Funktionsweise eines SMTP-Relays erläutert diese Abwägungen im Detail.
SMTP-Authentifizierung: AUTH, STARTTLS, SPF, DKIM, DMARC, BIMI
Das ursprüngliche Protokoll sah weder Verschlüsselung noch Identitätsprüfung vor. Der später hinzugefügte Befehl AUTH verlangt Zugangsdaten, bevor eine Übermittlung akzeptiert wird. STARTTLS erlaubt anschließend, eine Klartextverbindung im Laufe der Sitzung auf eine verschlüsselte Verbindung umzuschalten, statt von vornherein einen verschlüsselten Kanal zu öffnen. Eine Designentscheidung, die bei den meisten Mailservern weltweit bis heute opportunistisch statt verpflichtend bleibt. Über dieser Transportschicht liegt ein Dreiklang, der sich für die Zustellbarkeit durchgesetzt hat. SPF prüft, ob der sendende Server berechtigt ist, für diese Domain zu versenden. DKIM signiert den Inhalt kryptografisch, und DMARC entscheidet über das Schicksal einer Nachricht, die bei beiden scheitert, bis hin zum DMARC Reject, der die nicht konforme E-Mail schlicht zurückweist. Die Details zu SPF, DKIM, DMARC und BIMI erklären, wie diese Schichten zusammenwirken, wobei BIMI am Ende der Kette die Anzeige eines verifizierten Logos in bestimmten Mail-Clients ergänzt. Das Google Postmaster Tools ist nach wie vor das gängigste Werkzeug, um zu beobachten, wie sich diese Einstellungen tatsächlich auf die Reputation einer Domain auswirken.
Was SMTP nicht leistet
SMTP endet bei der Zustellung der Nachricht auf dem Server des Empfängers. Es ruft niemals ein Postfach ab und speichert selbst nichts. Das Lesen, Sortieren und die Synchronisation zwischen Geräten obliegen IMAP und POP3, zwei Protokollen, die erst eingreifen, nachdem SMTP seine Arbeit beendet hat.
Antwortcodes und Versandfehler
Ein Code 550 als Antwort auf einen Befehl RCPT TO signalisiert einen Hard Bounce: Die Adresse existiert nicht oder der Server weist die Nachricht endgültig zurück. Ein Code 421 oder 450 entspricht einem Soft Bounce, einem vorübergehenden Fehlschlag (volles Postfach, nicht erreichbarer Server, erreichtes Ratenlimit oder aktiver temporärer Filter), den der versendende MTA nach seinem eigenen Deferral-Zeitplan automatisch erneut versucht. Aktuelle Versionen des Protokolls ergänzen diesen Code oft um einen Enhanced Status Code aus drei Ziffernblöcken, etwa 5.1.1 für eine nicht existierende Adresse, der die Ursache präzisiert, ohne die Art des Urteils zu ändern. Eine Falle bleibt bei Domains, die als Catchall konfiguriert sind: Der Server antwortet mit 250 für jede beliebige lokale Adresse, auch für ein Postfach, das nie existiert hat, was diesen Erfolgscode für die Beurteilung der tatsächlichen Gültigkeit einer Adresse irreführend macht. Die vollständige Liste der SMTP-Antwortcodes und die Details zu den Mechanismen von Hard Bounce und Soft Bounce helfen dabei, eine sich verschlechternde Kampagne präzise zu diagnostizieren. Eine ungültige Adresse, die Hard Bounces anhäuft, schädigt die Sender Reputation der versendenden IP, noch bevor ein Authentifizierungsproblem überhaupt ins Spiel kommt. Eine Prüfung der Liste vor dem Versand bleibt die einzige Möglichkeit, den tatsächlichen Schaden zu lokalisieren.
Grenzen und Weiterentwicklungen des Protokolls
SMTP wurde für ASCII-Text und Adressen in lateinischen Zeichen konzipiert, eine Entscheidung, die nicht-lateinische Alphabete bei E-Mail-Adressen von vornherein ausschloss. Die Erweiterung SMTPUTF8 behebt diesen Punkt, indem sie Adressen in Unicode erlaubt, doch ihre Verbreitung bleibt außerhalb einiger asiatischer Märkte marginal. Zwei weitere Entwicklungen versuchen, den Transport zwischen Servern abzusichern, dort wo STARTTLS optional bleibt: MTA-STS (Mail Transfer Agent Strict Transport Security) erzwingt Verschlüsselung über eine in DNS und HTTPS veröffentlichte Richtlinie, während DANE sich direkt auf DNSSEC stützt, um das Zertifikat des Empfängerservers zu authentifizieren. Weniger als 1 % der Domains der Top 1 Million veröffentlichen eine MTA-STS-Richtlinie, eine Quote, die sich zwischen 2024 und 2026 mehr als verdoppelt hat, ohne diese Schwelle je zu überschreiten (Uriports, 2026). Das Paradox liegt im Gewicht der großen Anbieter beim tatsächlichen Traffic: In den Niederlanden misst eine Zivver-Studie vom September 2025, dass bereits 19,1 % des E-Mail-Volumens über eine durch MTA-STS geschützte Verbindung laufen, fast vollständig getragen von Gmail und Hotmail. DANE bleibt eine technische Kuriosität: Seine Verbreitung hängt von DNSSEC ab, einem Baustein, den die Mehrheit der Hoster vorgelagert immer noch nicht ausgerollt hat, was den Mechanismus blockiert, noch bevor er beim Kunden überhaupt eine Chance auf Konfiguration hätte. Das Protokoll entwickelt sich am Rand weiter, nie durch einen kompletten Ersatz.
