DMARC-Fehler bei Weiterleitung: Ursachen und Lösungen

DMARC-Fehler werden oft erst gemeldet, wenn die Einrichtung bereits abgeschlossen scheint. SPF ist veröffentlicht. DKIM ist aktiv. Die DMARC-Richtlinie steht endlich auf p=quarantine oder p=reject. Dann wird eine echte Nachricht weitergeleitet und kommt nicht an. Das muss weder eine Fälschung noch Spam sein: Die Nachricht kann einen Übertragungsweg genommen haben, den die Konfiguration nicht ausreichend berücksichtigt.

Das ist ein typisches Problem bei DMARC-Fehlern während der Weiterleitung. Die Nachricht ist legitim, doch der zusätzliche Hop verändert Zustellkontext oder Inhalt so, dass die Authentifizierung beim Empfänger nicht mehr genügt. Wer SPF und DKIM nur als abgehakte Einstellungen kennt, empfindet das als Zufall. Häufig gibt es jedoch ein nachvollziehbares Muster, anhand dessen sich die Ursache eingrenzen lässt.

Für die grundlegende Einrichtung beginnen Sie mit geschäftlicher E-Mail. Nutzen Sie bereits Weiterleitung, passt dazu der Leitfaden zur E-Mail-Weiterleitung.

Was ein DMARC-Fehler tatsächlich bedeutet

Ein DMARC-Fehler bedeutet, dass weder ein erfolgreicher, ausgerichteter SPF-Test noch eine gültige, ausgerichtete DKIM-Signatur zur sichtbaren From-Domain vorliegt. Eine erfolgreiche Authentifizierung allein reicht nicht. DMARC betrachtet auch das Verhältnis zwischen authentifizierter Domain und sichtbarer Absenderdomain.

DMARC baut auf SPF und DKIM auf. Nach dem in der historischen Spezifikation RFC 7489 beschriebenen Grundprinzip besteht eine Nachricht DMARC, wenn mindestens eine dieser Bedingungen erfüllt ist:

1. SPF ist erfolgreich und zur Domain im Header From ausgerichtet.
2. DKIM ist erfolgreich und zur Domain im Header From ausgerichtet.

Das klingt einfach. In der Praxis entstehen DMARC-Fehler oft, weil drei unterschiedliche Fragen verwechselt werden:

• Authentifizierung: War SPF oder DKIM erfolgreich?
• Alignment: Passt die erfolgreich authentifizierte Domain zur Header-From-Domain?
• Beständigkeit bei Weiterleitung: Blieben die für die Signatur relevanten Nachrichtenteile unverändert?

SPF kann erfolgreich sein und dennoch liegt ein DMARC-Fehler vor. Auch erfolgreiches DKIM kann mit einem DMARC-Fehler einhergehen. Gehört die erfolgreiche Identität zu einer nicht ausgerichteten Domain, genügt sie DMARC nicht.

Warum Weiterleitung häufig DMARC-Fehler verursacht

Weiterleitung kann DMARC-Fehler verursachen, weil sie den Übertragungsweg und manchmal den Inhalt verändert. SPF hängt vom Weg ab, DKIM von den signierten Nachrichtendaten. Weitergeleitete Nachrichten können eine Methode verlieren; ungünstige Änderungen können beide betreffen.

Ein häufiger Ablauf:

1. Ein Absender sendet eine Nachricht von sender.com.
2. Ein zwischengeschaltetes Postfach oder Gateway empfängt sie.
3. Dieses System leitet die Nachricht automatisch an Gmail, Outlook oder ein anderes Ziel weiter.

Der endgültige Empfänger sieht nun nicht mehr die ursprüngliche Absender-IP als SMTP-Client, sondern die IP des Weiterleiters.

Hier kann die Ursache eines DMARC-Fehlers liegen.

SPF kann zuerst scheitern

SPF ist in RFC 7208 definiert. Es prüft, ob die verbindende IP für die Envelope-Domain senden darf.

Nach der Weiterleitung verbindet sich der Weiterleiter statt des ursprünglichen Servers. SPF kann deshalb scheitern. SRS kann durch Umschreiben des Envelope-Absenders einen SPF-Erfolg für die neue Domain ermöglichen, stellt aber nicht automatisch DMARC-Alignment mit der ursprünglichen From-Domain her.

