Gemeinsamer Posteingang: alle Konten ohne Weiterleitung

Ein gemeinsamer Posteingang zeigt Nachrichten aus allen Ihren Konten in einer Liste, nach Empfangszeit sortiert. Jede Zeile kennzeichnet das Herkunftskonto. Viele suchen diese Lösung, nachdem sie versucht haben, ihre E-Mail per Weiterleitung zusammenzuführen und deren Grenzen kennengelernt haben.

Bei ungeeigneter Einrichtung können sich Absenderangaben ändern, Nachrichten im Spam landen und Antworten von einer dem Empfänger unbekannten Adresse kommen. Das zweite Konto bekommt dann wieder einen eigenen Browsertab, den man mehrmals täglich prüft.

Das lässt sich nicht immer durch eine andere Regel lösen. Weiterleitung verändert den Zustellweg und kann die Authentifizierung beeinträchtigen. SRS, eine unveränderte DKIM-Signatur und eine vom Empfänger als vertrauenswürdig bewertete ARC-Kette können helfen. Sie machen Weiterleitung aber nicht zu einem vollständigen Client für mehrere Konten.

Die Alternative ist ein Client, der alle Postfächer direkt liest. Desktop-Programme können das seit Langem. Ein serverseitiger gemeinsamer Posteingang nutzt denselben Ansatz, zeigt aber auf Smartphone und Laptop dieselbe zusammengeführte Liste.

Warum Weiterleitung keinen Client ersetzt

Weiterleitung versendet eine Nachricht erneut über einen Server, den der ursprüngliche Absender meist nicht in SPF autorisiert hat. SPF kann deshalb fehlschlagen. DKIM bleibt häufig gültig, solange die signierten Teile unverändert sind. DMARC benötigt gültiges, mit From abgeglichenes SPF oder DKIM. Wenn beides nicht passt, empfiehlt eine Richtlinie p=reject dem empfangenden Server, die Nachricht abzulehnen. Die endgültige Entscheidung trifft der Empfänger. So können beim Zusammenführen per Weiterleitung Zustellfehler entstehen.

Sender Rewriting Scheme ersetzt den Envelope-Absender durch eine Domain, die den Weiterleitungsserver autorisiert. Im beschriebenen System wird SRS automatisch angewendet und unterstützt SPF für den neuen Envelope-Absender. Es gleicht diese Domain nicht mit dem ursprünglichen From ab, repariert keine beschädigte DKIM-Signatur und ermöglicht keine Antwort von der alten Adresse.

Der letzte Punkt wird oft unterschätzt. Weiterleitung funktioniert nur in eine Richtung. Eine Nachricht an you@oldcompany.com landet im neuen Postfach. Sie antworten, und der Empfänger sieht you@newcompany.com, sofern der Versand von der alten Adresse nicht separat eingerichtet wurde. In Kundengesprächen kann das verwirren. Eine Weiterleitungsregel gibt Ihnen nicht das Recht, mit der bisherigen Adresse zu senden.

Auch der Speicher zählt. Die weitergeleitete Kopie belegt Platz am Ziel; das Original kann weiterhin an der Quelle liegen. Bei Löschung nach Weiterleitung fällt diese lokale Rückfallmöglichkeit weg. Eine fehlerhafte Regel kann dann die Wiederherstellung erschweren. Backups sollten unabhängig von Weiterleitung geplant werden.

Weiterleitung ist nützlich für eine Adresse ohne eigenes Postfach, etwa invoices@, die Rechnungen an die zuständige Person leitet. Sie ersetzt nicht das Lesen und Senden aus mehreren aktiven Konten. Mehr dazu unter Aliase, Postfächer und Weiterleitung sowie SRS bei weitergeleiteter E-Mail.

POP-Abruf und das Ende des alten Verfahrens

Ein anderes traditionelles Verfahren meldet sich regelmäßig per POP3 beim externen Konto an, lädt neue Nachrichten herunter und speichert sie lokal. So arbeitete Gmail Mail Fetcher. Die verbundenen Konten von Outlook.com erfüllten einen ähnlichen Zweck.

