Die E-Mails verschwanden immer wieder. Wir zogen das Shop-Postfach zu Google Workspace um, und die Details gaben den Ausschlag

Die Rückmeldung kam so, wie solche Rückmeldungen meistens kommen: eher vage. Manche Kunden bekamen unsere Antworten nie. Bei Gmail-Nutzern lief alles problemlos. Ab und zu kam eine Nachricht als unzustellbar zurück. Und ein Lieferant, ein Großhändler, bei dem der Shop einkauft, konnte den Shop problemlos anschreiben, aber der Shop konnte ihm nicht antworten.

Es geht um einen kleinen Fachhändler, den wir betreuen. Ein gemeinsam genutztes geschäftliches Postfach mit jahrelanger Korrespondenz, ein paar Mitarbeiter, die am Rechner und am Smartphone darin lesen, und ein Onlineshop, der Bestellbestätigungen von derselben Adresse verschickt. Niemand dort möchte sich Gedanken über E-Mails machen. Sie sollen einfach ankommen.

Hier schildern wir anonymisiert, wie wir das Problem gelöst haben: unsere Schritte, die umgangenen Fallstricke und die Nachkontrollen, die wir bei jedem solchen Umzug empfehlen. Die Kurzfassung: Wir haben das Postfach zu Google Workspace umgezogen und die Website beim bisherigen Hoster belassen. Dort änderten sich nur die E-Mail-Einstellungen. Die ausführliche Fassung lohnt sich, denn die meiste Arbeit steckte in Details, die zusätzlichen Aufwand erforderten: der DNS-Umstellung, Zehntausenden alter Nachrichten, dem Ordner „Gesendet“ (Sent) und den Benachrichtigungen des Shops selbst.

Alle Prüfungen bestanden, und trotzdem verschwanden E-Mails

Als Erstes prüft man die Authentifizierung. Das haben wir auch getan. SPF bestand. DKIM bestand. DMARC bestand, mit der Richtlinie p=none, die Empfänger auffordert, bei fehlgeschlagenen DMARC-Prüfungen keinerlei Maßnahmen zu ergreifen. Auf dem Papier war die Domain korrekt eingerichtet. Trotzdem bestanden die Probleme seit Monaten, obwohl alle diese Prüfungen erfolgreich waren.

Die Antwort lag eine Ebene weiter außen. Alles, was der Shop nutzte, also das DNS der Domain, die Website und das Postfach, lag bei einem einzigen Shared-Hosting-Anbieter. Ausgehende E-Mails wurden nicht vom eigenen Server des Shops versendet. Sie liefen über das gemeinsam genutzte Ausgangsrelay des Anbieters, dieselben wenigen Server, über die auch viele andere Kunden senden. Und die Relay-Adresse, über die die Nachrichten des Shops liefen, stand auf einer öffentlichen Spam-Blocklist.

Das Zustellmuster passte zu diesem Eintrag: Empfänger, die solche Listen abfragen, weisen E-Mails von gelisteten Adressen zurück oder sortieren sie als Spam ein, unabhängig davon, wie sauber sie signiert sind. Gmail gewichtet dagegen vor allem die eigenen Reputationsdaten. Die Ablehnungsnachricht des Großhändlers haben wir selbst nie gesehen, aber seine Seite verhielt sich genau wie ein Filter, der diese Liste verwendet.

Die Authentifizierung war nie das Problem. Die Reputation des gemeinsamen Relays war es.

Wenn Sie dieselbe Diagnose für Ihre eigene Domain durchführen möchten, kommen Sie mit diesen Befehlen schon recht weit. Die IP-Adresse finden Sie in der Zeile Received:, die der empfangende Server einer Nachricht hinzugefügt hat, die Sie an Ihre eigene Gmail-Adresse gesendet haben. Öffnen Sie die Nachricht und wählen Sie Original anzeigen (Show original).

# Wer empfängt Ihre E-Mails, und was sagen SPF und DMARC?
dig +short MX example-shop.com
dig +short TXT example-shop.com | grep -i spf
dig +short TXT _dmarc.example-shop.com

# Steht der Server, der Ihre Nachricht versendet hat, auf einer Blocklist?
# Nur ein Beispiel: die tatsächliche sendende IP umkehren, aus 203.0.113.25 wird 25.113.0.203
dig 25.113.0.203.bl.spamcop.net A +noall +comments +answer
# Status NOERROR mit 127.0.0.2 = gelistet; Status NXDOMAIN = derzeit nicht gelistet;
# SERVFAIL, REFUSED oder Timeout = keine Antwort, die Webabfrage der Liste nutzen