Ursprünglicher Weg: sender.com sendet von IP A. SPF ist erfolgreich.
Weitergeleiteter Weg: Ein Vermittler sendet von IP B weiter. Der Empfänger prüft sender.com gegen IP B. SPF scheitert, wenn diese IP nicht autorisiert ist.

Dieser SPF-Fehler allein garantiert keinen DMARC-Fehler. Bleibt ausgerichtetes DKIM gültig, besteht die Nachricht weiterhin DMARC. Deshalb ist verlässlich eingerichtetes DKIM wichtig.

DKIM kann die Authentifizierung erhalten

DKIM nach RFC 6376 signiert ausgewählte Header und den Nachrichtenkörper. Die weiterleitende IP spielt für die Signaturprüfung keine Rolle. DKIM kann daher den DMARC-Erfolg erhalten, wenn SPF scheitert.

Dafür müssen zwei Bedingungen erfüllt sein:

1. Die Signatur bleibt nach der Weiterleitung gültig.
2. Die Domain in d= ist zur sichtbaren From-Domain ausgerichtet.

Fehlt eine Bedingung und gibt es keinen anderen ausgerichteten Erfolg, entsteht ein DMARC-Fehler.

Weiterleiter können Nachrichten auf scheinbar kleine, aber relevante Weise verändern:

• [EXTERNAL] zum Betreff hinzufügen
• Haftungsausschlüsse oder rechtliche Fußzeilen anhängen
• MIME-Grenzen umschreiben
• Zeilenumbrüche oder Leerraum verändern

Manche Änderungen werden durch relaxed-Kanonisierung toleriert, andere nicht. Gateways können Signaturen beschädigen. Ein DMARC-Fehler bei Weiterleitung kann daher eine Implementierungsfrage sein, ist aber für sich genommen weder ein Beweis für Spoofing noch für dessen Abwesenheit.

Die Alignment-Falle ohne Weiterleitung

Ein DMARC-Fehler braucht keine Weiterleitung. Auch ein SaaS-Dienst kann mit seiner eigenen, nicht ausgerichteten Domain authentifizieren. Die Nachricht ist legitim, aber DMARC kann trotzdem scheitern.

Diese Unterscheidung wird im Betrieb häufig übersehen.

Beispiel:

• From: billing@yourcompany.com
• Return-Path: bounce.vendor-mail.com
• DKIM: d=vendor-mail.com

SPF kann für vendor-mail.com erfolgreich sein. DKIM kann für vendor-mail.com erfolgreich sein. Trotzdem meldet DMARC einen Fehler, wenn keine weitere erfolgreiche Identität zu yourcompany.com ausgerichtet ist.

Abhilfe schafft passend eingerichtete Domainauthentifizierung. Ausgerichtetes DKIM ist für Weiterleitung besonders hilfreich; bei direkter Zustellung kann auch ausgerichtetes SPF genügen.

Wenn Sie stark aliasbasierte Strukturen überarbeiten, lesen Sie Domain-Alias oder Postfach. Dabei können verborgene Weiterleitungswege und Zuständigkeiten sichtbar werden.

DMARC-Fehler anhand der Header untersuchen

Viele DMARC-Fehler lassen sich durch Headeranalyse schneller eingrenzen als durch Vermutungen. Beginnen Sie mit Authentication-Results, sofern dieser Header vom vertrauenswürdigen empfangenden System hinzugefügt wurde, und vergleichen Sie SPF, DKIM und die Alignment-Domains.

Bitten Sie den Empfänger um vollständige Header. Ein Beispiel:

Authentication-Results: mx.google.com;
       spf=fail smtp.mailfrom=sender.com;
       dkim=pass header.i=@sender.com header.s=mail;
       dmarc=pass header.from=sender.com

Das passt zu einer Weiterleitung, bei der SPF scheiterte und DKIM gültig blieb. DMARC ist erfolgreich; mögliche andere Zustellprobleme müssen dennoch separat bewertet werden.

Dieser Fall verlangt weitere Untersuchung:

Authentication-Results: mx.google.com;
       spf=fail smtp.mailfrom=sender.com;
       dkim=fail header.i=@sender.com;
       dmarc=fail header.from=sender.com

