Domain-E-Mails an Gmail weiterleiten: Einrichtung und Prüfung

Sie richten contact@yourdomain.com so ein, dass die E-Mails Ihrer Domain an Gmail weitergeleitet werden. Ein Kunde schickt einen Vertrag, eine Bank einen Sicherheitshinweis. Beide Nachrichten kommen nicht an.

Auch im Spamordner ist nichts zu finden. Bei Ihnen erscheint weder eine Spur der Nachrichten noch eine Fehlermeldung. Ob der ursprüngliche Absender einen Hinweis erhält, hängt vom Zustellablauf ab.

Das muss nicht an Gmail selbst liegen. Eine mögliche Ursache ist die Authentifizierung. Wenn Sie E-Mails Ihrer Domain an Gmail weiterleiten, überträgt Ihr Server eine fremde Nachricht von seiner eigenen IP-Adresse. Bleibt der Envelope-Absender erhalten, prüft Gmail SPF für dessen Domain, die Ihre IP gewöhnlich nicht autorisiert. SPF schlägt fehl. Bei einer strengen DMARC-Richtlinie (p=reject) und fehlender gültiger, passender DKIM-Authentifizierung kann Gmail die Nachricht mit 550-5.7.26 ablehnen. Der weiterleitende Server erhält diesen SMTP-Fehler; eine Unzustellbarkeitsmeldung kann den ursprünglichen Absender erreichen, während Sie keinen Hinweis bekommen.

SRS (Sender Rewriting Scheme) zur Umschreibung des Envelope-Absenders und ARC (Authenticated Received Chain) zur Dokumentation der Authentifizierung können das Weiterleiten an Gmail unterstützen. Beide Verfahren sind wichtige Infrastrukturbausteine, garantieren aber weder einen erfolgreichen DMARC-Domainabgleich noch die Zustellung. Eine erhaltene, passende DKIM-Signatur kann DMARC auch dann bestehen lassen, wenn SPF scheitert.

Dieser Leitfaden behandelt die Einrichtung: SRS-Umschreibung, Vermeidung von Schleifen und Gmails Funktion „Senden als“. Die Protokollgrundlagen, das Zusammenspiel von SPF, DKIM und DMARC bei Weiterleitungen sowie die technische Funktionsweise von SRS erklärt der vollständige Leitfaden zur Einrichtung und Fehlerbehebung bei E-Mail-Weiterleitungen.

Warum Gmail weitergeleitete E-Mails ablehnen kann

Bei einer Weiterleitung kann SPF fehlschlagen, weil die IP Ihres Weiterleitungsservers nicht im SPF-Eintrag der ursprünglichen Absenderdomain steht. SRS schreibt den Envelope-Absender so um, dass Gmail SPF für Ihre Domain prüft. Dafür muss diese Domain Ihren Server autorisieren. Ohne gültige, zur sichtbaren Absenderdomain passende Authentifizierung können strenge DMARC-Richtlinien zur Ablehnung führen.

So kann die Fehlerkette aussehen, wenn eine Nachricht von client@bank.com an you@gmail.com weitergeleitet wird:

1. bank.com liefert an Ihren Weiterleitungsserver
2. Ihr Server überträgt die Nachricht an Gmail
3. Gmail prüft SPF für den Envelope-Absender: client@bank.com
4. Der SPF-Eintrag von bank.com enthält die IP Ihres Servers nicht → SPF FAIL
5. Die DMARC-Richtlinie lautet p=reject; ohne passende DKIM-Authentifizierung kann Gmail 550-5.7.26 zurückgeben
6. Die Nachricht wird nicht zugestellt. Sie erhalten möglicherweise keinen Hinweis; eine Fehlermeldung an bank.com hängt vom Weiterleitungsserver ab.

DKIM kann eine Weiterleitung unverändert überstehen, sofern die signierten Teile der Nachricht erhalten bleiben. Angehängte Virenscanner-Fußzeilen oder Änderungen eines signierten Betreffs können die Signatur ungültig machen. Mit gültiger, passender DKIM-Signatur kann Gmail DMARC trotz SPF-Fehler bestehen lassen. Die Einstellung aspf=s betrifft den strengen SPF-Domainabgleich und verändert den DKIM-Abgleich nicht. SRS kann SPF unterstützen, ist jedoch allein keine garantierte Lösung für DMARC oder Zustellprobleme.

Drei Möglichkeiten, Domain-E-Mails an Gmail weiterzuleiten

Nicht jede Weiterleitung bringt dieselben Risiken mit sich. Wählen Sie vor der Einrichtung eine Architektur, die zu Ihrem Anwendungsfall passt.

