Welche E-Mail-Serverdaten, Ports und Verschlüsselung brauche ich für IMAP, POP3 und SMTP?

Serverrollen und Protokolle: IMAP vs. POP3, SMTP und die Bedeutung von Hostname, Benutzername und Domain

E-Mail-Programme und Mail-Apps sprechen nicht „E-Mail“ als einheitliches Protokoll, sondern kombinieren mehrere Dienste mit klar getrennten Aufgaben: Ein Server nimmt Nachrichten an, ein anderer stellt Postfächer bereit, und ein Client (App) authentifiziert sich mit passenden Zugangsdaten. Missverständnisse entstehen häufig dort, wo Rollen vermischt werden: Der Posteingang funktioniert, aber der Versand scheitert – oder umgekehrt. Ursache sind dann meist falsch gewählte Protokolle, Hostnamen oder Benutzernamen, weniger ein „defektes Konto“.

Serverrollen im Mailverkehr: Postfach vs. Versand

Für den Abruf und die Synchronisation des Postfachs kommen IMAP oder POP3 zum Einsatz. Für den Versand wird SMTP genutzt. Diese Trennung ist nicht nur historisch bedingt, sondern technisch sinnvoll: IMAP/POP3 müssen Postfächer verwalten und Inhalte ausliefern, SMTP ist auf die zuverlässige Übergabe von ausgehenden Nachrichten ausgelegt (inklusive Weiterleitung zwischen Mailservern). Viele Anbieter betreiben dafür unterschiedliche Servernamen oder zumindest unterschiedliche Dienste unter demselben Host.

In der Praxis bedeutet das: In einer Konto-Konfiguration existieren mindestens zwei Verbindungen mit jeweils eigenem Port und eigener Verschlüsselungsart. Selbst wenn der Hostname identisch ist, unterscheiden sich Protokoll und Port. Wer versehentlich einen SMTP-Hostname als IMAP-Server einträgt, erhält je nach Client „Zeitüberschreitung“, „Handshake fehlgeschlagen“ oder einen Authentifizierungsfehler, weil der erwartete Dienst dort nicht antwortet.

IMAP vs. POP3: Funktionsprinzip und typische Einsatzmuster

IMAP ist der Standard für die Nutzung eines Postfachs auf mehreren Geräten. Nachrichten verbleiben serverseitig, Ordner werden synchronisiert, und Statusinformationen wie „Gelesen“, „Markiert“ oder „Gelöscht“ werden zwischen Clients abgeglichen. POP3 ist dagegen auf den klassischen Abruf ausgelegt: Nachrichten werden vom Server heruntergeladen; je nach Einstellung verbleiben sie zusätzlich auf dem Server oder werden nach dem Abruf entfernt. POP3 kennt keine Ordnerstruktur wie IMAP und kann Statusänderungen nur eingeschränkt abbilden.

Für private Nutzung mit Smartphone, Notebook und ggf. Tablet ist IMAP in der Regel die robustere Wahl. POP3 kann sinnvoll sein, wenn ein einzelnes Gerät als „Archiv“ dienen soll und der Anbieter nur wenig Speicher bereitstellt. Entscheidend ist, dass die gewählte Methode zum eigenen Nutzungsmodell passt, weil ein späterer Wechsel zwar möglich ist, aber lokale Ablagen, Ordnerzuordnung und Löschregeln dann oft nachgearbeitet werden müssen.

• IMAP (Eingang): Serverseitige Synchronisation von Nachrichten und Ordnern, geeignet für mehrere Geräte; setzt meist SSL/TLS oder STARTTLS voraus.
• POP3 (Eingang): Abrufmodell mit optionalem „Kopie auf dem Server belassen“; keine echte Ordnersynchronisation, daher in Mehrgeräte-Szenarien fehleranfälliger.
• SMTP (Ausgang): Zuständig für Versand und Übergabe ausgehender Mails; verlangt bei den meisten Providern Authentifizierung (SMTP AUTH) und passende Verschlüsselung.

SMTP: Submission, Portlogik und warum „SMTP ist kaputt“ oft ein Login-Thema ist

Beim Versand ist weniger die Zustellung im Internet das Problem, sondern die Einlieferung (Submission) beim Anbieter. Moderne Setups nutzen dafür typischerweise Port 587 mit STARTTLS oder Port 465 mit implizitem TLS. Port 25 ist primär für Server-zu-Server-Transport reserviert und bei Privatanschlüssen häufig gesperrt oder ungeeignet, selbst wenn einzelne Clients ihn noch anbieten. Wenn der Versand scheitert, liegt die Ursache häufig in einer falschen Port-/TLS-Kombination oder in fehlender Authentifizierung: Der Server akzeptiert keine Mails ohne gültigen Login oder lehnt Absenderdomains ab, die nicht zum Konto passen.