Der Ausgangsartikel beschreibt die Einstellung dieser Funktionen. Microsoft entfernte verbundene Konten aus Outlook.com, und Google hat das Ende von Gmail Mail Fetcher und Gmailify angekündigt. Prüfen Sie aktuelle Termine und Verfügbarkeit beim jeweiligen Anbieter. Es geht um bestimmte Funktionen, nicht um alle Zugangswege zu mehreren Konten.

Regelmäßiger Abruf hat technische Grenzen. Eine Nachricht erscheint erst nach der nächsten Abfrage. Bleibt das Original erhalten, wird Speicher in beiden Diensten genutzt. Die Zustände können auseinanderlaufen: hier gelesen und dort ungelesen, an einer Stelle gelöscht und an der anderen erhalten. POP3 übernimmt keine Ordnerstruktur.

Drei Wege zum gemeinsamen Posteingang

Jeder Ansatz hat Grenzen. Weiterleitung sendet erneut und kann die Authentifizierung beeinflussen. Das Herunterladen von Kopien hängt vom Abfrageintervall und den Speicherbedingungen ab. Ein IMAP-Proxy authentifiziert sich bei jedem Konto und liest bei Bedarf, ohne ein dauerhaftes Kopienarchiv anzulegen. Ungültige Zugangsdaten werden beim Verbindungsversuch erkannt.

TrekMail nutzt den dritten Ansatz. Dauerhafte Nachrichtenkopien werden nicht angelegt. Beim Öffnen der gemeinsamen Ansicht verbindet sich der Server per IMAP mit den Konten, liest die nötigen Header, führt sie nach internem Datum zusammen und speichert das Ergebnis kurz im Cache. Beim Lesen wird die Nachricht an der Quelle als gelesen markiert, sofern Rechte und Einstellungen die Änderung erlauben.

Das Verbinden eines Kontos ändert nicht dessen Hosting. Gmail bleibt bei Google, mit eigenem Speicher, Filtern und Weboberfläche. Die Verbindung ändert weder MX noch eingehendes Routing. Nach dem Trennen muss kein Kopienarchiv gelöscht werden. Bereits im Client ausgeführte Aktionen bleiben jedoch an der Quelle bestehen.

So sieht es im Alltag aus

Es gibt zwei Ansichten. Eine führt Nachrichten für den Gesamtüberblick zusammen, die andere konzentriert sich auf ein Konto. Sie können je nach Arbeitskontext wechseln.

Alle Posteingänge führt Postfächer und verbundene Konten nach Empfangszeit zusammen. Jede Zeile zeigt die Herkunft durch ein Anbieterlogo oder einen farbigen Anfangsbuchstaben für ein TrekMail-Postfach. Beim Antworten wird die passende Absenderidentität vorausgewählt; ihre Nutzung hängt von Rechten und Versandeinstellungen ab.

Die Kontoansicht wählen Sie in der Seitenleiste. Ein Klick auf das Konto zeigt dessen Ordner, Entwürfe und gesendete Nachrichten.

Quellen werden parallel abgefragt. Acht IMAP-Server nacheinander zu kontaktieren würde die Seite merklich verlangsamen. Ist eine Quelle wegen widerrufener Zugangsdaten oder einer Störung nicht erreichbar, wird sie übersprungen und das betroffene Konto angezeigt. Die übrigen Quellen bleiben sichtbar.

Von der richtigen Adresse senden

Bei einer Antwort auf eine Nachricht im verbundenen Gmail-Konto wird die Antwort mit Ihrer Kontoauthentifizierung an Googles SMTP-Server übergeben. Bei korrekter Verbindung und Versandberechtigung wird sie über Googles Infrastruktur versendet, nicht über unseren Ausgangsserver.

Das ist für die Authentifizierung wichtig. Gmails SPF autorisiert Google-Server. Wer mit @gmail.com über fremde, nicht autorisierte Infrastruktur sendet, kann sich nicht auf gültiges und abgeglichenes SPF oder DKIM verlassen. Der autorisierte Server des Kontos unterstützt die richtige Prüfung. DMARC verlangt gültiges, mit From abgeglichenes SPF oder DKIM, nicht zwingend beides, und garantiert keine Zustellung im Posteingang.

