Was ist ein SMTP-Server? Funktionsweise, Ports und Praxis erklärt

Kurz gesagt: Ein SMTP-Server ist die Maschine, die deine E-Mails ins Netz schickt. SMTP steht für Simple Mail Transfer Protocol und ist der Standard, mit dem Mailprogramme und Server seit den 1980er-Jahren miteinander reden. Dieser Artikel zeigt dir, wie das im Detail abläuft, welche Ports du brauchst, wie du Authentifizierung und Verschlüsselung sauber einrichtest und worauf du in der Praxis achten musst, damit deine Mails nicht im Spam-Ordner landen.

Was ist ein SMTP-Server überhaupt?

Wenn du in deinem Mailprogramm auf „Senden“ klickst, passiert im Hintergrund Folgendes: Dein Programm verbindet sich mit einem SMTP-Server, übergibt dort die Mail samt Empfänger – und der SMTP-Server kümmert sich um den Rest. Er sucht den zuständigen Mailserver des Empfängers heraus, stellt eine Verbindung dorthin her und übergibt die Mail wie ein digitaler Postbote.

Drei Rollen unterscheidet man:

• Mail User Agent (MUA) – dein Mailprogramm, also Outlook, Thunderbird, Apple Mail, ein Webmailer oder das Skript in deinem Shop.
• Mail Submission Agent (MSA) – der SMTP-Server, der Mails von Nutzern entgegennimmt. Er authentifiziert dich und reicht die Mail weiter.
• Mail Transfer Agent (MTA) – der SMTP-Server, der Mails zwischen Servern transportiert.

In kleinen Setups übernimmt eine einzige Software – etwa Postfix oder Exim – beide Rollen. In größeren Systemen sind sie sauber getrennt, weil unterschiedliche Sicherheits- und Performance-Anforderungen gelten.

Wie funktioniert SMTP? Der Handshake Schritt für Schritt

SMTP ist ein textbasiertes Protokoll. Du kannst es mit einem Telnet-Client oder openssl s_client sogar von Hand sprechen. Vereinfacht sieht ein typischer Mail-Versand so aus:

S: 220 mail.beispiel.de ESMTP Postfix
C: EHLO client.beispiel.de
S: 250-mail.beispiel.de
S: 250-STARTTLS
S: 250-AUTH LOGIN PLAIN
S: 250 SIZE 52428800
C: STARTTLS
S: 220 Ready to start TLS
[TLS-Handshake]
C: EHLO client.beispiel.de
S: 250 mail.beispiel.de
C: AUTH LOGIN
S: 334 VXNlcm5hbWU6
C: bWVpbi1iZW51dHplcg==
S: 334 UGFzc3dvcnQ6
C: bWVpbi1wYXNzd29ydA==
S: 235 Authentication successful
C: MAIL FROM:<absender@beispiel.de>
S: 250 Ok
C: RCPT TO:<empfaenger@andere-firma.de>
S: 250 Ok
C: DATA
S: 354 End data with <CR><LF>.<CR><LF>
C: From: Absender <absender@beispiel.de>
C: To: Empfänger <empfaenger@andere-firma.de>
C: Subject: Test
C:
C: Hallo Welt.
C: .
S: 250 Ok: queued as 7A3B4C5D6E
C: QUIT
S: 221 Bye

Was hier passiert, in Worten:

1. Begrüßung (EHLO): Der Client meldet sich, der Server zählt seine Fähigkeiten auf (Extensions wie STARTTLS, AUTH, SIZE, PIPELINING).
2. Verschlüsselung (STARTTLS): Die unverschlüsselte Verbindung wird auf TLS hochgestuft. Ab jetzt sind alle weiteren Befehle und der Mailinhalt verschlüsselt.
3. Authentifizierung (AUTH): Der Client weist sich aus. Üblich sind heute AUTH LOGIN oder AUTH PLAIN über TLS.
4. Umschlag (MAIL FROM / RCPT TO): Der Server lernt Absender- und Empfänger-Adresse. Achtung: Diese „Envelope“-Daten sind nicht zwingend identisch mit den From- und To-Headern in der Mail selbst.
5. Inhalt (DATA): Der Client schickt Header und Body, abgeschlossen mit einer Zeile, die nur aus einem Punkt besteht.
6. Verabschiedung (QUIT): Verbindung sauber schließen.

Das ist alles. SMTP ist bewusst einfach gehalten – die Komplexität liegt heute drumherum: TLS, Authentifizierung, Spam-Schutz, Reputation.

