E-Mail-Weiterleitung ist eine der häufigsten legitimen Aktivitäten, die DMARC-Authentifizierungsfehler verursacht. Wenn ein Postfach automatisch eine eingehende Nachricht an ein anderes Ziel weiterleitet – beispielsweise eine persönliche Gmail-Adresse, die an ein Arbeitskonto weiterleitet, oder ein Büroadministrator, der Nachrichten an Abteilungsmitglieder weiterleitet – kann die weitergeleitete Nachricht DMARC-Prüfungen nicht bestehen, selbst wenn der ursprüngliche Absender alles korrekt konfiguriert hat.

Dieser Authentifizierungsausfall tritt auf, weil DMARC erwartet, dass die sendende Infrastruktur, die Nachrichten-Header und die Domain-Ausrichtung während der Zustellung unverändert bleiben. Weiterleitung bricht diese Annahme. Das Ergebnis: Legitime Nachrichten von authentifizierten Domains können abgelehnt, unter Quarantäne gestellt oder markiert werden, wenn ein Weiterleitungsserver sie an den Endempfänger weiterleitet.

Das Verständnis, warum Weiterleitung DMARC bricht, was während des Weiterleitungsprozesses fehlschlägt und wie weiterleitungssichere Richtlinien implementiert werden, hilft Organisationen, Anti-Spoofing-Schutzmaßnahmen durchzusetzen, ohne legitime geschäftliche Kommunikation zu blockieren.

I. Warum E-Mail-Weiterleitung DMARC-Fehler verursacht

DMARC-Ausrichtung erfordert, dass entweder SPF oder DKIM die Authentifizierung besteht und mit der Domain im From:-Header übereinstimmt. Wenn eine Weiterleitung erfolgt, können beide Ausrichtungsmechanismen fehlschlagen.

SPF schlägt während der Weiterleitung fehl

SPF authentifiziert den sendenden Server gegen die Domain, die in der Envelope-Adresse MAIL FROM aufgeführt ist. Wenn eine Nachricht weitergeleitet wird, wird der Weiterleitungsserver zum neuen sendenden Server. Der ursprüngliche SPF-Eintrag autorisiert die IP-Adresse des Weiterleitungsservers nicht, sodass die SPF-Authentifizierung am endgültigen Ziel fehlschlägt.

Beispielablauf:

1. [email protected] sendet eine E-Mail an [email protected]
2. [email protected] leitet die Nachricht an [email protected] weiter
3. Der Weiterleitungsserver (office.net) liefert die Nachricht an personal.com
4. personal.com überprüft SPF für company.com gegen die IP des Weiterleitungsservers
5. Der Weiterleitungsserver ist nicht im SPF-Eintrag von company.com
6. SPF schlägt fehl

Die Envelope-Adresse MAIL FROM verweist weiterhin auf company.com, aber die sendende IP gehört jetzt zu office.net. Die SPF-Abfrage gibt fail oder softfail zurück.

DKIM kann fehlschlagen, wenn Inhalte geändert werden

DKIM signiert die Nachrichten-Header und den Body mithilfe einer kryptografischen Signatur. Wenn der Weiterleitungsserver die Nachricht modifiziert – beispielsweise durch Hinzufügen einer Fußzeile, Ändern der Betreffzeile oder Ändern der MIME-Struktur – schlägt die Überprüfung der DKIM-Signatur fehl.

Häufige Weiterleitungsänderungen, die DKIM brechen:

• Anhängen einer Weiterleitungsbenachrichtigung oder eines Haftungsausschlusses an den Nachrichtentext
• Hinzufügen von [Fwd:] oder [External] zur Betreffzeile
• Konvertieren von HTML in Klartext oder Ändern von MIME-Grenzen
• Entfernen von Anhängen oder Ändern der Codierung

Selbst kleine Änderungen machen die Signatur ungültig. Wenn DKIM fehlschlägt, verliert die weitergeleitete Nachricht ihren Authentifizierungsnachweis.