Zusätzlich spielt der Absender eine Rolle: Viele Anbieter verlangen, dass die sichtbare „Von“-Adresse zur authentifizierten Mailbox gehört oder zumindest als Alias freigegeben ist. Andernfalls erscheinen Meldungen wie „Relaying denied“ oder „Sender address rejected“. Das wirkt wie ein SMTP-Problem, ist aber meist eine Policy-Prüfung nach erfolgreicher Verbindung.

Hostname, Benutzername und Domain: typische Stolperstellen bei der manuellen Einrichtung

Der Hostname ist die Adresse des Mailservers (z. B. imap.beispiel.de oder mail.provider.tld). Er ist nicht automatisch identisch mit der eigenen Domain der E-Mail-Adresse. Bei vielen Providern gehört die Domain der Adresse zu einem Marken- oder Kundenalias, während die Server unter einer festen Provider-Domain laufen. Autokonfigurationen (z. B. über DNS-Autodiscover-Mechanismen oder Profile) verschleiern diese Details; bei manueller Einrichtung müssen Hostnamen jedoch exakt stimmen, inklusive Schreibweise und Punktsetzung.

Der Benutzername ist ebenfalls nicht immer die E-Mail-Adresse. Manche Anbieter erwarten die vollständige Adresse als Login (name@domain.tld), andere eine Kundennummer, ein separates Postfach-Login oder nur den lokalen Teil (name). Das Passwort kann wiederum ein normales Kontopasswort sein oder – bei aktivierter Zwei-Faktor-Anmeldung – ein App-Passwort, das pro Gerät/Anwendung erzeugt wird. Ein korrektes Passwort mit falschem Benutzernamen führt häufig zu identischen Fehlermeldungen wie ein falsches Passwort, weshalb eine saubere Zuordnung entscheidend ist.

• Hostname (Servername): Muss zum jeweiligen Dienst passen, etwa imap.example.tld für IMAP und smtp.example.tld für SMTP; ein vertauschtes Feld endet oft in Connection timed out oder Server not responding.
• Benutzername: Je nach Anbieter entweder vollständige Adresse (vorname.nachname@domain.tld), Kunden-ID oder Postfachname; bei Unsicherheit in den Kontodaten des Providers prüfen, nicht aus der Adresse „ableiten“.
• Domain (Kontext): Bestimmt die sichtbare Absenderadresse und kann für Serverrichtlinien relevant sein (z. B. Absenderprüfung); die Domain ist jedoch nicht automatisch der Serverhost.
• App-Passwort bei 2FA: Wird häufig für klassische IMAP/SMTP-Clients benötigt, wenn das Hauptkonto mit Zwei-Faktor-Anmeldung geschützt ist; das App-Passwort ersetzt dann das normale Passwort im Client.

Ports und Verschlüsselung: SSL/TLS, STARTTLS, typische Standardwerte und wie sie in Clients benannt sind

Bei der manuellen E‑Mail-Konfiguration entscheidet die Kombination aus Port, Verschlüsselungsmodus und Authentifizierung darüber, ob eine Verbindung aufgebaut wird und ob sie den Sicherheitsanforderungen moderner Provider genügt. In der Praxis entstehen viele Fehlkonfigurationen weniger durch „falsche Servernamen“ als durch uneinheitliche Client-Bezeichnungen: Was in einem Programm als „SSL“ erscheint, heißt anderswo „TLS/SSL“ oder „verschlüsselte Verbindung (implizit)“, während STARTTLS oft als „TLS (wenn verfügbar)“ oder „STARTTLS“ angeboten wird. Technisch geht es dabei um zwei unterschiedliche Muster: TLS direkt beim Verbindungsaufbau (implizites TLS) oder TLS als Upgrade innerhalb einer bestehenden Klartextverbindung (STARTTLS).

Standardports für IMAP, POP3 und SMTP (und was „sicher“ konkret bedeutet)

Für den Posteingang sind IMAP und POP3 gebräuchlich, für den Versand SMTP. Historisch existieren pro Protokoll jeweils ein „Klartext-Port“ und ein „TLS-ab-Start-Port“. Viele Anbieter akzeptieren auf den Klartext-Ports nur noch STARTTLS und verweigern unverschlüsselte Logins. Clients zeigen diese Varianten nicht immer als Portpaar an, sondern koppeln Port und Sicherheit über Auswahllisten. Ein häufiger Stolperstein: „TLS“ wird fälschlich mit STARTTLS gleichgesetzt, obwohl in manchen Oberflächen „TLS“ die implizite TLS-Variante meint.

