E-Mail an eine andere Adresse weiterleiten: Fehler prüfen

Sie richten eine Weiterleitung ein, schicken eine Testnachricht und alles funktioniert. Sie wenden sich anderen Aufgaben zu.

Dann meldet ein Kunde, dass Ihre Antwort nicht angekommen ist. Sie sehen weder eine Rückläufermeldung noch einen NDR. Irgendwo zwischen den Servern scheint die Nachricht verschwunden zu sein; die Ursache lässt sich nur anhand der Zustellprotokolle klären.

Beim Weiterleiten einer E-Mail an eine andere Adresse öffnet Ihr Server eine neue SMTP-Verbindung zum Ziel. Dort wird SPF anhand Ihrer IP geprüft, nicht anhand der IP des ursprünglichen Absenders. Ist Ihre IP für dessen Envelope-Domain nicht autorisiert, kann SPF fehlschlagen. Bleibt auch keine gültige, zur sichtbaren Absenderdomain ausgerichtete DKIM-Signatur erhalten, scheitert DMARC. Bei p=reject fordert die Domain eine Ablehnung; ob eine Nachricht abgewiesen, gefiltert oder anders behandelt wird und ob eine Fehlermeldung entsteht, hängt vom Empfänger ab.

Das muss kein Tippfehler in der Konfiguration sein. Weiterleitung und moderne Authentifizierung passen nicht immer zusammen. Der vollständige Leitfaden zur Einrichtung und Fehlerbehebung bei E-Mail-Weiterleitungen behandelt die verschiedenen Szenarien. Hier geht es um die Authentifizierung: typische Fehler, Fehlercodes und geeignete Gegenmaßnahmen.

Warum Authentifizierung bei der Weiterleitung scheitern kann

Beim Weiterleiten prüft der empfangende MTA SPF anhand der IP des Weiterleitungsservers. Eine E-Mail besitzt unterschiedliche Absenderidentitäten, die dabei auseinanderfallen können. SPF prüft den Envelope-Absender; DMARC verlangt einen erfolgreichen SPF- oder DKIM-Nachweis, dessen Domain zur sichtbaren From-Domain ausgerichtet ist. Fehlen beide, schlägt DMARC fehl; die weitere Behandlung bestimmt die Empfängerrichtlinie.

Die Kette: Server A sendet an Ihren Weiterleitungsserver B, der eine neue TCP-Verbindung zu Ziel C öffnet. C sieht die IP von B. SPF fragt anhand des DNS der Envelope-Absenderdomain: "Darf diese IP für diese Domain senden?" Ist B nicht autorisiert, kann SPF fehlschlagen. Das ist häufig, aber nicht bei jeder Weiterleitung zwingend der Fall.

Für DMARC genügt ein erfolgreicher, ausgerichteter SPF- oder DKIM-Nachweis. Eine erhaltene DKIM-Signatur der ursprünglichen From-Domain kann die weitergeleitete Nachricht daher absichern. Entscheidend sind die signierten Header und der kanonisierte Nachrichteninhalt: Nicht jede Änderung macht DKIM ungültig. Fallen beide ausgerichteten Nachweise aus, scheitert DMARC. Bei p=reject wird eine Ablehnung verlangt, aber keine bestimmte Zustell- oder Rückläuferbehandlung garantiert.

Drei typische Fehlerbilder

Bei der Weiterleitung können drei unterschiedliche Probleme auftreten: eine administrative Sperre, fehlgeschlagene Authentifizierung oder eine Routingschleife. Ursache und Lösung unterscheiden sich. Nicht jeder Fehler hat einen festen SMTP-Code; die Zuordnung hilft dennoch bei der Diagnose.

1. Microsoft 365 sperrt ausgehende Weiterleitungen (550 5.7.520)

Microsoft 365 betrachtet automatische externe Weiterleitungen als mögliches Mittel zum Datenabfluss. Die wirksame Standardrichtlinie kann eine Weiterleitungsregel zu einer Adresse außerhalb des Mandanten blockieren, bevor die Nachricht Exchange Online verlässt.

550 5.7.520 Access denied, Your organization does not allow external forwarding.

Dies ist eine Richtliniensperre, kein Protokollfehler. Eine autorisierte Administration kann folgendermaßen vorgehen:

1. Öffnen Sie das Microsoft 365 Defender Portal.
2. Gehen Sie zu Email & collaboration → Policies & rules → Threat policies → Anti-spam.
3. Erstellen oder bearbeiten Sie die Outbound spam filter policy ausschließlich für ausdrücklich autorisierte Konten.
4. Setzen Sie dort Automatic forwarding auf On - Forwarding is enabled, sofern dies genehmigt ist.