DMARC-Ausrichtung schlägt fehl, selbst wenn DKIM besteht

Selbst wenn der Weiterleitungsserver die Nachricht nicht modifiziert und die DKIM-Überprüfung erfolgreich ist, kann DMARC aufgrund der Ausrichtungsanforderungen dennoch fehlschlagen.

DMARC erfordert, dass die Domain im From:-Header mit der Domain im SPF-Envelope-Absender (lockere oder strikte Ausrichtung) oder der Domain in der DKIM-Signatur (lockere oder strikte Ausrichtung) übereinstimmt. Wenn SPF fehlschlägt und DKIM besteht, aber eine andere Domain verwendet (z. B. der Weiterleitungsserver mit seiner eigenen Domain signiert), schlägt die DMARC-Ausrichtung fehl.

Dies tritt häufig auf, wenn:

• Die ursprüngliche DKIM-Signatur gültig bleibt, aber die From:-Domain von der DKIM-Signatur-Domain abweicht
• Der Weiterleitungsserver seine eigene DKIM-Signatur hinzufügt, die nicht mit der ursprünglichen From:-Domain übereinstimmt
• SPF fehlschlägt und keine ausgerichtete DKIM-Signatur existiert

II. Was fehlschlägt, wann und wie sichtbar

Weiterleitungsfehler sind für den ursprünglichen Absender und den weiterleitenden Benutzer oft unsichtbar. Die Nachricht kann ohne klare Rückmeldung abgelehnt oder unter Quarantäne gestellt werden.

Fehlerbedingungen

Wenn Fehler unsichtbar sind

• Der weiterleitende Benutzer erhält keine Bounce- oder Fehlerbenachrichtigung
• Der ursprüngliche Absender sieht keinen Zustellungsfehler, da die Nachricht das Weiterleitungspostfach erfolgreich erreicht hat
• Das endgültige Ziel lehnt die Nachricht ab, ohne den weiterleitenden Benutzer zu benachrichtigen
• DMARC-Aggregat-Berichte zeigen Authentifizierungsfehler, aber der ursprüngliche Absender korreliert den Fehler möglicherweise nicht mit der Weiterleitung

Wenn Fehler sichtbar sind

• Der weiterleitende Benutzer bemerkt, dass Nachrichten von bestimmten Absendern am endgültigen Ziel nicht mehr ankommen
• Der endgültige Postfachanbieter sendet eine Ablehnungsbenachrichtigung an das Weiterleitungspostfach
• Der ursprüngliche Absender erhält einen Bounce, wenn das endgültige Ziel eine Fehlerbenachrichtigung generiert (selten)

III. Wie Organisationen entdecken, dass Weiterleitung DMARC bricht

Die meisten Organisationen entdecken Weiterleitungsprobleme nach dem Wechsel von p=none zu p=quarantine oder p=reject. Nachrichten, die zuvor ohne Probleme zugestellt wurden, erreichen plötzlich keine weitergeleiteten Ziele mehr.

Häufige Entdeckungspfade:

• Mitarbeiter berichten, dass weitergeleitete Nachrichten von Kunden, Lieferanten oder Partnern nicht mehr ankommen
• Vertriebsteams stellen fest, dass automatische Weiterleitungen an CRM-Systeme fehlschlagen
• Helpdesk-Weiterleitungen von Ticketsystemen an persönliche E-Mails funktionieren nicht mehr
• Führungskräfte, die E-Mail-Weiterleitungen von Unternehmenskonten zu persönlichen Geräten verwenden, verlieren Nachrichten

DMARC-Aggregat-Berichte zeigen Authentifizierungsfehler von IP-Adressen von Weiterleitungsservern, aber die Berichte identifizieren die Weiterleitung nicht explizit als Ursache. Die Analyse der Berichte erfordert die Korrelation von Fehlerquellen mit bekannten Weiterleitungskonfigurationen.