Welcher SMTP-Port wofür? 25, 465 und 587 erklärt

Drei Ports tauchen in der SMTP-Welt regelmäßig auf. Sie haben unterschiedliche Aufgaben – und wer sie verwechselt, wundert sich oft, warum der Mailversand nicht funktioniert.

Port 25 – Server-zu-Server

Port 25 ist der klassische SMTP-Port. Er wird heute fast ausschließlich für die Übergabe zwischen Mailservern genutzt – also wenn der MTA von Anbieter A die Mail an den MTA von Anbieter B weiterreicht. Für Endnutzer ist Port 25 die falsche Wahl: Viele Internet-Provider blockieren ausgehenden Traffic auf Port 25, um Spam aus ihren Netzen einzudämmen.

Port 587 – Submission mit STARTTLS

Port 587 ist der empfohlene Port für Mailprogramme. Die Verbindung startet unverschlüsselt und wird per STARTTLS auf TLS hochgestuft. Authentifizierung ist Pflicht. Wenn du Outlook, Thunderbird oder ein Skript einrichtest, ist 587 in fast allen Fällen die richtige Wahl.

Port 465 – Implicit TLS (SMTPS)

Port 465 wurde lange totgesagt, ist aber durch RFC 8314 wieder als „Submission over Implicit TLS“ standardisiert. Hier startet die Verbindung von Anfang an verschlüsselt, ohne STARTTLS-Schritt. Funktional gleichwertig zu 587 mit STARTTLS. Manche Anbieter empfehlen heute wieder 465, weil der TLS-Zwang von Anfang an einfacher zu erzwingen ist.

Faustregel: Mailprogramm? 587 oder 465. Server-zu-Server-Übergabe? 25.

Authentifizierung: Wer darf hier Mails verschicken?

Ein SMTP-Server, der ohne Authentifizierung Mails von beliebigen Absendern annimmt, heißt Open Relay – und ist das Lieblingswerkzeug von Spammern. Seit den frühen 2000ern ist das praktisch ausgestorben. Heute musst du dich beim Submission-Port mit Benutzername und Passwort ausweisen.

Die gängigen Verfahren:

• AUTH PLAIN – Benutzername und Passwort werden Base64-kodiert übertragen. Ohne TLS unsicher, mit TLS Standard.
• AUTH LOGIN – ähnlich PLAIN, aber zweistufig. Funktional kein Unterschied.
• AUTH CRAM-MD5 – Challenge-Response, niemals das Passwort im Klartext. Wird seltener, weil TLS das Problem ohnehin löst.
• OAuth2 (XOAUTH2) – moderner Ansatz, vor allem bei Google und Microsoft. Statt Passwort wird ein Token verwendet.

Praktischer Hinweis: Wenn dein Mailprogramm „Passwort wird unverschlüsselt gesendet“ meldet, prüf zuerst, ob TLS aktiv ist. Über eine TLS-Verbindung ist AUTH PLAIN völlig in Ordnung – außerhalb davon nicht.

DNS-Grundlagen: MX, A, PTR und SPF

SMTP funktioniert nur, weil das DNS dem sendenden Server sagt, an welche IP-Adresse er die Mail liefern soll. Drei Record-Typen sind dabei zentral:

MX-Record (Mail Exchange)

Der MX-Record einer Domain zeigt auf den Hostnamen des zuständigen Mailservers. Beispiel:

beispiel.de.    IN MX  10 mail.beispiel.de.
beispiel.de.    IN MX  20 mail2.beispiel.de.

Die Zahl davor ist die Priorität. Niedrigere Werte werden zuerst kontaktiert. Das ist nützlich, wenn du einen Backup-Mailserver bereitstellen willst.

A-Record

Der MX zeigt auf einen Hostnamen, der wiederum per A-Record auf eine IP-Adresse aufgelöst werden muss. Ein MX, der auf einen nicht existierenden Hostnamen zeigt, ist eine der häufigsten Fehlkonfigurationen.

PTR-Record (Reverse-DNS)

Wenn dein Mailserver bei example.com klopft, schaut Gegenseite zurück: Welcher Hostname gehört zur IP-Adresse, von der die Verbindung kommt? Stimmt das nicht überein, wandert die Mail im besten Fall in den Spam, im schlimmsten wird sie abgewiesen. PTR-Records vergibst du beim IP-Provider, nicht beim DNS-Hoster der Domain.

Reputation: SPF, DKIM und DMARC