Ein praktischer Hinweis: Manche Blocklists, darunter Spamhaus, verweigern Abfragen über große öffentliche DNS-Resolver und liefern stattdessen einen Fehlercode zurück. Außerdem prüft eine Abfrage genau eine Liste zu einem bestimmten Zeitpunkt, nicht Ihre Zustellbarkeit insgesamt.

Warum wir nur die E-Mails umgezogen haben

E-Mail- und Website-Hosting sind getrennte Dienste, die häufig zusammen verkauft werden. Ein Website-Umzug ist ein Projekt mit Ausfallrisiko, dem Aufwärmen der Caches und etlichen Abhängigkeiten. Ein E-Mail-Umzug besteht aus einer DNS-Änderung und einem Import. Die Website des Shops funktionierte, also ließen wir sie beim bisherigen Hoster und lösten das Problem, das tatsächlich wehtat.

Wir haben vier Möglichkeiten abgewogen:

Wir würden beide großen Anbieter empfehlen. Wir haben uns aus einem einfachen Grund für Workspace entschieden: Die Menschen, die das Postfach nutzen, kannten Gmail bereits. Und je weniger ein kleines Team neu lernen muss, desto schneller wird die Umstellung zur Gewohnheit.

Außerdem haben wir das geschäftliche Postfach als eigenen Workspace-Nutzer belassen, statt es in das Privatkonto einer Person einzubinden. Eine Geschäftsadresse im privaten Gmail-Konto eines Mitarbeiters lässt sich nur schwer übergeben, prüfen und zurückholen, wenn die Person das Unternehmen verlässt. Wenn mehrere Personen eigene Anmeldungen statt eines gemeinsamen Zugangs benötigen, können sie über die Gmail-Delegierung mit ihren persönlichen Konten im gemeinsamen Postfach arbeiten. Die Zugriffsfrage behandeln wir in unserem Beitrag darüber, was passiert, wenn ein Mitarbeiter geht, seine Zugriffsrechte aber bleiben.

Vor dem ersten DNS-Eingriff: die Vorbereitung

Die Umstellung selbst dauert nur Minuten. Die Vorbereitung entscheidet, ob diese Minuten unspektakulär oder dramatisch werden.

• Die gesamte DNS-Zone sichern. Exportieren Sie sie oder notieren Sie jeden Eintrag, damit Sie die alten Einträge exakt wiederherstellen können. Beachten Sie: Ein Rollback ändert nur, wohin neue E-Mails gehen. Alles, was zwischenzeitlich bei Google zugestellt wurde, bleibt dort.
• Alle Adressen auflisten, die E-Mails empfangen. Postfächer, Aliasse, Weiterleitungen, Gruppen, Catch-all-Regeln. Sobald der MX-Eintrag auf Google zeigt, muss es sie alle auch dort geben, sonst werden ihre E-Mails zurückgewiesen. Dieser Shop hatte nur ein Postfach und sonst nichts. Die Liste blieb also kurz.
• Alles auflisten, was unter Ihrer Domain E-Mails versendet. E-Mail-Programme auf Rechnern und Smartphones, der Onlineshop (Bestellbestätigungen, Kontaktformular, Passwortzurücksetzungen), Rechnungsprogramme, Marktplatzkonten. Alles muss auch nach der Umstellung weiter funktionieren.
• Die TTL des MX-Eintrags einen Tag vorher auf 300 Sekunden senken. Der MX-Eintrag des Shops hatte eine TTL von vier Stunden. Andere Mailserver durften sich das alte Ziel also noch vier Stunden nach der Änderung merken.
• Googles TXT-Eintrag zur Domainbestätigung hinzufügen und die Gmail-Aktivierung in der Admin-Konsole (Admin console) abschließen. Der Bestätigungseintrag steht neben Ihrem SPF-Eintrag. Eine Domain darf viele TXT-Einträge haben, aber nur einer davon darf ein SPF-Eintrag sein.
• Die Bestätigung in zwei Schritten aktivieren, sowohl für den Workspace-Administrator als auch für den Postfachnutzer. Bewahren Sie die Back-up-Codes sicher auf, bevor die ersten E-Mails eingehen.