Ändern Sie nicht pauschal die organisationsweite Standardrichtlinie. Eine globale Freigabe erhöht das Risiko bei kompromittierten Konten. Verwenden Sie eine gezielt zugeordnete Richtlinie, MFA und Überwachung des ausgehenden Mailvolumens; prüfen Sie auch andere wirksame Weiterleitungssperren.

2. Beide DMARC-Nachweise fehlen

Dieses Fehlerbild ist leicht zu übersehen. Die neue IP kann SPF scheitern lassen. Eine gültige, ausgerichtete DKIM-Signatur kann DMARC weiterhin bestehen lassen. Änderungen am signierten Inhalt oder an signierten Headern können jedoch auch DKIM ungültig machen; maßgeblich sind Signaturumfang und Kanonisierung, nicht jede beliebige Inhaltsänderung.

Häufige Änderungen, die DKIM beeinträchtigen können:

• Von Antivirensoftware angehängte Fußzeilen: "Geprüft von [Produktname]"
• Betreffzusätze des Zielgateways, sofern der Betreff signiert ist: [EXT] oder [EXTERNAL]
• In den HTML-Text eingefügte Warnbanner für "externe Absender"
• Mailinglisten, die signierte Header umschreiben oder Abmeldefußzeilen anhängen

Fehlt sowohl ein ausgerichteter SPF-Erfolg als auch eine gültige, ausgerichtete DKIM-Signatur, meldet DMARC (RFC 7489) FAIL. Bei p=reject verlangt die Absenderdomain die Ablehnung. Empfänger können ihre eigene Richtlinie anwenden; eine Ablehnung mit Rückläufer, Quarantäne oder andere Behandlung ist möglich. Fehlende Benachrichtigungen beweisen keinen stillen Verlust.

3. Routingschleifen (554 5.4.14)

Schleifen entstehen, wenn Server eine Nachricht wiederholt aneinander zurückgeben, bis ein Hop-Limit greift. Sie können NDRs erzeugen, allerdings nicht zwingend sofort oder in jedem Fall. Warteschlangen und andere Zustellungen können dadurch verzögert werden.

Mögliche Auslöser:

• Benutzer A leitet an Benutzer B weiter; B leitet wiederum an A zurück.
• A leitet an B weiter; eine Abwesenheitsantwort von B wird erneut zu B geleitet. Eine Antwortschleife ist möglich, wenn die beteiligten Systeme automatische Antworten nicht ausreichend unterdrücken.
• Eine Catch-all-Adresse leitet an ein Postfach weiter, das wiederum eine nicht vorhandene Adresse derselben Domain als Ziel verwendet; je nach Catch-all-Regeln kann dies einen Kreis bilden.

554 5.4.14 Hop count exceeded - possible mail loop

Prüfen Sie vor dem Produktivbetrieb immer die gesamte Routingkette, einschließlich automatischer Antworten und Catch-all-Ziele.

Gegenmaßnahmen: SRS und ARC

Zwei serverseitige Mechanismen können die Weiterleitung verbessern, garantieren aber keine Zustellung. SRS schreibt den Envelope-Absender um, sodass SPF für die Weiterleitungsdomain bestehen kann, wenn deren DNS die sendende IP autorisiert. ARC dokumentiert frühere Authentifizierungsergebnisse für Empfänger, die dem Weiterleiter vertrauen und gegebenenfalls eine DMARC-Ausnahme zulassen. Eine reine Mailclient-Regel implementiert diese Mechanismen nicht.

SRS: Sender Rewriting Scheme

SRS schreibt den Envelope-Absender (P1) auf eine von Ihnen kontrollierte Domain um. Statt weiterhin alice@bank.com als Envelope-Absender zu verwenden, obwohl Ihre IP für diese Domain möglicherweise nicht autorisiert ist, erzeugt Ihr Weiterleitungsserver beispielsweise:

SRS0=Hash=Timestamp=bank.com=alice@your-forwarding-domain.com

SPF prüft nun die Weiterleitungsdomain. Autorisiert ihr SPF-Eintrag die ausgehende IP und treten keine anderen SPF-Fehler auf, kann die Prüfung bestehen. Dies stellt allein keine DMARC-Ausrichtung zur ursprünglichen From-Domain her.

Hash und Zeitstempel helfen beim kontrollierten Rückleiten von Fehlermeldungen: Ein NDR an eine gültige SRS-Adresse kann dekodiert und an Alice zurückgeleitet werden. SRS-Adressen sind zeitlich begrenzt und für diesen Zweck bestimmt. Sichere Geheimnisse allein verhindern jedoch kein offenes Relay; dazu gehören auch korrekte Relay-Zugriffskontrollen und die Validierung von Rückläuferempfängern.

