Landingpage · Google SMTP-Relay-Dienst

Was sollte ein Produktteam bei der Wahl des Google SMTP-Relay-Dienstes prüfen?

Wählen Sie das Google-Workspace-SMTP-Relay nur, wenn sein Administrations-, Identitäts- und Kontingentmodell zur Workload passt. Klären Sie, wer die Workspace-Domain und die Einstellung in der Admin-Konsole verantwortet, ob die Anwendung eine stabile, freigegebene öffentliche IP oder TLS-geschützte SMTP-Authentifizierung nutzen kann, welche Envelope-Absender erlaubt sind und wie TLS durchgesetzt wird. Modellieren Sie vor dem Rollout die aktuellen Limits von Google pro Nutzer, pro Kunde und pro Transaktion. Testen Sie temporäre und permanente Fehler, bewahren Sie SMTP-Antworten auf, authentifizieren Sie den sichtbaren Absender mit SPF, DKIM und DMARC und halten Sie Annahme, Zustellung an den Empfängerserver und Platzierung im Posteingang als getrennte Ergebnisse auseinander.

Mit Workload und administrativer Eignung beginnen

Der SMTP-Relay-Dienst von Google ist eine administrative Google-Workspace-Route für Anwendungen, Geräte und Mailserver, die über smtp-relay.gmail.com senden. Bewerten Sie ihn als Teil der Workspace- und Mail-Sicherheitsgrenze der Organisation und nicht als generischen anonymen SMTP-Endpunkt. Ermitteln Sie den verantwortlichen Workspace-Super-Admin, die Domains im Konto, Quellsysteme, öffentliche Egress-IPs, Absenderadressen, Nachrichtenklassen, Spitzen- und Tagesvolumen der Empfänger, das Anhangsprofil und den Ansprechpartner für Störfälle. Entscheiden Sie, ob die Workload transaktional, intern-operativ, nutzerverfasst, Bulk mit Abonnement oder gerätegeneriert ist. Halten Sie diese Klassen getrennt, weil sich Anforderungen an Autorisierung, Einwilligung, Sperrliste, Audit und Reputation unterscheiden. Bestätigen Sie, dass niedrigere Umgebungen keine Produktivrouten oder Kundenadressen nutzen können. Ein Relay kann eine autorisierte Nachricht transportieren. Es entscheidet nicht, ob das Geschäftsereignis legitim ist, ob ein Empfänger eingewilligt hat oder ob der nachgelagerte Anwendungszustand fortschreiten soll.

IP-Autorisierung und SMTP-Authentifizierung vergleichen

Die aktuelle Einrichtung von Google erlaubt Administratoren, die Relay-Annahme auf festgelegte öffentliche IP-Adressen zu beschränken, SMTP-Authentifizierung über TLS zu verlangen oder Richtlinienoptionen laut dokumentierter Einstellung zu kombinieren. Stabile IP-Autorisierung kann zu kontrollierten Rechenzentren oder festen Egress-Gateways passen, wird aber hinter wechselndem Cloud-NAT, mehreren Regionen, Failover-Diensten oder Fremdnetzen brüchig. SMTP-Authentifizierung identifiziert ein Workspace-Konto und die Absenderdomain, bringt aber Lebenszyklus der Zugangsdaten, Nutzerstatus, Wechselwirkungen mit Multi-Faktor und Richtlinien sowie eine harte TLS-Anforderung mit. Verwenden Sie nie eine breite Zugangsdatenkombination über Mandanten oder unverbundene Anwendungen hinweg. Dokumentieren Sie für jede Option, wer eine IP oder ein Konto hinzufügen darf, wie Änderungen geprüft werden, wie eine Kompromittierung erkannt wird, wie Zugriff entzogen wird und was das Failover bewirkt. Halten Sie die erlaubten IP-Bereiche so klein wie praktikabel und prüfen Sie die öffentliche Egress-Adresse in der tatsächlichen Laufzeitumgebung, statt eine interne Adresse zu kopieren.