IV. So implementieren Sie weiterleitungssichere DMARC-Richtlinien

Organisationen können nicht kontrollieren, wie Drittanbieter-Weiterleitungsserver Nachrichten verarbeiten. Sie können jedoch DMARC-Richtlinien anpassen, Fehlermuster überwachen und Benutzer über Weiterleitungsalternativen aufklären.

Stufen der Durchsetzung nach Mail-Stream, nicht nach Prozentsatz

Anstatt pct= zu verwenden, um DMARC schrittweise durchzusetzen, sollten Sie die Durchsetzung nach Domain, Subdomain, Absendergruppe und Mail-Stream-Reife staffeln. Wenden Sie p=reject auf hochwertige Domains an, die für Finanztransaktionen, Kontobenachrichtigungen und Führungskommunikation verwendet werden. Wenden Sie p=quarantine oder p=none auf Domains mit bekannten Weiterleitungsmustern an, bis alternative Lösungen implementiert sind.

Verlassen Sie sich nicht auf den prozentualen Rollout als Hauptstrategie. Aktuelle DMARC-fähige Programme sollten die Durchsetzung nach Domain, Subdomain, Absendergruppe und Geschäftsfunktion staffeln.

Verwenden Sie Subdomains für weiterleitungsintensive Mail-Streams

Wenn ein bestimmter Mail-Stream häufig weitergeleitet wird – wie Newsletter, automatisierte Berichte oder interne Benachrichtigungen – senden Sie von einer Subdomain mit einer weniger restriktiven DMARC-Richtlinie. Dies isoliert Weiterleitungsfehler von hochwertiger Transaktions-E-Mail.

Beispiel:

• company.com → p=reject (Transaktions-, Kontosicherheit)
• reports.company.com → p=none (automatisierte Berichte, Newsletter)

Dieser Ansatz bewahrt den Anti-Spoofing-Schutz auf der primären Domain, während weitergeleitete Mail-Streams durchgelassen werden.

Informieren Sie Benutzer über Weiterleitungsalternativen

Weiterleitung wird oft aus Bequemlichkeit verwendet, aber Alternativen reduzieren DMARC-Ausrichtungsfehler:

• Verwenden Sie nativen IMAP- oder POP-Zugriff anstelle der Weiterleitung. Die meisten E-Mail-Clients unterstützen die Verwaltung mehrerer Konten.
• Verwenden Sie E-Mail-Delegation (wie Gmails „Zugriff auf Ihr Konto gewähren“ oder Microsoft 365s „Senden im Auftrag von“), um mehrere Postfächer ohne Weiterleitung zu verwalten.
• Verwenden Sie E-Mail-Aliase innerhalb derselben Domain anstelle der Weiterleitung an externe Adressen.
• Verwenden Sie Verteilerlisten oder freigegebene Postfächer für teambasiertes Mail-Routing anstelle einzelner Weiterleitungsregeln.

Überwachen Sie Aggregat-Berichte auf Weiterleitungsmuster

DMARC-Aggregat-Berichte enthalten die Quell-IP-Adresse, Authentifizierungsergebnisse und Nachrichtenzählung. Weiterleitungsfehler zeigen typischerweise:

• SPF-Fehler von IP-Adressen, die zu bekannten Weiterleitungsanbietern gehören (Google Workspace, Microsoft 365, E-Mail-Hosting-Anbieter)
• DKIM bestanden oder fehlgeschlagen, abhängig davon, ob die Nachricht modifiziert wurde
• Ausrichtungsfehler, wenn DKIM besteht, aber nicht ausgerichtet ist

Die Überprüfung dieser Muster hilft zu identifizieren, welche Weiterleitungsziele Fehler verursachen und ob das Volumen Richtlinienanpassungen rechtfertigt.