Port 25 gehört technisch ebenfalls zu SMTP, ist für Privatnutzer in Mail-Apps jedoch in der Regel unpassend: Viele Zugangsnetze blockieren ihn, und Provider erwarten für die Abgabe von E‑Mails meist den Submission-Dienst über 587 oder 465 mit Authentifizierung. In Clients findet sich 587 oft zusammen mit „STARTTLS“ als Standardvorschlag, während 465 eher in Assistenten auftaucht, die „SSL“ als Option priorisieren.

Implizites TLS vs. STARTTLS: Ablauf, Risiken bei falscher Wahl, Erkennung im Client

Bei implizitem TLS startet die Verbindung sofort als TLS-Session; ohne TLS kommt keine sinnvolle Protokollkommunikation zustande. STARTTLS beginnt dagegen im Klartext, schaltet dann per Protokollkommando auf TLS um. Wird STARTTLS auf einem Port konfiguriert, der implizites TLS erwartet, scheitert der Handshake häufig mit Meldungen wie „falsche Versionnummer“ oder „Handshake fehlgeschlagen“. Umgekehrt führt „SSL/TLS“ auf einem STARTTLS-Port oft zu sofortigen Verbindungsabbrüchen, weil der Server anfangs Klartext-Protokollbanner sendet, der Client jedoch TLS-Daten erwartet.

Sicherheitsrelevant ist weniger, ob STARTTLS oder implizites TLS genutzt wird, sondern dass TLS tatsächlich erzwungen und das Zertifikat geprüft wird. Seriöse Clients prüfen Hostnamen und Vertrauenskette; bei abweichenden Servernamen (etwa mail.beispiel.tld statt imap.beispiel.tld) entstehen Zertifikatswarnungen. Ein „Trotzdem verbinden“-Klick umgeht Schutzmechanismen und sollte in der Konfiguration nicht als Normalzustand verbleiben.

• Implizites TLS (sofort verschlüsselt): Typisch bei IMAP 993, POP3 995, SMTP 465; Client-Optionen lauten häufig „SSL“, „SSL/TLS“ oder „TLS/SSL“.
• STARTTLS (Upgrade auf TLS): Typisch bei IMAP 143, POP3 110, SMTP 587; Client-Optionen heißen „STARTTLS“, „TLS“ oder „TLS (wenn verfügbar)“. „Wenn verfügbar“ ist schwächer als „erforderlich“, sofern der Client eine entsprechende Unterscheidung anbietet.
• Zertifikatsprüfung und Servername: Der eingetragene Hostname (z. B. imap.provider.tld) muss zum Zertifikat passen; bei Zertifikatsfehlern erscheinen Hinweise wie „Hostname stimmt nicht überein“ oder „Zertifikat nicht vertrauenswürdig“.

Wie Clients Felder und Modi benennen: typische Zuordnungen ohne Missverständnisse

Mail-Programme bündeln mehrere technische Parameter in vereinfachten Dropdowns. Hinter „Sicherheitstyp“ steckt die Wahl zwischen implizitem TLS und STARTTLS; hinter „Port“ steckt oft eine automatisch nachgezogene Zahl. Bei SMTP kommt hinzu, dass manche Oberflächen nicht von „SMTP“, sondern von „Ausgangsserver“ sprechen und darunter zusätzlich „Anmeldung erforderlich“ oder „Authentifizierungsmethode“ führen. Werden diese Felder nicht konsistent gesetzt, wird zwar TLS aufgebaut, aber der Server lehnt den Versand wegen fehlender Authentifizierung ab.

Besonders uneinheitlich ist die Beschriftung „TLS“: In manchen Clients bedeutet „TLS“ ausschließlich STARTTLS, in anderen steht „TLS“ für implizites TLS und „STARTTLS“ ist separat. Verlässlich ist die Kopplung mit dem Port: 993/995/465 deuten nahezu immer auf implizites TLS, 143/110/587 auf STARTTLS. Wo ein Client „Automatisch“ anbietet, ist das Ergebnis in der Regel korrekt, solange Port und Servername stimmen; bei manueller Eingabe sollte „Automatisch“ jedoch nicht mit „beliebig“ verwechselt werden, da einige Programme dann auf unsichere Fallbacks ausweichen könnten, falls der Server falsch angegeben wurde.