Erlaubte Absender und Domain-Identität festlegen

Die Relay-Einstellung in der Admin-Konsole steuert, welche Absender erlaubt sind. Google dokumentiert Optionen für registrierte Apps-Nutzer und Adressen in eigenen Domains sowie eine weiter gefasste Option für beliebige Adressen, die das Missbrauchsrisiko erhöht. Wählen Sie die engste Option, die die Workload erfüllen kann. Erfassen Sie den SMTP-Envelope-Absender unabhängig von den sichtbaren Feldern From und Reply-To. Google weist darauf hin, dass bei einem Absender außerhalb der Kontodomains SMTP AUTH oder eine in HELO oder EHLO angegebene Domain beeinflussen kann, wie der Envelope-Absender identifiziert oder umgeschrieben wird. Verlassen Sie sich nicht auf Umschreiben als Ersatz für ein Modell eigener Absender. Verlangen Sie eine freigegebene Zuordnung aus Anwendung, Mandant, Nachrichtenklasse, Envelope-Absender, sichtbarer From-Domain und Return-Path. Blockieren Sie beliebige nutzerdefinierte Header, Newline-Injection und mandantenübergreifende From-Adressen, bevor Sie sich mit Google verbinden. Testen Sie Bounce-Routing und Abwesenheitsnachrichten, einschließlich eines leeren Envelope-Absenders, ohne die gesamte Einstellung aufzuweichen.

Transportsicherheit bewusst erzwingen

Die aktuelle Relay-Anleitung von Google verweist TLS-fähige On-Premise-Systeme auf smtp-relay.gmail.com an Port 587 und erklärt, dass SMTP-Authentifizierung TLS erfordert. Die Admin-Einstellung kann außerdem TLS für Verbindungen vom sendenden Server verlangen. Aktivieren Sie erforderliches TLS für den Produktivbetrieb, sofern keine dokumentierte Legacy-Einschränkung eine zeitlich begrenzte Ausnahme rechtfertigt. Validieren Sie Servernamen, Zertifikatskette, unterstützte Protokoll- und Cipher-Richtlinie, STARTTLS-Aushandlung und Fehlerverhalten. Der Client muss fail closed arbeiten, wenn erforderliches TLS nicht aufgebaut werden kann. Ein stilles Zurückfallen auf Klartext hebelt die Richtlinie aus. Schützen Sie SMTP-Zugangsdaten in einem verwalteten Secret Store und halten Sie sie aus Kommandozeilen, URLs, Quellcode, Logs, Analytics, Crash-Reports und Tickets heraus. Transport-TLS schützt den Hop zu Google, nicht den gesamten Nachrichtenlebenszyklus oder das Postfach. Sensible Inhalte können Kontrollen auf Anwendungsebene, Datenminimierung, Aufbewahrungsregeln und separate Entscheidungen zur Ende-zu-Ende-Verschlüsselung erfordern.

Aktuelle Kontingente modellieren, bevor Sie das Relay wählen

Die aktuelle Dokumentation zur SMTP-Relay-Einrichtung von Google nennt, dass jeder Nutzer innerhalb von 24 Stunden bis zu 10.000 Nachrichten an höchstens 10.000 eindeutige Empfänger senden kann, in Testphasen möglicherweise mit niedrigeren Limits. Sie dokumentiert außerdem ein Limit von 100 Empfängern pro SMTP-Transaktion sowie zusätzliche Kontrollen für Kunden, Spitzen und Tagesvolumen. Betrachten Sie dies als aktuell dokumentierte Obergrenzen und nicht als Kapazitätsziel oder dauerhaften Vertrag. Prüfen Sie die offizielle Seite vor dem Launch für Konto und Workload erneut. Berechnen Sie Empfänger, nicht nur Nachrichten, über To, Cc, Bcc, Wiederholungsversuche und Fan-out. Setzen Sie Rate, Parallelität, Warteschlangenalter und Mandantenfairness auf Anwendungsebene unterhalb der Google-Limits an. Lösen Sie Alarm bei Beschleunigung und verbleibendem Spielraum aus. Reagieren Sie auf ein Limit nicht damit, Traffic auf nicht autorisierte Konten zu verteilen, Envelope-Absender zu rotieren oder unkontrolliert Verbindungen zu öffnen. Eine Workload, die regelmäßig eine gemeinsame Workspace-Grenze erreicht, braucht womöglich die Bewertung eines dafür gebauten Transports.

