5 SMTP-Irrtümer, die vielen E-Mail-Versendenden zum Stolperstein werden

SMTP gibt es seit 1982. Man sollte meinen, dass wir inzwischen alles verstanden hätten. Und doch lassen sich einige der hartnäckigsten Probleme bei der E-Mail-Zustellung auf eine Handvoll sturer Irrtümer darüber zurückführen, was SMTP eigentlich macht.

Das Protokoll hat eine Aufgabe – den Transport von E-Mails zwischen Servern – und diese Aufgabe erledigt es gut. Aber es authentifiziert nicht Ihre Identität, garantiert keine Posteingangsplatzierung, verschlüsselt Ihre Inhalte nicht standardmäßig und geht mit Bounces nicht so um, wie die meisten Absender vermuten. Zu verstehen, wo SMTP aufhört und alles andere beginnt, ist der Unterschied zwischen einer sauberen E-Mail-Infrastruktur und einer, die ständig brennt.

SMTP (Simple Mail Transfer Protocol) ist ein Transportprotokoll. Es überträgt E-Mails von einem Server zum anderen. Das ist seine gesamte Aufgabe. Stellen Sie sich SMTP wie den Auslieferungsfahrer vor, der ein Paket abholt und an der Laderampe des Gebäudes Ihres Empfängers absetzt. Was danach passiert – ob jemand zu Hause ist, ob das Paket durch die Sicherheitskontrolle kommt, ob es auf dem richtigen Schreibtisch landet –, liegt völlig außerhalb der Kontrolle des Fahrers.
SMTP steuert die Kommunikation zwischen Mailservern: die EHLO-Begrüßung, die Befehle MAIL FROM und RCPT TO, die Nachrichtenübertragung und die abschließende Antwort „250 OK“, die den erfolgreichen Empfang bestätigt. Sobald diese 250 eintrifft, betrachtet SMTP seine Arbeit als erledigt. Ob die Nachricht im Posteingang, im Spam-Ordner oder gar nirgends ankommt, ist eine andere Frage – und genau da liegen die meisten Irrtümer. Wenn Sie mehr über den vollständigen SMTP-Versandprozesserfahren möchten, haben wir ihn hier ausführlich beschrieben.

Dies ist wahrscheinlich das teuerste Missverständnis beim Thema E-Mail. Eine 250 OK-Antwort von einem empfangenden Server bedeutet, dass der Server Ihre Nachricht akzeptiert hat – nicht, dass er sie in den Posteingang zugestellt hat. Der empfangende Server kann nach der Annahme mit der Nachricht tun, was er will: sie als Spam filtern, in Quarantäne verschieben oder stillschweigend verwerfen.

SMTP arbeitet auf der Transportschicht. Die Posteingangsplatzierung ist eine Frage der Zustellbarkeit, die durch die Absenderreputation, Authentifizierungssignale, den Engagement-Verlauf und Inhaltssignale gesteuert wird – nichts davon berührt SMTP direkt. Wenn Sie eine Fehlerbehebung bei niedrigen Öffnungsraten oder hoher Spam-Platzierung durchführen, sollten Sie sich nicht nur die SMTP-Protokolle ansehen. Sehen Sie sich Ihre Absenderreputation, Ihre Authentifizierung und die Qualität Ihrer Empfängerlisten an. Unser Leitfaden zu den häufigsten Mythen rund um die E-Mail-Zustellbarkeit ist ein guter Ausgangspunkt, um mit verbreiteten Missverständnissen aufzuräumen.

Als SMTP entstand, war das Internet noch eine vertrauensvollere Welt. Ursprünglich konnte das Protokoll gar nicht prüfen, ob ein Absender echt ist – die Angabe bei MAIL FROM wurde einfach als gegeben hingenommen. Deshalb ist E-Mail-Spoofing seit Jahrzehnten ein Problem.