Dasselbe gilt für andere Konten: Eine Fastmail-Adresse sendet über Fastmail, ein eigener Server über seinen SMTP. Das From-Menü enthält nur verfügbare Adressen: die Postfachadresse, Aliase mit aktiviertem Versand, gemeinsame Postfächer mit Antwortrecht und verbundene Konten. Eine fehlende Adresse kann auf unzureichende Rechte oder Einstellungen hinweisen, nicht auf einen nachgewiesenen künftigen Authentifizierungsfehler. Prüfen Sie das vor dem Versand, nicht erst nach einer Fehlermeldung zwei Minuten später.

App-Passwörter und OAuth

Große Anbieter schränken normale Passwörter für IMAP zunehmend ein. Die Verbindung nutzt ein App-Passwort, OAuth oder ein anderes unterstütztes Verfahren. Der Ablauf hängt vom Anbieter ab. Prüfen Sie auch aktuelle Regeln und Organisationsrichtlinien.

Ein App-Passwort ist eine separate zufällige Zeichenfolge, die meist ohne Änderung des Hauptpassworts widerrufen werden kann. Seine Rechte sind nicht zwingend auf ein Protokoll begrenzt; das hängt vom Anbieter ab. Es vermeidet die Weitergabe des Hauptpassworts. Der Assistent verlinkt die Erstellungsseite des erkannten Dienstes.

Die Erkennung erfolgt automatisch: Die Domain wird mit bekannten Anbietern verglichen; bei einer eigenen Domain werden MX-Einträge geprüft. So lassen sich Google Workspace und Microsoft 365 auch ohne Endung @gmail.com erkennen. Wird der Dienst nicht erkannt, geben Sie die Einstellungen manuell ein. Diese Prüfung ändert DNS nicht.

Manuelle Verbindungen unterstützen IMAP auf 993 mit implizitem TLS oder 143 mit STARTTLS sowie SMTP auf 465, 587 oder 2525. Die TLS-Zertifikatsprüfung ist verpflichtend. Ein nicht vertrauenswürdiges selbstsigniertes Zertifikat oder ein falscher Name verhindert die Verbindung. Prüfen Sie Vertrauenskette, Gültigkeit und Servernamen, denn die Verbindung gewährt Zugriff auf E-Mail.

Ein Konto verbinden

1. Öffnen Sie Webmail und gehen Sie zu Einstellungen → Verbundene Konten.
2. Klicken Sie auf Konto verbinden und geben Sie die Adresse ein.
3. Bei erkanntem Anbieter folgen Sie der Anleitung zum App-Passwort oder zur Microsoft-Anmeldung für Outlook.com. Andernfalls geben Sie IMAP- und SMTP-Server, Ports und Verschlüsselung nach Anbieterdokumentation ein.
4. Klicken Sie auf Verbindung testen. Lesen und Senden werden getrennt geprüft, damit erkennbar ist, welcher Teil scheitert.
5. Speichern Sie. Das Konto erscheint in der Seitenleiste, seine Nachrichten unter Alle Posteingänge.

Ordner werden bei der ersten Verbindung zugeordnet. Anbieter verwenden unterschiedliche Namen: [Gmail]/Sent Mail, Sent Items, Sent. Wenn vorhanden, werden Kennzeichnungen für Spezialordner genutzt, andernfalls die Namen. Virtuelle Gmail-Ansichten wie Alle Nachrichten werden verborgen, damit dieselbe Nachricht nicht mehrfach erscheint. Labels bedeuten nicht, dass jede Nachricht physisch mehrfach gespeichert ist.

In der Dokumentation finden Sie Anleitungen für Gmail, Outlook und Microsoft, iCloud, Yahoo und AOL und andere IMAP-Server.

Fehler und ihre Anzeichen

Widerrufenes App-Passwort. Eine häufige Ursache. Eine Änderung des Google-Hauptpassworts kann App-Passwörter widerrufen. Die Oberfläche fordert zum erneuten Verbinden auf, statt das Konto zu verbergen. Erstellen Sie ein neues App-Passwort und aktualisieren Sie die Einstellungen.