Ein technisch funktionierender Mailversand ist nur die halbe Miete. Damit Gmail, Outlook und Co. deine Mails überhaupt im Posteingang zeigen, brauchst du Reputation – und die baut auf drei DNS-basierten Verfahren auf.

SPF – Sender Policy Framework

Im SPF-Record legst du fest, welche IPs oder Hosts überhaupt Mails für deine Domain verschicken dürfen. Beispiel:

beispiel.de.    IN TXT "v=spf1 mx a:mail.beispiel.de include:_spf.hostingplus.de -all"

Empfänger prüfen: Kommt die Mail wirklich von einer dieser Quellen? Wenn nicht, sieht es nach Spoofing aus. Das -all am Ende heißt: Alles andere ablehnen. Ein ~all wäre weicher (Softfail), ?all neutral – beides wird heute nicht mehr empfohlen.

DKIM – DomainKeys Identified Mail

DKIM signiert ausgehende Mails kryptografisch. Empfänger holen sich den öffentlichen Schlüssel aus einem speziellen DNS-TXT-Record und prüfen, ob die Signatur passt. Stimmt sie, ist sicher: Die Mail wurde von einem berechtigten System verschickt und unterwegs nicht verändert.

DMARC – die Klammer drumherum

DMARC sagt dem Empfänger, was er tun soll, wenn SPF oder DKIM fehlschlagen, und wohin er Reports schicken kann. Beispiel:

_dmarc.beispiel.de.    IN TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@beispiel.de; pct=100"

Hier sagt der Domain-Inhaber: Mails ohne gültige Authentifizierung sollen in die Quarantäne, und Reports gehen an dmarc@beispiel.de. Mit DMARC siehst du erstmals, wer in deinem Namen Mails verschickt – ein wichtiger Schritt gegen Phishing.

Pflicht seit 2024: Gmail und Yahoo verlangen für Versender mit mehr als 5.000 Mails am Tag SPF, DKIM und DMARC. Wer das nicht hat, fliegt zuverlässig raus. Auch für kleinere Versender ist die saubere Konfiguration heute Standard.

Inbound vs. Outbound: Zwei Seiten, die oft verwechselt werden

Wenn vom „Mailserver“ die Rede ist, sind oft zwei verschiedene Dinge gemeint:

• Outbound-SMTP: Wo gehen deine Mails raus? Das ist der Server, den dein Mailprogramm oder dein Skript für den Versand kontaktiert. Hier brauchst du Authentifizierung, hier gilt SPF/DKIM/DMARC für deine Domain.
• Inbound-SMTP: Wo kommen Mails für deine Domain an? Das wird über den MX-Record gesteuert. Dieser Server nimmt von der ganzen Welt anonym Mails entgegen, prüft sie auf Spam und legt sie in dein Postfach.

Beide Rollen können auf demselben Hostnamen liegen – müssen aber nicht. Gerade wenn du Mailversand und Mailempfang trennen willst (zum Beispiel Empfang bei deinem Hoster, Versand über einen spezialisierten Transaktions-Mail-Anbieter), liegen die Konfigurationen auseinander.

SMTP bei HostingPlus: Was du brauchst, wo du es findest

Bei jedem Hosting-Paket bei HostingPlus bekommst du Mailpostfächer mit eigenem SMTP-Zugang. Die Daten findest du im Kundenbereich unter dem jeweiligen Paket. Im Standardfall:

• Server: mail.deine-domain.de (sobald die DNS-Records gesetzt sind)
• Port: 587 mit STARTTLS oder 465 mit Implicit TLS
• Authentifizierung: komplette E-Mail-Adresse als Benutzername, Postfach-Passwort
• Verschlüsselung: TLS 1.2 oder TLS 1.3 – ältere Versionen sind deaktiviert

SPF und DKIM richten wir für deine Hauptdomain automatisch ein, sobald sie auf unsere Nameserver zeigt. DMARC empfehlen wir mit p=none zu starten, um erst einmal Reports zu sammeln, und dann auf p=quarantine oder p=reject zu erhöhen.

Häufige Probleme – und wie du sie löst

„Verbindung wird abgelehnt“ auf Port 25

Klassiker. Dein Internet-Provider blockiert ausgehenden Traffic auf Port 25. Lösung: Port 587 oder 465 verwenden.

„Authentifizierung fehlgeschlagen“