In einer verwalteten Skysnag-Bereitstellung verwenden Sie das von Skysnag generierte Berichtsziel. Das Folgende ist nur ein manuelles Beispiel:

v=DMARC1; p=quarantine; rua=mailto:[email protected]; pct=100; fo=1

Ein traditioneller statischer Eintrag kann funktionieren, aber nur wenn Berichte aktiv empfangen, analysiert, ausgewertet und darauf reagiert wird. Skysnag Protect aggregiert und analysiert DMARC-Berichte automatisch, um Weiterleitungsmuster aufzudecken und betroffene Absender zu identifizieren.

Erwägen Sie ARC (Authenticated Received Chain)-Unterstützung

ARC ist ein Protokoll, das entwickelt wurde, um Authentifizierungsergebnisse über zwischengeschaltete Server, einschließlich Weiterleitungssysteme, zu bewahren. Wenn eine Nachricht durch einen Weiterleitungsserver geht, der ARC unterstützt, fügt der Server einen ARC-Header-Satz hinzu, der die ursprünglichen Authentifizierungsergebnisse aufzeichnet. Das endgültige Ziel kann die ARC-Kette auswerten, um festzustellen, ob die Nachricht vor der Weiterleitung authentifiziert wurde.

ARC löst Weiterleitungsfehler nicht von selbst. Der endgültige empfangende Server muss ARC-Header respektieren, und der Weiterleitungsserver muss ARC korrekt implementieren. Ab 2026 wächst die ARC-Unterstützung bei großen Postfachanbietern, ist aber nicht universell implementiert.

Organisationen können nicht kontrollieren, ob Weiterleitungsserver oder endgültige Ziele ARC unterstützen. Die Überwachung von ARC-bezogenen Headern in DMARC-Forensik-Berichten kann jedoch helfen zu identifizieren, ob Weiterleitungssysteme versuchen, die Authentifizierung zu bewahren.

V. Was nach Richtlinienanpassung schiefgehen kann

Die Anpassung von DMARC-Richtlinien zur Berücksichtigung von Weiterleitungen führt neue Risiken ein.

Abschwächung der Richtlinie auf der primären Domain

Das Senken der DMARC-Durchsetzung auf der primären Domain zur Verhinderung von Weiterleitungsfehlern reduziert den Anti-Spoofing-Schutz. Angreifer können die geschwächte Richtlinie ausnutzen, um unauthentifizierte E-Mails von der Domain zu senden.

Beispielfehler:

• company.com ändert sich von p=reject zu p=quarantine, um weitergeleitete Nachrichten zuzulassen
• Ein Angreifer fälscht [email protected], um Phishing-E-Mails zu senden
• Die gefälschte Nachricht schlägt bei DMARC fehl, wird aber unter Quarantäne gestellt statt abgelehnt
• Einige Empfänger rufen die Nachricht aus der Quarantäne ab und werden Opfer des Phishing-Angriffs

Fehlausrichtung der Subdomain-Richtlinie

Die Verwendung von Subdomains für weiterleitungsintensive Mail-Streams funktioniert nur, wenn die Subdomain-DMARC-Richtlinie explizit festgelegt ist. Wenn die Subdomain die p=reject-Richtlinie der übergeordneten Domain über das sp=-Tag erbt, bleiben Weiterleitungsfehler bestehen.

Beispielfehler:

• company.com → p=reject; sp=reject
• reports.company.com wird für weitergeleitete E-Mails erstellt
• reports.company.com erbt p=reject von der übergeordneten Domain
• Weitergeleitete Nachrichten schlagen weiterhin bei DMARC fehl und werden abgelehnt

Veröffentlichen Sie immer einen separaten DMARC-Eintrag für Subdomains mit unterschiedlichen Durchsetzungsanforderungen.

Lücken in der Benutzerschulung