Einen dauerhaften Einlieferungs-Workflow aufbauen

Stellen Sie den SMTP-Client hinter einen autorisierten Server-Worker oder eine Warteschlange. Speichern Sie einen ausgehenden Job mit stabilem Geschäftsereignis-Schlüssel, Mandant, Nachrichtenklasse, Template-Revision, freigegebenem Absender und Empfängern, Einwilligungs- oder Erforderlichkeitsgrundlage, Sperrlisten-Entscheidung und Versuchsverlauf. Übernehmen Sie diesen Job genau einmal, rendern und validieren Sie den Inhalt und verbinden Sie sich dann mit dem konfigurierten Google-Endpunkt. Begrenzen Sie Empfänger pro Transaktion und Nachrichtengröße gemäß aktuellen Limits und Produktrichtlinie. Erfassen Sie die vollständige SMTP-Antwort, den erweiterten Statuscode, den Remote-Host, den Zeitstempel und die Versuchskennung, ohne Zugangsdaten oder unnötige Inhalte zu protokollieren. Wenn das Relay die DATA-Transaktion akzeptiert, markieren Sie nur die Phase der Provider- oder Relay-Annahme. Läuft der Client nach dem Senden der Daten, aber vor der endgültigen Antwort in ein Timeout, belassen Sie den Versuch als unbekannt und gleichen Sie ihn ab, bevor Sie erneut senden. SMTP bietet keinen Idempotenzschlüssel für Anwendungen, daher gehört die Duplikatkontrolle in die Produkt-Warteschlange und das Event-Modell.

Relay-Fehler klassifizieren, statt alles zu wiederholen

Die Fehlerseite zum SMTP-Relay von Google dokumentiert unterschiedliche Zustände, darunter verweigertes Mail-Relay, ungültige Relay-Zugangsdaten oder Domain-Identifikation, überschrittenes Tageslimit, temporäres Zurückstellen wegen Spitzenlimit und zu viele Empfänger in einer Transaktion. Erfassen Sie die genaue Antwort und ordnen Sie sie einer engen internen Klasse zu. Beheben Sie Fehler bei Konfiguration, Absenderdomain, Zugangsdaten, IP und Empfängerzahl pro Transaktion, bevor Sie erneut abspielen. Pausieren oder verschieben Sie Arbeit, wenn das Tageslimit erschöpft ist. Wiederholen Sie infrage kommende temporäre Spitzen- oder Transportfehler mit exponentiellem Backoff, Jitter, Versuchsobergrenzen und Warteschlangenalter-Limits. Wiederholen Sie eine permanente Antwort niemals endlos. Nennt ein Fehler eine nicht registrierte IP, bestätigen Sie die tatsächliche öffentliche Egress-Adresse der Laufzeitumgebung und die richtige Workspace-Einstellung, statt die Allowlist zu erweitern. Bewahren Sie datenschutzminimierte aggregierte Zählwerte nach Quellsystem, Konfigurationsrevision, Absenderdomain, Statusklasse und Zeit auf. Lösen Sie Alarm bei neuartigen Antworten und Authentifizierungsspitzen aus, denn sie können auf Richtlinienabweichung, Widerruf von Zugangsdaten, NAT-Änderung oder Missbrauch hindeuten.

Den Absender über den Relay-Zugriff hinaus authentifizieren