Das kann ein typischer DMARC-Fehler nach Weiterleitung sein: SPF scheitert am geänderten Weg, DKIM an Änderungen oder einer zuvor ungültigen Signatur. Die Header allein belegen jedoch nicht jede Ursache.

DMARC-Fehler bei Weiterleitung reduzieren

Sie können nicht verhindern, dass Empfänger Nachrichten weiterleiten. DMARC-Fehler lassen sich eher reduzieren, wenn die Konstruktion Weiterleitung berücksichtigt: ausgerichtetes DKIM, übersichtliches SPF und ein Weg, der signierte Nachrichtenteile möglichst unverändert lässt.

1. DKIM für alle Versandströme vorsehen

Soll legitime Post eine Weiterleitung möglichst gut überstehen, ist ausgerichtetes DKIM wichtig. Signieren Sie alle kontrollierten Versandströme, nicht nur Newsletter oder Supportpost.

Die Signatur muss zur sichtbaren From-Domain ausgerichtet sein. Bei yourdomain.com kann die Signierdomain yourdomain.com oder im relaxed-Alignment-Modus eine entsprechend ausgerichtete Subdomain sein. Striktes Alignment verlangt genaue Übereinstimmung.

Bei TrekMail beginnt die DNS-Einrichtung mit den erforderlichen DNS-Einträgen. Ein gelber oder roter Status sollte untersucht werden; auch ein grüner Status garantiert keinen Erfolg jedes Weiterleitungsfalls.

2. Relaxed-Kanonisierung für DKIM prüfen

Simple-Kanonisierung kann auf kleine Formatänderungen empfindlich reagieren und damit zu DMARC-Fehlern beitragen. Relaxed-Kanonisierung toleriert bestimmte Änderungen an Leerraum und Headerformatierung.

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=mail;
 c=relaxed/relaxed; h=from:to:subject:date:message-id; ...

Ein angehängter Nachrichtenfooter wird dadurch normalerweise nicht unschädlich. Die Toleranz betrifft nur die im Standard festgelegte Normalisierung.

3. Domainauthentifizierung der Anbieter überprüfen

Signiert CRM, Helpdesk oder Newsletterdienst mit d=vendor.com, prüfen Sie das Alignment und weitere Signaturen, statt die Domain allein als Fehler zu werten. Fehlt ausgerichtetes DKIM, kann Weiterleitung den noch vorhandenen SPF-Pfad verlieren und einen DMARC-Fehler auslösen. Richten Sie passende eigene DKIM- und gegebenenfalls Return-Path-Domains ein; beide Methoden müssen nicht gleichzeitig erfolgreich sein, damit DMARC besteht.

4. SPF übersichtlich und auswertbar halten

SPF scheitert nicht nur bei Weiterleitung. Eine überladene Konfiguration kann ebenfalls Fehler erzeugen. RFC 7208 begrenzt die berücksichtigten DNS-Abfragen auslösenden Mechanismen und Modifikatoren während der SPF-Auswertung auf 10, einschließlich relevanter verschachtelter Terme. Das Überschreiten, nicht das bloße Erreichen, kann permerror verursachen und SPF als erfolgreichen DMARC-Pfad ausschließen.

dig +short TXT example.com

dig +short TXT _dmarc.example.com

Wenn Google, Microsoft, Mailgun, SendGrid, Zendesk und drei alte Hoster in derselben SPF-Konfiguration stehen, prüfen Sie, welche Quellen noch benötigt werden. Separate Subdomains können sinnvoll sein, müssen aber zu den tatsächlichen Envelope-Domains passen.

5. Möglichkeiten und Grenzen von SRS und ARC verstehen

SRS schreibt bei Weiterleitung den Envelope-Absender um und kann SPF für die neue Identität ermöglichen, ohne das ursprüngliche DMARC-Alignment automatisch wiederherzustellen. ARC übermittelt vorherige Authentifizierungsergebnisse in einer überprüfbaren Kette. Der Empfänger entscheidet, ob er dem Vermittler vertraut und daraus eine Richtlinienausnahme ableitet. Beides ersetzt keine verlässliche DKIM-Konfiguration.