Ein Catch-all kann die Zustellbarkeit besonders stark beeinträchtigen. Spammer testen zufällige Adressen wie abc123@yourdomain.com und junk@yourdomain.com. Ihr Server nimmt diese Nachrichten an und leitet sie an Gmail weiter. Besteht der weitergeleitete Verkehr im Beispielszenario zu 90% aus Spam, kann Gmail die Reputation Ihrer Versand-IP schlechter bewerten oder sie blockieren. Auch legitime E-Mails können dann im Spamordner landen. Die Erholung der Reputation kann Wochen dauern; der Anteil ist kein allgemeiner Messwert oder garantierter Schwellenwert.

Wann Aliasse sinnvoll sind und wann vollständige Postfächer besser passen, erläutert der Artikel über Risiken und Abwägungen bei Alias-Weiterleitungen. Für die Entscheidung bei einer neuen Adresse bietet der Vergleich von Domain-Alias und Postfach konkrete Kriterien.

SRS: Warum es für Weiterleitungen an Gmail wichtig ist

SRS (Sender Rewriting Scheme) kann SPF-Fehler auf Envelope-Ebene reduzieren. Es schreibt den Envelope-Absender, der im Return-Path erscheint und für Fehlermeldungen verwendet wird, von der ursprünglichen Domain auf Ihre Domain um. Gmail prüft dann SPF für Ihre Domain. Ist Ihre Server-IP dort korrekt autorisiert, kann SPF bestehen. Daraus folgt jedoch keine automatische Zustellung oder DMARC-Konformität.

Ohne SRS (Fehlerszenario):
Envelope From: client@bank.com
Versand-IP: 203.0.113.10 (Ihr Weiterleitungsserver)
SPF-Prüfung: SPF-Eintrag von bank.com → FAIL (203.0.113.10 nicht enthalten)
DMARC: FAIL (p=reject), sofern auch passendes DKIM fehlt → mögliche Ablehnung

Mit SRS (SPF im Beispiel erfolgreich):
Envelope From: SRS0=HASH=TT=bank.com=client@yourdomain.com
Versand-IP: 203.0.113.10 (Ihr Weiterleitungsserver)
SPF-Prüfung: SPF-Eintrag von yourdomain.com → PASS (203.0.113.10 ist enthalten)
Header From: client@bank.com (unverändert, Sie sehen den ursprünglichen Absender)

Ihr SPF-Eintrag muss den tatsächlichen Versandweg autorisieren, beispielsweise die IP Ihres Weiterleitungsservers oder die passenden Mechanismen für den Versanddienst. Ohne diese Autorisierung kann SPF auch nach SRS scheitern: Die umgeschriebene Adresse verwendet Ihre Domain, deren SPF-Eintrag den Server aber nicht erlaubt.

Gut konfigurierte Weiterleitungsinfrastruktur kann zusätzlich Header für ARC (Authenticated Received Chain) ergänzen. Die kryptografisch signierte Kette dokumentiert tatsächlich beobachtete Authentifizierungsergebnisse an den beteiligten Stationen. Google kann sie bei vertrauenswürdigen Weiterleitern berücksichtigen. ARC benötigt eine eigene korrekte Signaturkonfiguration; eine gewöhnliche DKIM-Signatur allein ersetzt ARC nicht. Bei gehosteter E-Mail liegt die Implementierung beim Anbieter.

Die SPF-Spezifikation steht in RFC 7208. ARC, das die Authentifizierungsinformationen über mehrere Übertragungsschritte dokumentiert, ist in RFC 8617 definiert.

Schleifen vermeiden: Vier Prüfungen vor dem Einsatz

Weiterleitungsschleifen können Fehler wie 5.4.14 Hop count exceeded verursachen und legitime Nachrichten unzustellbar machen. Prüfen Sie vor dem produktiven Einsatz diese vier Punkte.

1. Keine kreisförmigen Routen. Stellen Sie sicher, dass you@gmail.com keinen Filter hat, der Nachrichten an you@yourdomain.com zurückleitet. Verweist diese Adresse wieder auf Gmail, entsteht eine Schleife.
2. Automatische Antworten kontrollieren. Bei Funktionsadressen (team@domain.com → mehrere Gmail-Konten) deaktivieren Sie unnötige automatische Antworten oder richten Sie geeigneten Schleifenschutz ein. Header wie Precedence: bulk können berücksichtigt werden, sind aber kein vollständiger Schutz für sich allein.
3. Von einem dritten Konto testen. Gmail kann doppelte Nachrichten unterdrücken. Ein Test vom Zielkonto an den eigenen Alias erscheint daher möglicherweise nur unter Gesendet. Testen Sie zusätzlich von einem unabhängigen Yahoo- oder Outlook-Konto.
4. Ausgehende M365-Richtlinie prüfen. Bei Microsoft 365 muss externe automatische Weiterleitung durch die geltende ausgehende Spamrichtlinie erlaubt sein. Eine autorisierte Administration kann die Einstellung nach Risikoprüfung anpassen. Andernfalls kann 550 5.7.520 auftreten.