Die Erlaubnis, das Relay von Google zu nutzen, ist nicht dasselbe wie empfängerseitige Absenderauthentifizierung. Veröffentlichen Sie eine SPF-Richtlinie, die den tatsächlichen Sendeweg für die Envelope-Identität autorisiert, konfigurieren Sie DKIM-Signierung mit einer von der Organisation kontrollierten, DMARC-ausgerichteten Domain und veröffentlichen Sie eine geprüfte DMARC-Richtlinie für die sichtbare From-Domain. Prüfen Sie die rohe empfangene Nachricht in kontrollierten externen Postfächern. Erfassen Sie SPF-Ergebnis und Domain, DKIM-Ergebnis, d=-Domain und Selektor, sichtbare From-Domain, Alignment und DMARC-Ergebnis. Eine technisch gültige Signatur von Provider oder Workspace kann mit einer eigenen From-Domain unausgerichtet bleiben. Auch Weiterleitungen können den SPF-Nachweis verändern. Fügen Sie keinen zweiten SPF-Eintrag hinzu und schwächen Sie DMARC nicht organisationsweit ab, nur damit ein Test besteht. Stimmen Sie sich mit DNS- und Mail-Administratoren ab, bewahren Sie frühere Einträge auf, testen Sie autoritative und rekursive Antworten und führen Sie jeweils nur eine Identitätsänderung ein.

Observability und einen getesteten Ausstiegsweg verlangen

Nutzen Sie die E-Mail-Log-Suche der Google Admin-Konsole und Relay-seitige Logs, wo verfügbar, behalten Sie aber das produkteigene Ausgangsbuch als entscheidendes System. Überwachen Sie Warteschlangenalter, Annahme, temporäre und permanente Antworten, Limitnutzung, Bounce- und Beschwerdesignale, Authentifizierung und Latenz nach Nachrichtenklasse und Absenderdomain. Beschränken Sie den Zugriff und vermeiden Sie vollständige Adressen oder Inhalte in Routine-Metriken. Testen Sie Änderungen der Quell-IP, Rotation von Zugangsdaten, TLS-Fehler, Deaktivierung der Admin-Einstellung, Nutzersperrung, erschöpfte Limits, Empfänger-Fan-out, DNS-Änderungen und Provider-Ausfall. Definieren Sie ein Rollback, das die betroffene Kohorte pausieren kann, ohne dauerhafte Jobs zu verwerfen. Isolieren Sie für die Migration providerspezifische SMTP-Felder in einem Adapter und bewahren Sie Geschäftsereignis-Schlüssel, Sperrlisten-Zustand, Absenderautorisierung und Versuchsverlauf. Ein zweites Relay darf nicht zur automatischen Umgehung dauerhafter Richtlinien- oder Empfängerablehnungen werden. Kompatibilität erfordert Tests auf Feld- und Fehlerebene und nicht nur das Ändern eines Hostnamens.

So passt SendHQ

SendHQ ist eine auf den Workspace beschränkte E-Mail-API für erwartete Produktkommunikation mit Versand über verifizierte Domains, eingehenden E-Mails, gehosteten Templates, Zustell-Events, Sperrlisten und einem Web-Dashboard. Vergleichen Sie es anhand aktueller Dokumentation und kontrollierter Tests mit Google Workspace SMTP relay: Konto- und Mandantengrenzen, Zugangsdaten und Rotation, Durchsetzung erlaubter Absender, Envelope- und sichtbare Identitäten, TLS-Fehler, Empfängerlimits, temporäre und dauerhafte Antworten, mehrdeutige Ergebnisse, Sperrlisten, Event-Auslesen und Migration.

Häufig gestellte Fragen

Welchen Hostnamen verwendet Google Workspace für SMTP-Relay?

Die aktuelle Einrichtungsanleitung von Google verwendet smtp-relay.gmail.com. Wählen Sie Port und TLS-Verhalten anhand der offiziellen Anleitung und der durchgesetzten Sicherheitsrichtlinie der Organisation.