Die Empfehlung von Weiterleitungsalternativen garantiert nicht die Benutzerakzeptanz. Mitarbeiter können Weiterleitungsregeln weiterhin verwenden, wenn Alternativen nicht klar kommuniziert, dokumentiert oder von der IT unterstützt werden.

Beispielfehler:

• Die IT kündigt an, dass E-Mail-Weiterleitung DMARC-Fehler verursacht und empfiehlt IMAP-Zugriff
• Mitarbeiter verstehen nicht, wie IMAP konfiguriert wird, oder es fehlen Richtlinien für die Verwaltung mobiler Geräte
• Mitarbeiter leiten E-Mails weiter und berichten, dass Nachrichten von Lieferanten und Kunden fehlen
• Die IT behebt einzelne Fälle manuell, ohne das zugrunde liegende Verhalten anzugehen

Weiterleitungsalternativen erfordern Benutzerschulungen, klare Dokumentation und IT-Support, um erfolgreich zu sein.

VI. Wie Skysnag Protect hilft, Weiterleitungsfehler zu identifizieren und zu beheben

Skysnag Protect aggregiert DMARC-Berichte, identifiziert weiterleitungsbezogene Authentifizierungsfehler und deckt Muster auf, die darauf hinweisen, dass legitime Mail-Streams von Weiterleitung betroffen sind.

Skysnag Protect:

• Identifiziert Quell-IP-Adressen, die zu bekannten Weiterleitungsdiensten gehören, und hebt DMARC-Fehler hervor, die von diesen Adressen stammen
• Zeigt an, ob SPF, DKIM oder beide während der Weiterleitung fehlgeschlagen sind
• Verfolgt das Nachrichtenvolumen von Weiterleitungsquellen, um Richtlinienanpassungen zu priorisieren
• Bietet Einblick, welche Absender und Mail-Streams am stärksten von Weiterleitung betroffen sind
• Generiert Berichte, die IT-Teams helfen, Benutzer über Weiterleitungsalternativen aufzuklären und die Akzeptanz zu überwachen

Verwenden Sie Skysnag Protect, um legitime Absender zu identifizieren, nicht autorisierte Quellen zu erkennen und zur Durchsetzung überzugehen, ohne geschäftskritische weitergeleitete Nachrichten zu blockieren. Beginnen Sie mit DMARC-Überwachung unter.

VII. Wichtigste Erkenntnisse

• E-Mail-Weiterleitung bricht DMARC, weil SPF fehlschlägt, wenn der Weiterleitungsserver nicht durch den SPF-Eintrag des ursprünglichen Absenders autorisiert ist.
• DKIM kann fehlschlagen, wenn der Weiterleitungsserver den Nachrichtentext, die Betreffzeile oder die MIME-Struktur modifiziert.
• Selbst wenn DKIM besteht, kann die DMARC-Ausrichtung fehlschlagen, wenn die From:-Domain nicht mit der SPF- oder DKIM-Signatur-Domain übereinstimmt.
• Weiterleitungsfehler sind für den ursprünglichen Absender und den weiterleitenden Benutzer oft unsichtbar. Das endgültige Ziel lehnt die Nachricht ab oder stellt sie unter Quarantäne, ohne klare Rückmeldung.
• Organisationen sollten die DMARC-Durchsetzung nach Domain und Mail-Stream staffeln, nicht nach Prozentsatz. Verwenden Sie Subdomains für weiterleitungsintensive Mail-Streams.
• Informieren Sie Benutzer über Weiterleitungsalternativen: IMAP-Zugriff, E-Mail-Delegation, Aliase und freigegebene Postfächer.
• Überwachen Sie DMARC-Aggregat-Berichte, um Weiterleitungsmuster zu identifizieren und die Auswirkungen zu quantifizieren.
• Skysnag Protect deckt weiterleitungsbezogene Fehler auf, verfolgt betroffene Mail-Streams und hilft, Richtlinienanpassungen zu priorisieren, ohne den Anti-Spoofing-Schutz zu schwächen.