Typische Fehlermeldungen bei Port-/TLS-Mismatch und ihre technische Ursache

Fehlertexte variieren stark nach Betriebssystem und Bibliothek, folgen aber wiederkehrenden Mustern. Ein Port-/TLS-Mismatch wirkt häufig wie ein „Zertifikatsproblem“, obwohl der TLS-Handshake gar nicht sauber startet. Umgekehrt kann ein Zertifikatsfehler wie ein „Login fehlgeschlagen“ erscheinen, wenn der Client aus Sicherheitsgründen den Verbindungsaufbau abbricht, bevor Anmeldedaten gesendet werden. Für die Eingrenzung hilft die Trennung: „Kann keine Verbindung aufbauen“ spricht eher für Netzwerk/Port/TLS; „Authentifizierung fehlgeschlagen“ spricht eher für Benutzername/Passwort/Methoden, obwohl beides zusammen auftreten kann.

• Handshake-/Protokollfehler: Meldungen wie „TLS-Handshake fehlgeschlagen“, „wrong version number“, „protocol error“ deuten häufig auf „STARTTLS“ auf 993/995/465 oder „SSL/TLS“ auf 143/110/587.
• Timeout oder keine Verbindung: Hinweise wie „Zeitüberschreitung“, „Server nicht erreichbar“ können durch falschen Port (z. B. 25 statt 587), Firewall/Provider-Blocking oder falschen Hostnamen entstehen; bei Mobilfunknetzen kommt Portfiltering gelegentlich vor.
• Zertifikatswarnungen: Texte wie „Zertifikat abgelaufen“, „nicht vertrauenswürdig“, „Name stimmt nicht überein“ weisen auf eine fehlerhafte Hostname-Zuordnung oder eine unterbrochene Vertrauenskette hin; Eingaben wie imap.provider.tld vs. mail.provider.tld sind ein typischer Auslöser.
• Server lehnt AUTH ab: Meldungen wie „Authentication required“ oder „Relay access denied“ treten oft auf, wenn bei SMTP die Option „Server erfordert Anmeldung“ deaktiviert ist oder als Methode „Keine“ statt LOGIN/PLAIN/OAuth2 gewählt wurde (Bezeichnungen variieren).

Für eine belastbare Konfiguration gilt: Port und Sicherheitsmodus müssen zueinander passen, und der Servername muss zum Zertifikat gehören. Erst danach lohnt die Feineinstellung von Authentifizierungsoptionen, weil viele scheinbare Passwortprobleme tatsächlich schon vorher auf der Transportschicht entstehen.

Authentifizierung und Fehlersuche: Passwort vs. App-Passwort, OAuth2/2FA sowie häufige Fehlermeldungen und ihre Ursachen

Warum die Anmeldung scheitert: Authentifizierung ist nicht gleich Verschlüsselung

Bei E-Mail-Konten werden zwei Ebenen häufig verwechselt: die Transportverschlüsselung (SSL/TLS oder STARTTLS) und die eigentliche Anmeldung am Server. SSL/TLS entscheidet, ob Benutzername und Geheimnis vor dem Mitlesen geschützt übertragen werden. Ob die Anmeldung akzeptiert wird, hängt dagegen vom vom Provider geforderten Verfahren ab: klassisches Passwort, App-Passwort (bei aktivierter Zwei-Faktor-Anmeldung) oder moderne Token-basierte Verfahren wie OAuth2.

Viele Provider sperren „reine Passwort-Anmeldung“ für IMAP/SMTP teilweise oder vollständig, wenn das Konto mit 2FA abgesichert ist oder wenn die App kein modernes Verfahren unterstützt. Das führt zu Fehlermeldungen, obwohl Servername, Port und Verschlüsselung korrekt wirken. Eine zusätzliche Stolperfalle ist der Benutzername: teils gilt die vollständige E-Mail-Adresse, teils eine separate Kennung. Schon ein fehlendes Alias oder ein Tippfehler reicht, um Authentifizierungsfehler zu erzeugen, die wie Passwortprobleme aussehen.

Passwort, App-Passwort, OAuth2: Einsatzfälle und typische Anforderungen

Ein Konto mit aktiviertem zweiten Faktor akzeptiert das normale Kontopasswort bei „Basic Auth“ oft nicht mehr. In diesem Fall wird ein App-Passwort (auch „Anwendungspasswort“) benötigt: ein separates, langes Einmal-Passwort, das nur für klassische IMAP/SMTP-Anmeldungen gedacht ist. Alternativ setzen aktuelle Clients auf OAuth2: Die App erhält dabei kein dauerhaftes Passwort, sondern ein zeitlich begrenztes Zugriffstoken, das nach interaktiver Anmeldung (Browserfenster) ausgegeben wird.