Googles Hinweise für indirekte Mail unterscheiden Weiterleitung von direkter Zustellung und empfehlen Weiterleitungsdiensten ARC-Header. Daraus folgt keine allgemeine Aufhebung von DMARC-Alignment. Für 2025 und 2026 sollten Sie jeweils die aktuellen Anbieterregeln und tatsächlichen Ergebnisse prüfen.

Bei vielen weitergeleiteten Postfächern ist die Plattformgestaltung relevant. TrekMail bietet nach aktueller Dokumentation Postfachweiterleitung und DNS-Anleitungen. Die Dokumentation zu Bring Your Own SMTP hilft, externe Versandwege und ihre Alignment-Anforderungen zu prüfen.

Traditioneller und strukturierter Ansatz für viele Domains

Beim traditionellen Umgang mit DMARC-Fehlern werden manchmal immer weitere Werkzeuge ergänzt, bis unklar ist, welches System signiert. Ein strukturierter Ansatz trennt Postfachhosting, Versand und DNS-Zustand nachvollziehbar, damit Fehler untersucht werden können.

TrekMail kann nach aktuellen Tarifbedingungen Postfächer mehrerer Domains bündeln, gemeinsamen Speicher bereitstellen und Versand über verwaltetes SMTP oder einen eigenen Anbieter ermöglichen. Kosten und Eignung hängen von der Nutzung ab. Vergleichen Sie Multi-Domain-E-Mail-Hosting und den Migrationsleitfaden zu imapsync.

Vorgehen bei einer DMARC-Fehlermeldung

Bei einem DMARC-Fehler sollten Sie nicht reflexartig von reject auf none wechseln. Klären Sie zunächst, ob Weiterleitung, ungültiges DKIM oder fehlendes Alignment die Ursache ist. Richtlinienänderungen benötigen Senderinventar, Tests, Überwachung und einen abgestimmten Rückfallplan.

1. Vollständige Header vom Empfänger beschaffen.
2. Prüfen, ob die SPF-fehlgeschlagene Verbindung von einem bekannten Weiterleiter stammt.
3. DKIM-Ergebnisse und die signierende d=-Domain prüfen.
4. Alignment der Signierdomain mit der sichtbaren From-Domain prüfen.
5. Bei einem vertrauenswürdigen Vermittler nach arc=pass suchen und die Bedeutung für diesen Empfänger bewerten.
6. SPF auf Abfragelimit, veraltete Includes und Syntaxfehler untersuchen.

Für TrekMail bieten Domain hinzufügen einen Einstieg zur DNS-Prüfung und Ich empfange keine E-Mails Hinweise, wenn eine Nachricht ohne sichtbaren Bounce fehlt.

Fazit: DMARC-Fehler lassen sich systematisch untersuchen

Wiederkehrende DMARC-Fehler bedeuten nicht, dass E-Mail grundsätzlich unbrauchbar ist. Mögliche Ursachen sind zu große Abhängigkeit von SPF, nicht ausgerichtetes oder empfindliches DKIM und Änderungen durch Weiterleiter. Auch unerlaubte Quellen müssen berücksichtigt werden.

Die Maßnahmen sind meist unspektakulär: ausgerichtet signieren, gültiges DKIM erhalten, SPF pflegen und Weiterleitung testen. Prüfen Sie echte Versandströme und verfügbare Berichte, deren Abdeckung begrenzt sein kann.

TrekMail bietet je nach aktuellem Tarif Multi-Domain-Postfachhosting, gemeinsamen Speicher, IMAP-Migration, Catch-all und flexible Versandoptionen. Nach den hier genannten Bedingungen beginnen bezahlte Pläne bei $3.50 pro Monat mit jährlicher Abrechnung; für bezahlte Pläne kann eine 14-tägige kostenlose Testphase verfügbar sein. Nano kann kostenlos und ohne Karte angeboten werden. IMAP kopiert Mailboxdaten, nicht DNS oder Reputation. Prüfen Sie Preise oder TrekMail auf aktuelle Bedingungen.

Kurz gesagt: Gibt es Weiterleitung in Ihrer Umgebung, sind DMARC-Fehler ein wichtiger Testfall. Erfolgreiche Tests helfen, die Konfiguration belastbarer zu machen, garantieren aber weder DMARC-Erfolg auf jedem Weg noch Zustellung bei jedem Empfänger.