Lässt sich das Google SMTP-Relay nach Quell-IP einschränken?

Ja. Die Admin-Einstellung kann ausschließlich festgelegte öffentliche IP-Adressen akzeptieren. Halten Sie die Bereiche eng und prüfen Sie die tatsächliche Egress-Adresse der Laufzeitumgebung und das Failover-Verhalten.

Funktioniert die SMTP-Authentifizierung bei diesem Relay ohne TLS?

Laut der aktuellen Anleitung von Google erfordert SMTP-Authentifizierung TLS. Produktive Clients sollten fail closed arbeiten, wenn die erforderliche TLS-Aushandlung oder Zertifikatsprüfung nicht gelingt.

Wie viele Empfänger kann eine SMTP-Relay-Transaktion enthalten?

Google dokumentiert derzeit ein Limit von 100 Empfängern pro Transaktion über smtp-relay.gmail.com. Prüfen Sie die aktuelle offizielle Seite erneut, da sich Provider-Limits und Kontobedingungen ändern können.

Sollte ein Fehler wegen Spitzenlimit des Relays wiederholt werden?

Google beschreibt das Erreichen des Spitzenlimits als temporär. Behalten Sie denselben dauerhaften Job bei und nutzen Sie begrenzten Backoff, Jitter, Versuchsobergrenzen und Warteschlangenalter-Limits statt sofortigem Fan-out.

Bedeutet die Annahme durch das Relay, dass der Empfänger die E-Mail erhalten hat?

Nein. Die Relay-Annahme ist eine Transportphase. Annahme durch den Empfängerserver, späterer Bounce, Postfachfilterung, Platzierung im Posteingang und menschliche Interaktion bleiben getrennte Beobachtungen.

Kann der Relay-Zugriff von Google SPF, DKIM und DMARC ersetzen?

Nein. Die Relay-Autorisierung steuert die Nutzung des Google-Dienstes. Empfängerseitige Authentifizierung und DMARC-Alignment erfordern korrekte Absenderidentitäten, DNS-Einträge, Signaturen und die Prüfung empfangener Nachrichten.

Belegt diese Seite, dass SendHQ mit dem Google SMTP-Relay kompatibel ist?

Nein. Vergleichen Sie die dokumentierten Funktionen von SendHQ mit den Anforderungen von Google Workspace SMTP relay und verwenden Sie kontrollierte Tests für Authentifizierung, TLS, Kontingente, Fehler und das Auslesen von Zustell-Events.

Quellen

Weiterlernen

So bewerten Sie einen SMTP-Relay-ServiceSMTP-Relay-Services nach Einlieferungssicherheit, Authentifizierung, Warteschlangen, Wiederholungsverhalten, Limits, Zustell-Events, Sperrlisten, Isolation und Migrationseignung bewerten.SMTP-Mailprotokoll: Wie Anwendungs-E-Mails übertragen werdenErfahren Sie, wie SMTP-Einlieferung, Relay, Envelopes, Antwortcodes, TLS, Wiederholungsversuche und Nachrichteninhalt einen E-Mail-Workflow einer Anwendung prägen.SMTP-Ports 25, 465 und 587: Ein praktischer LeitfadenWählen Sie den passenden SMTP-Port nach Rolle und TLS-Modus und diagnostizieren Sie Fehler bei Verbindung, Handshake, Authentifizierung und Nachrichtenannahme.So bewerten Sie einen E-Mail-ZustellbarkeitsdienstE-Mail-Zustellbarkeitsdienste nach Umfang, Nachweisen, Authentifizierung, Feedback-Loops, Sperrlisten, Datenschutz, Portabilität und betrieblicher Eignung bewerten.Gmail API: Implementierungsleitfaden für ProduktteamsGmail-API-Zugriff mit OAuth nach dem Prinzip der minimalen Rechte, dauerhafter Postfach-Synchronisierung, sicherem Versand, begrenzten Wiederholungsversuchen und einem klaren Service-Account-Modell implementieren.