ARC: Authenticated Received Chain

SRS kann SPF für die Weiterleitungsdomain bestehen lassen, schließt aber nicht die Ausrichtungslücke zur ursprünglichen From-Domain. Auch ARC (RFC 8617) schließt diese Lücke nicht. Stattdessen versieht der Weiterleiter die Nachricht mit einer kryptografisch gesicherten Dokumentation seiner Authentifizierungsbeobachtungen: "Dies habe ich beim Empfang geprüft."

Empfänger wie Google oder Microsoft können gültige ARC-Ketten vertrauenswürdiger Weiterleiter bei ihrer Zustellentscheidung berücksichtigen. Ob sie einem Siegel vertrauen und von der DMARC-Richtlinie abweichen, liegt bei ihnen. Gute IP-Reputation und eine gültige ARC-Kette garantieren weder Annahme noch Posteingangszustellung.

ARC ähnelt einem Nachweis der Verwahrungskette. Jeder teilnehmende Weiterleitungsschritt ergänzt signierte Angaben zum beobachteten Authentifizierungszustand. Nachfolgende Empfänger können die Kette prüfen und nach eigener Richtlinie berücksichtigen, auch wenn die aktuelle DMARC-Prüfung keinen ausgerichteten SPF- oder DKIM-Erfolg ergibt.

Gmail und Microsoft 365 unterstützen ARC in bestimmten Nachrichtenflüssen; prüfen Sie die konkreten Header und die aktuelle Dokumentation statt jedes Siegel vorauszusetzen. Ohne ARC fehlt diese zusätzliche Dokumentation. Daraus folgt aber kein zwangsläufiger DMARC-Fehler: Eine gültige, ursprünglich ausgerichtete DKIM-Signatur kann weiterhin genügen.

Umsetzung: Zwei Wege

Sie können Ihren eigenen MTA verwalten oder eine Plattform nutzen, die SRS und gegebenenfalls ARC für den betreffenden Weiterleitungsweg bereitstellt. Auch eine verwaltete Lösung erfordert richtige DNS-Einträge, passende Regeln und Zustelltests; kein Ansatz beseitigt sämtliche Zustellfehler.

Option A: Postfix + postsrsd in Eigenverwaltung

Auf einem Linux-Server mit Postfix lässt sich postsrsd für die Envelope-Umschreibung einsetzen. Das folgende ältere Beispiel gilt nur für Versionen mit TCP-Maps; auf eine Version mit Socketmap-Schnittstelle lässt es sich nicht unverändert übertragen. Prüfen Sie die installierte Version und deren dokumentierte Einstellungen. Das Beispiel wurde hier nicht ausgeführt:

# /etc/postfix/main.cf
sender_canonical_maps = tcp:localhost:10001
sender_canonical_classes = envelope_sender
recipient_canonical_maps = tcp:localhost:10002
recipient_canonical_classes = envelope_recipient

Dabei übernehmen Sie unter anderem:

• Verwaltung der SRS-Geheimnisse. Ein Verlust kann gefälschte SRS-Rückläufer ermöglichen; Relay-Zugriffskontrollen bleiben unabhängig davon notwendig.
• Passende Ausnahmen für lokale Domains. Eine zu breite Umschreibung kann interne Zustellung beeinträchtigen.
• Pflege der Reputation Ihrer ausgehenden IP; sie beeinflusst die Zustellung an Gmail und Outlook neben anderen Faktoren.
• Gesonderte ARC-Konfiguration, die postsrsd allein nicht bereitstellt.

Eine korrekt konfigurierte Lösung kann funktionieren, verlangt aber laufende Wartung. Spezialisierte Mailplattformen können einen Teil dieses Betriebsaufwands übernehmen.

Option B: TrekMail mit verwalteter Weiterleitung

Prüfen Sie für den konkret gewählten TrekMail-Tarif und Weiterleitungsweg die aktuelle Verfügbarkeit der automatischen SRS-Umschreibung, der ARC-Signierung und verwalteter SMTP-Relays. Solche Funktionen können serverseitige Konfigurations- und Schlüsselverwaltung reduzieren; die Aussage, dass ARC in bezahlten Tarifen enthalten sei oder jede Weiterleitung über ein bestimmtes Relay laufe, sollte vor dem Kauf bestätigt werden. Die Reputation eines Relays garantiert keine Zustellung.