Die Umstellung, Eintrag für Eintrag

Das waren die Änderungen. Die Namen des Shops haben wir durch Platzhalter ersetzt.

Behalten Sie im SPF-Eintrag alle Mechanismen bei, die Ihre aktiven Absender noch benötigen, und ergänzen Sie daneben Googles Include. Pro Name darf es nur einen SPF-Eintrag geben, und insgesamt höchstens zehn DNS-Abfragen, wenn alle Includes mitgezählt werden.

Zwei Details verdienen einen eigenen Absatz. Erstens: Der DKIM-Schlüssel ist länger als die 255 Zeichen, die eine einzelne DNS-Textzeichenfolge aufnehmen kann. Trotzdem muss er in einem einzigen TXT-Eintrag stehen. Manche DNS-Oberflächen teilen ihn automatisch in mehrere Zeichenfolgen in Anführungszeichen innerhalb dieses Eintrags auf, bei anderen müssen Sie das selbst tun. Vergleichen Sie den veröffentlichten Wert Zeichen für Zeichen mit dem in der Admin-Konsole. Klicken Sie anschließend unter Apps, Google Workspace, Gmail, „Authenticate email“ auf „Start authentication“. Bei einem ganz neuen Workspace-Konto kann es einen Tag oder länger dauern, bis Google die Schlüsselerstellung freigibt.

Zweitens: Verlassen Sie sich nicht auf Ihren eigenen Resolver, um die erfolgreiche Umstellung zu prüfen. Fragen Sie jeden autoritativen Nameserver direkt ab:

# Jeden Nameserver der Domain fragen, welchen MX er gerade ausliefert
for ns in $(dig +short NS example-shop.com.); do
  printf '%s\n' "$ns"
  dig @"$ns" example-shop.com. MX +norecurse +noall +comments +answer
done
# In jedem Block auf das Flag "aa" (eine autoritative Antwort) und den neuen MX achten

Bei unserer Abfrage lieferte ein Nameserver innerhalb von Sekunden den Google-Eintrag. Die anderen drei gaben noch etwa zwanzig Minuten lang den alten MX zurück, bei gleicher Seriennummer der Zone. Warum, haben wir nie erfahren. Hätten wir nur unseren eigenen Resolver geprüft, hätten wir die Umstellung für abgeschlossen erklärt und übersehen, dass E-Mails noch zwanzig Minuten lang den alten Weg nahmen.

Ein Nameserver antwortete binnen Sekunden mit Google. Die anderen drei brauchten etwa zwanzig Minuten.

Rechnen Sie auch mit Nachzüglern. Mailserver, die den alten MX vor der Änderung abgefragt haben oder Nachrichten für einen erneuten Zustellversuch in der Warteschlange halten, können noch eine Weile an das alte Postfach zustellen. Lassen Sie deshalb während der Übergangszeit beide Postfächer aktiv, überwachen Sie das alte und wiederholen Sie den Import, bis dort nichts Neues mehr ankommt. Prüfen Sie bei Hosting-Oberflächen wie cPanel außerdem die E-Mail-Routing-Einstellung der Domain: Wenn das Hosting-Konto weiterhin davon ausgeht, für die E-Mails der Domain zuständig zu sein, können Nachrichten von der Website an Ihre eigene Adresse lokal im alten Postfach landen.

40.000 Nachrichten übertragen, ohne eine zu verlieren

Im alten Postfach lagen 39.840 Nachrichten in 27 Ordnern, insgesamt etwa 13 GB aus vielen Jahren: Lieferantenrechnungen, Marktplatzbestellungen, Paketdienstbenachrichtigungen und Kundengespräche. Davon durfte nichts verloren gehen. Eine Woche mit halb importierten Ordnern kam ebenso wenig infrage.

Der Import ist der einfache Teil. Erst der Abgleich erlaubt die Aussage, dass nichts verloren ging.

Wir begannen mit Googles integrierter Datenmigration, die sich per IMAP mit dem alten Server verbindet und alles kopiert. Sie funktioniert, hatte bei diesem Postfach aber drei Probleme:

• Geschwindigkeit. Etwa 2.400 Nachrichten pro Stunde, bei diesem Postfach also mehr als sechzehn Stunden. Soweit wir erkennen konnten, wurde pro IMAP-Sitzung eine Nachricht abgerufen. Eine Einstellung für die Geschwindigkeit bietet das Tool nicht.
• Lücken. Mehrere Ordner meldeten einen „crawl failure“ mit einem internen Synchronisierungsfehler. Die Empfehlung lautete, später eine weitere Migration auszuführen.
• Falsche Datumsangaben. 925 Nachrichten stammten von einem Absender, dessen Mailsystem einen fehlerhaften Date-Header schreibt: Sekunden ohne führende Null und keine Zeitzone, etwa 2 Apr 2024 18:36:4. Zwei weitere hatten gar keinen Date-Header. Die Migration versah sie mit dem Importzeitpunkt. Dadurch erschienen Jahre alte Nachrichten ganz oben im Posteingang, als wären sie erst an diesem Morgen angekommen.

Also schlossen wir die Arbeit mit einem eigenen Importer auf Basis der Gmail-Import-API ab, den wir vollständig selbst steuern konnten:

• Nur lesend an der Quelle. Das alte Postfach wurde schreibgeschützt geöffnet und jede Nachricht abgerufen, ohne das Flag „seen“ zu setzen. Auf dem alten Server änderte sich nichts. Er blieb damit eine verlässliche Rückfalloption.
• Bereits übertragene Nachrichten überspringen. Jede Nachricht wurde anhand ihrer Message-ID mit dem Bestand in Gmail abgeglichen. So kopierte der Importer nicht noch einmal, was Googles Migration bereits übertragen hatte.
• Aus Ordnern werden Labels. Ein alter Ordner wie INBOX.Invoices wurde zum Gmail-Label Invoices. Das Team fand also alles dort, wo es erwartet wurde.
• Fortsetzbar. Eine Statusdatei hielt den Fortschritt fest. Nach einer Unterbrechung ging es an derselben Stelle weiter, statt von vorn zu beginnen.
• Das Datum der Nachricht selbst. Nachrichten mit gültigem Date-Header wurden anhand dieses Datums zeitlich eingeordnet, nicht nach dem Tag des Imports.

Ein weiteres Detail fällt schon am ersten Tag auf: Markierungen. Die Sterne wurden beim Import nicht übernommen. Ein Team, das Sterne seit Jahren als Aufgabenliste nutzt, bemerkt das sofort. Wir ordneten die 530 markierten Nachrichten aus dem alten Postfach ihren Kopien in Gmail zu und versahen sie wieder mit Sternen.

Für den Ordner „Gesendet“ brauchten wir einen eigenen Plan

Nach der Zustellung selbst war das dem Shopbetreiber am wichtigsten. Beim Wechsel zu Gmail gingen im Ordner „Gesendet“ drei verschiedene Dinge schief.

1. Gmail entschied, was als gesendet galt

In diesem Postfach erschien jede importierte Nachricht von der eigenen Postfachadresse unter „Gesendet“. Dasselbe beobachteten wir später bei Kopien, die über das Relay eingingen. Nach dem Import betraf das auch die automatischen Shop-Benachrichtigungen aus vielen Jahren, denn Bestellbestätigungen waren schon immer von der Geschäftsadresse versendet worden. Unter „Gesendet“ lagen plötzlich etwa 1.950 Nachrichten, die niemand selbst geschrieben hatte, vermischt mit den tatsächlichen Antworten des Teams.

Wir erkannten die vom Shop erzeugten Nachrichten an ihren Mailer-Headern und verschoben alle 1.959 mit dem IMAP-Verschiebebefehl aus „Gesendet“ in die passenden Labels. In diesem Postfach entfernte das Verschieben aus dem Ordner „Gesendet“ auch das Label „Gesendet“. Genau das brauchten wir. Wir testeten es zunächst mit einer kleinen Anzahl von Nachrichten. Danach enthielt „Gesendet“ wieder ausschließlich von Menschen geschriebene E-Mails.

Gmail ordnete die eigenen Shop-Benachrichtigungen unter „Gesendet“ ein. Nach dem Verschieben war der Ordner wieder sinnvoll nutzbar.

2. Neue Shop-E-Mails würden ihn wieder füllen

Der naheliegende Weg, einen Onlineshop über Google senden zu lassen, ist die Anmeldung mit den Zugangsdaten des Postfachs bei smtp.gmail.com. Das funktioniert. Ab diesem Tag landet dann aber wieder jede Bestellbestätigung unter „Gesendet“. Deshalb versendet der Shop über Googles SMTP-Relay-Dienst (smtp-relay.gmail.com), den ein Administrator in der Admin-Konsole unter Apps, Google Workspace, Gmail, Routing einrichtet:

• „Allowed senders“: „Only addresses in my domains“
• „Require SMTP authentication“
• „Require TLS encryption“

„Comprehensive mail storage“, eine Administratoreinstellung unter Gmail, „Compliance“, war in diesem Konto deaktiviert. Über das Relay versendete Nachrichten erschienen nicht im Ordner „Gesendet“ des Absenders. Wird diese Einstellung aktiviert, werden Kopien der über das Relay versendeten E-Mails in den Postfächern der Nutzer gespeichert. Wenn für Sie Aufbewahrungspflichten gelten, sollten Sie sich diese Einstellung und Google Vault ansehen.

3. Das Team möchte trotzdem sehen, was der Shop versendet hat

Ein aufgeräumter Ordner „Gesendet“ ist schön, bis ein Kunde anruft und wissen möchte, was in seiner Bestätigung stand. Deshalb sorgt nun ein kleines Stück individuell ergänzter Code im Shop dafür, dass jede erfolgreich versendete Nachricht eine Kopie an eine Plus-Adresse des Hauptpostfachs auslöst (office+shop@). Die Kopie kommt von einer separaten Adresse der Domain (shop@), für die es gar kein Postfach gibt. Ihr Anzeigename nennt die ursprünglichen Empfänger („An: customer@...“), und ihr Reply-To verweist auf den Kunden. Eine Antwort geht damit an die richtige Person.

Ein Gmail-Filter für deliveredto:office+shop@example-shop.com überspringt den Posteingang, markiert die Kopie als gelesen und weist ihr das Label Gesendet - Shop zu. Warum eine andere Absenderadresse? Wegen Punkt 1: In diesem Postfach landeten Kopien von der eigenen Postfachadresse unter „Gesendet“, selbst wenn sie über das Relay eingingen. Benachrichtigungen des Shops an die eigenen Mitarbeiter werden ebenfalls von shop@ verschickt. So landen sie im Posteingang, wo sie tatsächlich jemand liest.

Eine Einschränkung sollten Sie kennen: Gmail kann kein Label innerhalb von „Gesendet“ anlegen. Gesendet - Shop steht daneben in der Label-Liste. Damit war der Shopbetreiber einverstanden, nachdem der Grund klar war.

E-Mail-Programme auf dem Desktop

Ein paar Einstellungen machten den Unterschied zwischen „Thunderbird ist seit dem Umzug langsam“ und einem E-Mail-Programm, das ordentlich funktioniert:

• Weniger synchronisieren. Gmail zeigt jedes Label als IMAP-Ordner an. Eine Nachricht kann deshalb mehrfach heruntergeladen werden. Entfernen Sie in den Gmail-Einstellungen unter Labels den Haken bei „In IMAP anzeigen“ (Show in IMAP) für Ordner, die das Team auf dem Desktop nicht nutzt, etwa „Wichtig“. Seien Sie bei „Alle Nachrichten“ vorsichtig: Archivierte Nachrichten liegen nur dort. Wenn das Team in Gmail archiviert, lassen Sie „Alle Nachrichten“ sichtbar und begrenzen Sie stattdessen das Offline-Herunterladen im E-Mail-Programm.
• Das E-Mail-Programm keine zweite Kopie gesendeter Nachrichten speichern lassen. Bei Konten, die über Gmail senden, speichert Gmail bereits jede gesendete Nachricht. Prüfen Sie, ob eine Testnachricht unter „Gesendet“ erscheint. Deaktivieren Sie danach das Speichern einer eigenen Kopie im E-Mail-Programm. Sonst lädt es jede Nachricht ein zweites Mal hoch.
• Das alte Konto im E-Mail-Programm stilllegen. Entfernen Sie es nach dem letzten Importdurchlauf oder benennen Sie es zumindest um, damit niemand aus Gewohnheit über den alten Server antwortet.

Die E-Mails des Shops: die Einstellungen in PrestaShop

Unabhängig vom Shopsystem bedeuten die Relay-Einstellungen dasselbe. In PrestaShop 1.7 und 8 finden Sie sie unter Erweiterte Einstellungen, E-Mail (Advanced Parameters > E-mail). Die Bezeichnungen können je nach Version leicht abweichen:

Die eigene E-Mail-Adresse des Shops, die Sie unter Shop-Einstellungen (Shop Parameters) hinterlegen, muss eine Adresse Ihrer Domain sein. Andernfalls weist das Relay sie zurück. Senden Sie von derselben Einstellungsseite eine Test-E-Mail, öffnen Sie sie in Gmail, wählen Sie Original anzeigen und achten Sie auf drei erfolgreiche Prüfungen: SPF, DKIM mit Signatur Ihrer eigenen Domain und DMARC. Die oben beschriebene Archivkopie gehört nicht zu diesen Einstellungen. Dafür war in diesem Shop individueller Code nötig, PrestaShop bringt das nicht von Haus aus mit. Einen umfassenderen Überblick über die E-Mail-Einstellungen von PrestaShop finden Sie in unserer Anleitung zur E-Mail-Konfiguration in PrestaShop: SMTP, Gmail und Transaktions-E-Mails.

Nach der Umstellung: die alten Zugänge schließen

Eine Migration ist abgeschlossen, wenn nichts mehr vom alten System abhängt und niemand es versehentlich nutzen kann. Diese Checkliste arbeiten wir nach einem solchen Umzug ab:

• SPF verschärfen, sobald einige ruhige Tage zeigen, dass nichts mehr über den alten Server sendet: Entfernen Sie das Include des bisherigen Anbieters.
• Einen unabhängigen Export des alten Postfachs aufbewahren, bevor der alte Dienst gekündigt wird. Geben Sie dem alten Postfach außerdem ein langes Zufallspasswort, damit niemand es aus Gewohnheit weiter nutzt.
• Alle temporären Zugangsdaten widerrufen, die beim Umzug verwendet wurden: App-Passwörter für den Import, API-Clients, Hosting-Tokens.
• Sicherstellen, dass DMARC-Berichte tatsächlich ankommen (der Eintrag benötigt eine Berichtsadresse). Lesen Sie sie einige Wochen lang und stellen Sie die Richtlinie dann von p=none auf quarantine um.
• Google Postmaster Tools in Betracht ziehen, um Spamraten und Reputation bei Gmail zu beobachten. Bei geringem Versandvolumen sind dort womöglich nur wenige Daten sichtbar. Achten Sie deshalb weiterhin auf Unzustellbarkeitsmeldungen und Rückmeldungen von Empfängern.
• Dokumentieren, wo alles liegt: DNS, die Workspace-Administration, die Relay-Einstellungen und die Filter. Die nächste Person, die daran arbeitet, wird dankbar sein, auch wenn Sie es selbst in zwei Jahren sind.

Das Ergebnis

Die E-Mails des Shops werden jetzt über Googles Infrastruktur versendet und mit der eigenen Domain des Shops signiert. SPF, DKIM und DMARC bestehen die Prüfungen, der Großhändler erhält wieder Antworten, und die Beschwerden über unzustellbare Nachrichten haben aufgehört. Der einzige Rückläufer in den ersten Tagen nach der Umstellung war eine E-Mail zur Kontobestätigung an eine erfundene Adresse, die ein Bot ins Registrierungsformular eingetragen hatte. So eine Unzustellbarkeitsmeldung ist erwünscht.

Der Posteingang des Teams sieht aus wie zuvor, und jede alte Nachricht liegt dort, wo sie erwartet wird. „Gesendet“ enthält, was Menschen geschrieben haben. Die Benachrichtigungen des Shops liegen unter einem eigenen Label, nur einen Klick entfernt, wenn ein Kunde anruft.

Und eine ehrliche Fußnote: Am ersten Tag landeten unsere eigenen Testnachrichten an das neue Postfach im Spamordner. Sie kamen von einem kleinen Server von uns mit einwandfreier Authentifizierung und sehr kurzer Versandhistorie. Wir können Gmails Gründe nicht einsehen, aber die kurze Historie ist der wahrscheinlichste. Daraus folgt dieselbe Lehre wie aus dem gesamten Fall: Eine bestandene Authentifizierung bedeutet noch nicht, dass einem Absender vertraut wird.

Häufig gestellte Fragen

Quellen

• Google: MX-Einträge für Google Workspace einrichten
• Google: ausgehende SMTP-Relay-Nachrichten über Google leiten
• Google: Gmail-Versandlimits in Google Workspace
• Google: DKIM einrichten
• Google: umfassende E-Mail-Speicherung
• Gmail API: Nachrichten importieren