Meistens stimmt das Passwort nicht – oder du hast „nur den lokalen Teil“ als Benutzername eingegeben. Bei den meisten Mailservern ist die vollständige E-Mail-Adresse der Benutzername, nicht nur „benutzer“ ohne Domain.

Mails landen im Spam-Ordner

Erste Checks: SPF korrekt? DKIM aktiv und signiert das ausgehende System wirklich? PTR-Record passend? Mailtester wie mail-tester.com liefern in 30 Sekunden eine Diagnose. Wenn alles grün ist und es trotzdem nicht klappt, kann es ein Reputations-Problem deiner IP sein – passiert nach Phishing-Vorfällen oder bei zu aggressiven Marketingkampagnen.

„550 Sender address rejected“

Der Empfänger prüft den Absender. Häufige Ursachen: SPF-Record fehlt oder verbietet die sendende IP. Oder der Absender existiert gar nicht als gültige Adresse auf deiner Domain – manche Server prüfen das aktiv per Callout.

Timeouts beim DATA-Schritt

Wenn die Verbindung nach DATA hängt, ist meistens eine Firewall oder ein Anti-Spam-Filter im Spiel, der die ganze Mail in Echtzeit untersucht. Das kann je nach Anhang einige Sekunden dauern. Echte Timeouts deuten auf Routing-Probleme oder einen überlasteten Server hin.

SMTP testen – mit Bordmitteln

Du kannst SMTP von Hand sprechen. Auf einem Linux- oder Mac-Terminal:

openssl s_client -starttls smtp -crlf -connect mail.beispiel.de:587

Du siehst dann die Server-Antworten und kannst EHLO, AUTH, MAIL FROM, RCPT TO, DATA, QUIT von Hand schicken. Das ist Gold wert, wenn du verstehen willst, ob ein Problem am Mailprogramm, an der Authentifizierung oder am Server liegt.

Für AUTH brauchst du Benutzer und Passwort Base64-kodiert. Das geht in einer Zeile:

echo -n 'mein-benutzer' | base64
echo -n 'mein-passwort' | base64

FAQ

Brauche ich einen eigenen SMTP-Server?

Für die meisten Webseiten und Online-Shops nicht. Das Hosting-Paket bringt einen mit, und für Transaktionsmails (Bestellbestätigungen, Passwort-Resets) reicht das in den allermeisten Fällen. Einen eigenen SMTP-Server lohnt sich erst bei sehr hohen Volumina oder besonderen Compliance-Anforderungen.

Was ist der Unterschied zwischen SMTP und IMAP/POP3?

SMTP verschickt Mails. IMAP und POP3 holen sie ab. Beim Einrichten eines Mailprogramms brauchst du immer beides: einen SMTP-Server für ausgehende Mails und einen IMAP- oder POP3-Server für eingehende.

Warum heißt es noch „Simple“ Mail Transfer Protocol?

Weil das Kernprotokoll wirklich simpel ist – ein paar Befehle, klare Antworten. Die ganze Komplexität der modernen Mailwelt – TLS, Authentifizierung, Spam-Filter, DKIM-Signaturen, DMARC-Reports – steckt in den Erweiterungen drumherum.

Kann ich SMTP ohne TLS verwenden?

Technisch ja, in der Praxis nein. Jeder seriöse Empfänger verlangt heute TLS. Mailserver, die unverschlüsselt senden, haben de facto keine Reichweite mehr.

Was bedeutet „Open Relay“?

Ein SMTP-Server, der Mails von beliebigen Absendern an beliebige Empfänger weiterreicht, ohne Authentifizierung zu verlangen. Solche Server werden binnen Stunden von Spammern entdeckt und missbraucht – und landen anschließend auf jeder Blacklist. Heute akzeptiert kein Anbieter mehr Open Relays.

Fazit

SMTP ist alt, aber lebendig. Wer den Handshake einmal verstanden hat, weiß auch, warum eine Mail mal durchkommt und mal nicht. Die wichtigsten Stellschrauben sind heute nicht mehr im Protokoll selbst, sondern drumherum: Verschlüsselung, Authentifizierung, DNS-Records für Reputation. Wenn du diese drei Bereiche sauber konfigurierst, hast du auf Versender-Seite alles getan, was du tun kannst – der Rest liegt an Inhalt und Versandverhalten.

Du willst dir das Setup nicht selbst zusammenbasteln? Bei unseren Hosting-Paketen ist eine voll konfigurierte Mailumgebung mit SPF, DKIM und sauberer TLS-Konfiguration dabei – aufgesetzt von Leuten, die den Maschinenraum kennen.