OAuth2 ist aus Sicherheits- und Compliance-Sicht die bevorzugte Option, setzt aber voraus, dass der Client es implementiert und der Provider es für IMAP/SMTP freigeschaltet hat. App-Passwörter sind ein Kompromiss für ältere Clients oder Geräte, die keinen Browser-Login unterstützen. Sie sollten getrennt pro Gerät vergeben und bei Geräteverlust umgehend widerrufen werden.

• Benutzername: Häufig identisch mit der vollständigen Adresse, z. B. vorname.nachname@example.de; bei manchen Providern stattdessen eine Kontokennung oder ein primäres Alias.
• App-Passwort generieren: Erfolgt im Sicherheitsbereich des Kontos; nach der Erstellung wird es typischerweise nur einmal angezeigt und sollte als eigener Eintrag pro Gerät geführt werden (z. B. „Laptop-IMAP“).
• OAuth2 in Clients: In Einstellungen oft als Authentifizierungstyp OAuth2 oder Modern Authentication auswählbar; bei SMTP zusätzlich auf „Server erfordert Anmeldung“ achten.

Häufige Fehlermeldungen: Bedeutung, Ursachen, erste Gegenprüfungen

Fehlermeldungen wirken je nach Betriebssystem und App sehr unterschiedlich, lassen sich aber meist auf wenige Ursachen zurückführen: falsches Geheimnis (Passwort/App-Passwort), falscher Benutzername, unpassender Authentifizierungstyp, blockierter Zugriff durch Sicherheitsrichtlinien oder eine Verschlüsselungs-/Port-Fehlkombination. Wichtig ist die Trennung zwischen „Verbindung zum Server“ und „Anmeldung am Server“: Zeitüberschreitungen und TLS-Fehler sind Transportprobleme, während „Authentication failed“ meist erst nach erfolgreichem Verbindungsaufbau auftritt.

Geräteübergreifende Checkliste für zielgerichtete Fehlersuche

Eine saubere Diagnose beginnt mit der Frage, welcher Schritt fehlschlägt: DNS/Servername, TCP-Port, TLS-Aufbau oder Authentifizierung. Viele Clients protokollieren das nur knapp; deshalb hilft ein strukturiertes Vorgehen. Bei wiederholten Fehlversuchen sperren einige Provider Anmeldungen temporär oder verlangen eine zusätzliche Bestätigung im Webkonto. Bei Konten mit 2FA ist zudem zu klären, ob der Client OAuth2 unterstützt; andernfalls führt der Einsatz des normalen Passworts zwangsläufig in eine Authentifizierungs-Schleife.

• Benutzername normalisieren: Als Erstversuch stets die vollständige Adresse einsetzen, z. B. name@domain.tld; keine Leerzeichen, keine führenden oder nachgestellten Zeichen.
• 2FA-Status klären: Ist Zwei-Faktor aktiv, dann entweder Authentifizierung auf OAuth2 stellen oder ein App-Passwort verwenden; das reguläre Kontopasswort ist bei Basic Auth oft wirkungslos.
• SMTP-Anmeldung erzwingen: In vielen Apps muss „SMTP-Server erfordert Anmeldung“ explizit aktiviert werden; Nutzername/Geheimnis sollten mit IMAP identisch sein, sofern der Provider nichts anderes vorgibt.
• Transport und Port konsistent wählen: Für IMAP typischerweise 993/TLS, für POP3 995/TLS, für SMTP Submission 587/STARTTLS oder SMTPS 465/TLS; Mischkonfigurationen erzeugen TLS- und Timeout-Fehler.
• Sperren und Sicherheitsmeldungen prüfen: Im Webkonto nach Hinweisen wie „ungewöhnliche Anmeldung“ suchen; bei Bedarf App freigeben oder App-Passwort widerrufen und neu erstellen.

Wenn eine Einrichtung auf Smartphone und PC unterschiedlich scheitert, liegt der Grund häufig im Authentifizierungstyp: Ein Desktop-Client kann OAuth2 anbieten, während eine einfache Mail-App nur Passwortfelder kennt. In solchen Fällen ist die Wahl zwischen einem Client mit OAuth2-Unterstützung und einem App-Passwort die entscheidende Weiche; Serverdaten und Ports sind dann meist nicht die eigentliche Ursache.