Das sind verbreitete Fehlerquellen bei der ersten Weiterleitung von Domain-E-Mails an Gmail. Die Fehlermeldung allein erklärt ihre Ursache nicht immer eindeutig.

Domain-E-Mails mit TrekMail an Gmail weiterleiten

Im beschriebenen Funktionsstand übernimmt TrekMail SRS-Umschreibung und ARC-Signierung auf MTA-Ebene für unterstützte Weiterleitungen. Sie hinterlegen die Zieladresse, die Verarbeitung erfolgt serverseitig. Maßgeblich ist der aktuelle Funktionsumfang; über die Annahme einer Nachricht entscheidet weiterhin Gmail.

In diesem Tarifstand gehört die Postfachweiterleitung zu den Tarifen Pro und Agency, nicht zu Free oder Starter. Vergleichen Sie vor einem Wechsel die aktuellen Tarifbedingungen. Die Einrichtung erläutert die Dokumentation zur TrekMail-Postfachweiterleitung:

1. Öffnen Sie Postfächer im Dashboard
2. Wählen Sie beim gewünschten Postfach Verwalten
3. Schalten Sie Weiterleitung aktivieren ein
4. Tragen Sie Ihre Gmail-Adresse in Weiterleiten an ein
5. Aktivieren Sie Kopie behalten und lassen Sie dies während der Einrichtung eingeschaltet
6. Klicken Sie auf Weiterleitungseinstellungen speichern

Die Option „Kopie behalten“ ist wichtig. Im beschriebenen Modus bleibt eine Kopie im Postfach, sofern Kontingent und lokale Zustellung dies zulassen, während zusätzlich die Weiterleitung an Gmail versucht wird. Ohne diese Option fehlt diese lokale Kopie; bei einer Ablehnung durch Gmail hängt das weitere Vorgehen von Warteschlange und Fehlerbehandlung ab. Lassen Sie die Option eingeschaltet, bis Sie den Empfang und die Header geprüft haben. Sie ersetzt keine Sicherungs- oder Aufbewahrungsstrategie.

Die Quelle beschreibt für Agenturen eine Sammelaktion: Mehrere Postfächer auswählen und über das Aktionsmenü dasselbe Weiterleitungsziel zuweisen. So kann die Konfiguration auch für hundert Domains effizienter werden, soweit aktuelle Funktionen und Grenzen dies unterstützen. Prüfen Sie die Auswahl vor dem Anwenden.

Auch den Versand einrichten: „Senden als“ in Gmail

Weiterleitung regelt den Empfang. Ohne passende „Senden als“-Konfiguration können Antworten jedoch von Ihrer privaten @gmail.com-Adresse statt von Ihrer Domain kommen. Der Kunde sieht dann Gmail statt ceo@yourdomain.com.

Verwenden Sie Gmails Funktion „Senden als“ mit autorisierten externen SMTP-Zugangsdaten, sofern die Konfiguration unterstützt wird. Die Option „Als Alias behandeln“ allein legt den Versandweg nicht zuverlässig fest. Prüfen Sie den tatsächlich verwendeten Server, die sichtbare Absenderadresse und den DMARC-Domainabgleich, statt allein auf diese Checkbox zu vertrauen.

In Gmail: Einstellungen → Konten und Import → Senden als → Weitere E-Mail-Adresse hinzufügen. Prüfen Sie „Als Alias behandeln“ passend zu Ihrer Konfiguration; das Deaktivieren allein garantiert kein bestimmtes Authentifizierungsergebnis.

TrekMail-SMTP-Einstellungen laut Quelle (Starter, Pro, Agency):

SMTP Server:  smtp.trekmail.net
Port:         587
Security:     TLS (STARTTLS)
Username:     your-mailbox@yourdomain.com
Password:     Your mailbox password

Nano laut Quelle: eigener SMTP-Dienst (SES, SendGrid, Mailgun usw.):