Die Authentifizierung ist SMTP überlagert, nicht darin integriert. SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail) und DMARC (Domain-based Message Authentication, Reporting, and Conformance) arbeiten alle unabhängig vom SMTP-Handshake. SMTP AUTH – der Mechanismus, der einen Benutzernamen und ein Passwort erfordert, bevor Ihr E-Mail-Client eine Nachricht übergibt – ist ebenfalls ein separates Add-on, das in RFC 4954 und nicht in der SMTP-Kernspezifikation definiert ist.
Was das in der Praxis bedeutet: Ein 250 OK von einem empfangenden Server bestätigt nicht, dass Ihre Authentifizierungseinträge in Ordnung sind. Sie können eine Nachricht erfolgreich über SMTP übertragen und dennoch als Junk eingestuft oder abgelehnt werden, weil Ihr SPF-Eintrag fehlerhaft ist oder Ihre DKIM-Signatur nicht verifiziert werden kann. Sorgen Sie also zuerst für eine saubere Authentifizierung – SMTP allein reicht dafür nicht aus. Unser In unserem Leitfaden zur E-Mail-Authentifizierung zeigen wir Ihnen, wie Sie SPF, DKIM und DMARC von Anfang an richtig einrichten.

Standardmäßig versendet klassisches SMTP alles im Klartext, also unverschlüsselt. E-Mail-Kopfzeilen, Nachrichteninhalt, Anmeldedaten: All das könnte von Dritten mitgelesen werden, die die Verbindung überwachen. Im frühen Internet war das kein kritisches Anliegen; heute ist es ein ernstes Problem.
Die Verschlüsselung kam später als separate Schicht hinzu. Zwei Optionen decken die meisten Versandszenarien ab:

STARTTLS
STARTTLS ist eine Protokollerweiterung, mit der ein Client eine bestehende unverschlüsselte SMTP-Verbindung per Upgrade in eine verschlüsselte umwandeln kann. Es wird auf den Ports 25 und 587 unterstützt. Das Schlüsselwort lautet „Upgrade“ – wenn der empfangende Server STARTTLS nicht unterstützt, kann die Verbindung auf Klartext zurückfallen. Dies wird manchmal als opportunistisches TLS bezeichnet und ist der gängigste Ansatz, wenn E-Mails von Server zu Server weitergeleitet werden.

SMTPS (implizites TLS)
SMTPS baut von Anfang an eine TLS-verschlüsselte Verbindung auf – eine unverschlüsselte Phase gibt es hier gar nicht erst. Es läuft über Port 465 (für die Übermittlung vom Client zum Server) und ist die sicherere Option, wenn beide Seiten es unterstützen. Das praktische Fazit: Konfigurieren Sie Ihren Versand stets so, dass TLS genutzt wird, und stellen Sie sicher, dass Ihr ESP dies auch durchsetzt. Unser ausführlicher Beitrag zu SMTP-Ports beleuchtet die Sicherheitsaspekte der jeweiligen Portwahl. Gehen Sie nicht davon aus, dass die Verbindung verschlüsselt war, nur weil Ihre Nachricht akzeptiert wurde.

Port 25 ist der ursprüngliche SMTP-Port und stammt aus dem Jahr 1982. Genau dieser Port bereitet inzwischen aber die meisten Schwierigkeiten.
Weil Spam-Versender diesen Port besonders gerne missbrauchen, sperren viele Internetanbieter und Hosting-Provider ausgehenden Traffic über Port 25 auf Nicht-Server-Netzwerken. Wenn Sie eine Anwendung erstellen, die E-Mails versendet, und Sie über Port 25 routen, werden Sie in vielen Netzwerken auf Verbindungsfehler stoßen und Ihre Nachrichten werden nicht gesendet.
Diese Ports, sollten Sie kennen:

Port 587: Der moderne Standard für die authentifizierte E-Mail-Übermittlung (SMTP mit STARTTLS). Verwenden Sie diesen in fast allen Fällen für die Übermittlung vom Client zum Server.
Port 465: Eine Zeit lang veraltet, wird jetzt aber häufig für SMTPS (implizites TLS) verwendet. Viele ESPs, einschließlich Mailgun, unterstützen ihn.
Port 2525: Eine praktische Alternative, wenn 587 blockiert ist. Mailgun bietet diese Option an.
Port 25: Nur für die Weiterleitung zwischen Servern. Nicht für die Client-Übermittlung geeignet. Wird häufig blockiert.

Mehr zur Geschichte der einzelnen Ports und eine klare Empfehlung für Ihre Konfiguration finden Sie in unserem SMTP-Port-Leitfaden.

Dieser Mythos taucht oft auf, wenn Teams ihre ESP-Kosten senken oder die E-Mail-Infrastruktur intern behalten wollen. Auf den ersten Blick klingt das plausibel: Wie schwer kann es schon sein, einen eigenen SMTP-Server zu betreiben?

In der Praxis führt eine eigene SMTP-Infrastruktur oft schneller als gedacht zu Zustellproblemen – meist, ohne dass der Grund dafür klar ist. Der Betrieb eines eigenen Servers bedeutet, dass Sie für alles verantwortlich sind, was SMTP nicht abdeckt: IP-Warm-up, Verarbeitung von Bounces und Beschwerden, Verwaltung der Sperrliste, Registrierung von Feedbackschleifen bei großen E-Mail-Anbietern, Wartung von TLS-Zertifikaten, Blocklisten-Überwachung und die Einhaltung der sich entwickelnden Absenderanforderungen von Gmail, Yahoo und Microsoft. Das ist praktisch ein Vollzeitjob – wofür ESPs längst ausgereifte Tools entwickelt haben.

Abgesehen vom operativen Aufwand befinden sich selbstverwaltete Server häufig in Blöcken mit geteilten IP-Adressen mit schlechter Reputation, und neue IP-Adressen stehen vor großen Hürden bei der Posteingangsplatzierung, bis ein Warm-up einen Versandverlauf etabliert hat.

Für die meisten Teams nimmt SMTP-Relay die komplexe Infrastrukturarbeit ab und liefert direkt Logs, Analysen und Zustellbarkeits-Tools mit, die man sonst selbst bauen müsste. Überlegen Sie, ob SMTP weiterhin die richtige Wahl ist oder ein Umstieg auf eine API-Integration sinnvoller wäre? Unser Vergleich SMTP vs. API zeigt die Vor- und Nachteile beider Optionen.

SMTP ist nicht der Feind. Seit über 40 Jahren sorgt dieses erstaunlich robuste Protokoll dafür, dass E-Mails ihr Ziel erreichen. Wer versteht, was SMTP wirklich leistet, legt damit den Grundstein für ein sauberes Versand-Setup.

Die Kurzfassung: SMTP bewegt Ihre Nachricht von Punkt A nach Punkt B. Alles andere – Posteingangsplatzierung, Authentifizierung, Verschlüsselung, Bounce-Management – liegt in Ihrer Verantwortung und muss zusätzlich konfiguriert werden. Die gute Nachricht: Mit moderner E-Mail-Infrastruktur, von Authentifizierungsprotokollen bis zu verwalteten Relay-Diensten, lässt sich dieser Aufbau problemlos umsetzen – man muss nur wissen, wo man anfängt.

Wenn Sie einen bestimmten Fehler beim Versenden beheben möchten, hilft Ihnen unser Leitfaden zu SMTP-Fehlercodes dabei, genau zu entschlüsseln, was der empfangende Server Ihnen mitteilt, und wie Sie das Problem beheben können.

Author: The Sinch Mailgun team The Sinch Mailgun team shares news, best practices, and strategies to take your products and apps to the next level using email. Subscribe to our newsletter to get all the articles in your inbox!