IMAP beim Anbieter deaktiviert. Google-Workspace- oder Microsoft-365-Richtlinien können den Zugriff beschränken. Der Client kann das nicht umgehen. Ein Administrator muss die Berechtigung prüfen.

Ungültige OAuth-Berechtigung. Microsoft-Token werden erneuert, solange dies erlaubt bleibt. Widerrufene Zustimmung oder Änderungen an Sicherheit und Richtlinien können eine neue Autorisierung erfordern. Melden Sie sich bei entsprechender Aufforderung erneut an.

Langsamer Quellserver. Jede Quelle hat ein Zeitlimit. Antwortet sie zu spät, wird sie für diesen Seitenaufruf übersprungen und gemeldet. Es gibt keine endlosen Wiederholungen zulasten der übrigen Postfächer.

Weitere Hilfe unter Fehlerbehebung für verbundene Konten.

Grenzen

Laut Ausgangsbeschreibung sind verbundene Konten ab Starter verfügbar:

Die gemeinsame Ansicht fragt bis zu 25 Quellen gleichzeitig ab. Darüber sind Kontoansichten praktischer. Dauerhafte Kopien der verbundenen E-Mail belegen keinen Tarifspeicher; Nachrichten bleiben an der Quelle. Temporäre Caches für Oberflächendaten sind damit nicht ausgeschlossen.

Häufige Fragen

Verschiebt der gemeinsame Posteingang meine E-Mail?

Nein. Er kopiert oder verschiebt kein dauerhaftes Archiv. Nachrichten werden per IMAP beim ursprünglichen Anbieter gelesen. Das Trennen löscht das Quellpostfach nicht, macht aber bereits ausgeführte Aktionen wie Lesemarkierungen nicht rückgängig.

Was ist der Unterschied zur Migration?

Migration kopiert Nachrichten zu TrekMail für den Wechsel vom bisherigen Anbieter. Der gemeinsame Posteingang belässt den Speicher und bietet eine gemeinsame Oberfläche. Für einen endgültigen Umzug nutzen Sie die Massenmigration.

Kommen Antworten von der richtigen Adresse?

Bei korrekten Rechten und Einstellungen sendet die verbundene Adresse über ihren SMTP. Der Empfänger sieht die gewohnte Adresse. Gültiges, abgeglichenes SPF oder DKIM hängt von den Anbietereinstellungen ab. Die Verbindung allein garantiert weder Authentifizierung noch Zustellung.

Warum braucht Gmail ein App-Passwort statt einer Anmeldeschaltfläche?

Diese Integration verwendet IMAP mit App-Passwort. Die Gmail-API kann eine Prüfung eingeschränkter Berechtigungen und je nach Datenverarbeitung eine externe Sicherheitsbewertung erfordern. Das App-Passwort bietet einen anderen Zugang und lässt sich bei Google widerrufen, sofern die Kontorichtlinie seine Erstellung erlaubt. IMAP und API gewähren nicht zwingend dieselben Rechte.

Kann ich ein Postfach auf meinem eigenen Server hinzufügen?

Ja. Geben Sie IMAP- und SMTP-Server, Ports und Verschlüsselung manuell ein. Das Zertifikat muss Vertrauens- und Namensprüfung bestehen. Ersetzen Sie ein nicht vertrauenswürdiges selbstsigniertes Zertifikat. Ein Zertifikat einer öffentlichen Zertifizierungsstelle eignet sich bei korrekter Kette, Gültigkeit und passendem Namen.

Funktioniert der gemeinsame Posteingang mobil?

Ja. Die Verbindungen sind auf dem Server eingerichtet, nicht in einem lokalen Profil. Nach Anmeldung auf einem unterstützten Gerät sehen Sie dieselben Konten und dieselbe Liste ohne erneute Verbindungseinrichtung.

Was passiert beim Wechsel zu einem Tarif ohne verbundene Konten?

Der Abruf endet, und das Konto wird als nicht verfügbar angezeigt. Der Tarifwechsel löscht keine Quelldaten. Mit einem passenden Tarif wird der Zugriff wieder möglich, sofern Zugangsdaten und Rechte weiterhin gültig sind.