SMTP Server:  email-smtp.us-east-1.amazonaws.com  (Amazon SES example)
Port:         587
Security:     TLS
Username:     Your SMTP credentials from your provider

Die SMTP-Blöcke sind Beispiele; bestätigen Sie die aktuellen Verbindungsdaten beim jeweiligen Anbieter. Bei der Einrichtung kann Gmail einen Bestätigungscode an das Postfach senden. Geben Sie ihn gemäß dem aktuellen Ablauf ein und wählen Sie die Domainadresse gegebenenfalls als Standardabsender. Testen Sie anschließend auch Antworten auf weitergeleitete Nachrichten, denn deren Absender hängt von den Kontoeinstellungen ab.

Ergebnis prüfen: Gmails Authentifizierungsheader lesen

Wenn eine Testnachricht eines externen Kontos in Gmail angekommen ist, prüfen Sie vor dem produktiven Einsatz die vollständigen Header.

In Gmail: Nachricht öffnen → Dreipunktmenü → Original anzeigen. Suchen Sie nach Authentication-Results.

Ein beispielhaftes Ergebnis mit erfolgreichen Prüfungen kann so aussehen; es zeigt für sich allein keinen erfolgreichen DMARC-Domainabgleich:

Authentication-Results: mx.google.com;
  spf=pass (google.com: domain of SRS0=hash=tt=bank.com=client@yourdomain.com
    designates 203.0.113.10 as permitted sender)
    smtp.mailfrom=SRS0=hash=tt=bank.com=client@yourdomain.com;
  dkim=pass header.i=@yourdomain.com;
  arc=pass (i=1 spf=pass dkim=pass)

Bei spf=softfail oder spf=fail prüfen Sie SRS-Umschreibung und die Autorisierung der tatsächlichen Versand-IP im SPF-Eintrag. Auch andere Konfigurationsfehler sind möglich. arc=fail kann unter anderem auf Änderungen signierter Inhalte, ungültige Signaturen oder Probleme der ARC-Kette hinweisen. Die offiziellen Hinweise von Google zu Weiterleitungen an Gmail behandeln die passende Verwendung des Envelope-Absenders. SRS ist ein Verfahren für dessen Umschreibung.

Eigenbetrieb oder verwalteter Dienst: die tatsächliche Abwägung

Auf einem selbst verwalteten Postfix-Server können Sie beispielsweise postsrsd installieren, die Datei srs_secret sicher verwalten und ihre Rotation planen, OpenARC mit geeigneten Signaturschlüsseln einrichten und die Reputation über Google Postmaster Tools beobachten, soweit dort Daten verfügbar sind. Abhängigkeiten, fehlerhafte Schlüsselrotation oder veränderte Absenderrichtlinien können dennoch Störungen verursachen. Dann analysieren Sie womöglich um 11 Uhr abends Authentifizierungsheader.

Die beschriebene MTA-Verarbeitung entlastet Sie nach der Einrichtung des Weiterleitungsziels bei SRS und ARC. Domainauthentifizierung, aktuelle Unterstützung und Testergebnisse müssen dennoch geprüft werden; laufende Kontrolle bleibt sinnvoll.

Die ersten Schritte

Für die grundlegende Einrichtung einer einzelnen Domain nennt die Quelle Nano ohne Kreditkarte. Dieser Tarif bietet laut der beschriebenen Tarifaufteilung jedoch nicht die Postfachweiterleitung selbst. Für die unterstützte Weiterleitung mit serverseitigem SRS wird Pro genannt, pauschal ab $10/Monat ohne Nutzergebühr innerhalb der Tarifgrenzen. Prüfen Sie die aktuellen Bedingungen und schließen Sie die Domainprüfung ab, bevor Sie testen.

Die Quelle nennt für kostenpflichtige Tarife eine kostenlose Testphase von 14 Tagen mit erforderlicher Kreditkarte. Alternativ finden Sie unter trekmail.net/pricing die aktuellen Bedingungen für Nano und die kostenpflichtigen Tarife.

Für eine belastbare Weiterleitung an Gmail sind vier Punkte wichtig: SRS schreibt den Envelope-Absender um, ARC dokumentiert die Authentifizierung, SPF autorisiert die tatsächliche Versand-IP und „Senden als“ richtet den Antwortversand ein. Keiner dieser Punkte garantiert allein oder gemeinsam die Zustellung. Prüfen Sie auch passendes DKIM, die Empfangsrichtlinien und die Fehlerbehandlung, damit fehlende Nachrichten möglichst früh auffallen.

Einrichten, Header prüfen und die Ergebnisse im Betrieb weiter beobachten.