Für Einzelgründer: Wenn Sie $6 pro Monat für jedes Postfach bezahlen, nur um info@yourdomain.com an Ihren privaten Posteingang weiterzuleiten, lohnt sich ein Vergleich mit domainbasierten Tarifen. Der hier genannte Starter-Tarif von TrekMail mit $3.50 pro Monat für bis zu 50 Domains ohne nutzerabhängige Gebühren ist vor Vertragsabschluss anhand der aktuellen Preise und Weiterleitungsgrenzen zu prüfen. Lesen Sie auch, wie Postfachweiterleitung in TrekMail funktioniert.

Für Agenturen mit vielen Kundendomains kann die Fehlersuche bei SPF teuer werden. Eine zentrale Weiterleitungsverwaltung kann den Betrieb vereinfachen, sofern die benötigten Funktionen verfügbar sind. Der Leitfaden zu E-Mail-Alias-Weiterleitungen erklärt die Unterschiede zwischen Aliasen und Postfachregeln.

Checkliste vor der Weiterleitung

Prüfen Sie alle vier Punkte, bevor Sie eine produktive Weiterleitungsregel aktivieren. Sie helfen, die oben beschriebenen Fehler einzugrenzen, ersetzen aber keine Tests mit den tatsächlichen Absendern und Zielsystemen.

1. SRS ist aktiv. Prüfen Sie den Return-Path einer zugestellten Testnachricht. Wenn SRS für diesen Weg vorgesehen ist, sollte er die Weiterleitungsdomain zeigen; prüfen Sie zusätzlich deren SPF-Autorisierung.
2. Signierten Inhalt möglichst erhalten. Vermeiden Sie Fußzeilen, Betreffzusätze und eingefügte Warnbanner, wenn sie DKIM beeinträchtigen. Deaktivieren Sie weder Antivirus noch andere Sicherheitsprüfungen; verwenden Sie gleichwertige Schutzmaßnahmen ohne Änderung des signierten Inhalts und prüfen Sie Kanonisierung und signierte Header.
3. Schleifenschutz. Prüfen Sie Rückweiterleitungen, Abwesenheitsantworten, Catch-all-Ziele und die Unterdrückung automatischer Antwortschleifen.
4. M365-Ausgangsrichtlinie. Prüfen Sie bei Exchange Online die wirksame Richtlinie. Erlauben Sie automatische externe Weiterleitung nur in einer genehmigten, auf die erforderlichen Konten begrenzten Richtlinie, nicht durch eine globale Freigabe.

Wann eine Weiterleitung nicht die passende Lösung ist

Wenn mehrere Domains in dasselbe lokal gehostete Postfach münden sollen, kann ein Domain-Alias zusätzliche externe Weiterleitung vermeiden. Ein Alias, der seinerseits extern weiterleitet, umgeht jedoch weder SPF noch DKIM oder DMARC; entscheidend ist der tatsächliche Zustellweg.

Der Vergleich von Domain-E-Mail-Alias und Postfach erklärt die Einsatzfälle. Für den Umzug historischer Nachrichten kann ein IMAP-Migrationstool geeigneter sein als eine Live-Weiterleitung. Prüfen Sie die aktuelle Verfügbarkeit des TrekMail-Tools; eine Kopie per IMAP ersetzt nicht die Umstellung des Routings für neu eingehende Nachrichten.

Zusammenfassung

Bei externer Weiterleitung sieht der Empfänger die IP Ihres Servers. Ist sie für die ursprüngliche Envelope-Domain nicht autorisiert, kann SPF fehlschlagen. Bleibt auch kein gültiger, ausgerichteter DKIM-Nachweis erhalten, scheitert DMARC. Die Empfängerrichtlinie bestimmt die Behandlung; stiller Verlust oder das Ausbleiben eines Rückläufers sind nicht garantiert.

Die Gegenmaßnahmen sind serverseitig: SRS schreibt den Envelope-Absender auf eine kontrollierte Domain um und kann bei korrektem SPF helfen. ARC dokumentiert frühere Authentifizierung für eine mögliche Vertrauensentscheidung, stellt aber keine DMARC-Ausrichtung her. Beide lassen sich selbst betreiben oder über eine geeignete Plattform nutzen.

Wenn Sie SRS-Schlüssel, ARC und Relay-Betrieb nicht selbst verwalten möchten, prüfen Sie die passenden Funktionen von TrekMail. Die hier genannte Starter-Kondition von $3.50 pro Monat für bis zu 50 Domains ohne nutzerabhängige Gebühren ist mit dem aktuellen Tarif und dessen Weiterleitungsgrenzen abzugleichen. Alle Tarife ansehen.