DMARC Fail: Ausrichtung, Header und SPF gezielt prüfen

DMARC fail bedeutet, dass eine Nachricht keinen erfolgreichen zur sichtbaren From-Domain ausgerichteten Authentifizierungspfad geliefert hat. Bei p=reject wird Ablehnung angefordert, bei p=quarantine verdächtige Behandlung. Die tatsächliche Entscheidung liegt beim Empfänger. Prüfen Sie die Konfiguration, ohne andere Zustellursachen auszuschließen. Den Gesamtaufbau erläutert geschäftliche E-Mail für kleine Unternehmen.

Wiederkehrende Ursachen sind fehlende Ausrichtung, SPF-Probleme bei Weiterleitung, unvollständige DKIM-Signierung und SPF-Auswertungsfehler. Statt weitere DNS-Werte auf Verdacht hinzuzufügen, prüfen Sie vertrauenswürdige Empfangsheader, vergleichen Domains und korrigieren den betroffenen Versandweg.

Dieser Leitfaden bietet eine Übersicht zur Einordnung, einen Prüfablauf und Beispiele für mögliche DNS-Anpassungen. Eine dauerhafte Lösung erfordert auch Tests nach späteren Änderungen.

Was bedeutet DMARC fail?

Die Nachricht hat kein Ergebnis geliefert, das zugleich erfolgreich und zur sichtbaren From-Domain ausgerichtet ist. SPF oder DKIM kann für eine andere Domain bestanden haben, ohne einen DMARC-Erfolg zu ermöglichen.

Laut Spezifikation muss SPF oder DKIM erfolgreich sein und zur Domain im RFC5322 From ausgerichtet sein. Mindestens ein solcher Pfad genügt. Siehe RFC 7489.

Schritt 1: Zuerst die Ausrichtung prüfen

Bei legitimer Mail hat der Anbieter häufig seine eigene Domain authentifiziert statt einen zur From-Domain ausgerichteten Pfad. Entscheidend ist nicht nur der Erfolg, sondern die verwendete Domain.

Ein Beispiel:

Header From: support@yourdomain.com
Return-Path: bounces.vendor.net
DKIM: d=vendor.net

spf=pass und dkim=pass können hier vorliegen, ohne DMARC-Erfolg: vendor.net ist nicht zu yourdomain.com ausgerichtet.

Prüfen Sie bei Marketing, CRM, Support und alternativen SMTP-Diensten die Domainauthentifizierung, einen eigenen Return-Path beziehungsweise eine eigene Bounce-Domain und ausgerichtetes DKIM. Linkbranding oder Tracking-Domains allein ändern den Envelope-Absender nicht.

Mögliche DNS-Muster, deren genaue Werte und Aktivierung der Anbieter vorgibt:

Type: CNAME
Host: bounces
Value: yourvendor.example.net

Type: CNAME
Host: k1._domainkey
Value: dkim1.yourvendor.example.net

Type: CNAME
Host: k2._domainkey
Value: dkim2.yourvendor.example.net

TrekMail kann bei der Einrichtung gemeinsame DNS-Anforderungen anzeigen. Dazu helfen Domain hinzufügen und Erforderliche DNS-Einträge. Je tatsächlicher MAILFROM-Domain ist ein gültiger SPF-Eintrag erforderlich. DNS-Veröffentlichung allein aktiviert keine fremde Plattform; testen Sie danach den Versand.

Schritt 2: Empfangsheader auswerten

Öffnen Sie die vollständigen Header einer betroffenen Nachricht und suchen Sie Authentication-Results, Return-Path und DKIM d=. Verwenden Sie die Ergebnisse Ihres vertrauenswürdigen Empfangsservers, nicht beliebige vom Absender mitgelieferte Header.

Die Checkliste:

1. Sichtbare From-Domain ermitteln.
2. SPF-Ergebnis prüfen.
3. Die tatsächlich SPF-geprüfte Domain bestimmen.
4. DKIM-Ergebnis prüfen.
5. Die Domain der gültigen DKIM-Signatur bestimmen.
6. Erfolgreiche Pfade mit der From-Domain vergleichen.

Ein Beispiel für fehlende Ausrichtung:

Authentication-Results: mx.google.com;
  dkim=pass header.i=@sendgrid.net header.s=s1;
  spf=pass smtp.mailfrom=bounces.sendgrid.net;
  dmarc=fail (p=reject) header.from=yourdomain.com

Beachten Sie dabei:

SPF wurde für eine Subdomain von sendgrid.net geprüft, wie der Envelope-Wert zeigt. sendgrid.net in header.i ist nicht allein die maßgebliche DKIM-Domain; prüfen Sie d= der gültigen Signatur. Zur From-Domain yourdomain.com fehlt im dargestellten Ergebnis ein erfolgreicher ausgerichteter Pfad.

Wiederholen Sie die Prüfung pro Versandstrom. Funktionierende Transaktionsmail beweist nichts über Marketing, Support oder weitergeleitete Aliasse. Ergänzend hilft E-Mail auf meiner Domain einrichten.

Schritt 3: Weiterleitung separat untersuchen

Weiterleitung kann SPF scheitern lassen, weil ein neuer Server nicht für die ursprüngliche Envelope-Domain autorisiert ist. DMARC kann dennoch bestehen, wenn eine gültige ausgerichtete DKIM-Signatur erhalten bleibt.

Das kann bei Google Groups, Outlook-Weiterleitung, Alumniadressen oder Universitätsservern auftreten. SPF-Fail allein entscheidet nicht über DMARC; erfolgreiches ausgerichtetes DKIM genügt.

RFC 7960 erläutert die Schwierigkeiten: Bei erhaltenem Envelope-Absender kann SPF am neuen Server scheitern. Umschreiben, etwa mit SRS, kann neues SPF ermöglichen, liefert aber nicht automatisch ursprüngliche From-Ausrichtung. Siehe RFC 7960.

Mehr SPF-Autorisierungen auf Verdacht sind deshalb keine allgemeine Lösung. Prüfen Sie stattdessen:

1. Unterstützte ausgehende Versandwege mit DKIM signieren und testen.
2. Gelockerte Ausrichtung erwägen, sofern keine getestete strikte Anforderung besteht.
3. Bei Mailinglisten Signaturänderungen und Empfängerentscheidungen gezielt untersuchen.

Bei wichtigen Weiterleitungswegen helfen E-Mail-Weiterleitung und Domainmail an Gmail weiterleiten. TrekMail kann je nach Tarif Weiterleitung und verwalteten SMTP bereitstellen. Die signierten Daten müssen unter den Kanonisierungsregeln erhalten bleiben; eine universelle Weiterleitungsgarantie gibt es nicht.

Schritt 4: SPF auf PermError prüfen

SPF PermError kann bei Überschreitung der Grenze von zehn DNS-auslösenden Mechanismen und Modifikatoren einschließlich verschachtelter Auswertung oder bei ungültiger Konfiguration entstehen. Das ist keine Grenze aller DNS-Pakete. Erfolgreiches ausgerichtetes DKIM kann DMARC trotzdem bestehen lassen.

Ein Beispiel mit mehreren Anbietern:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:mail.zendesk.com include:sendgrid.net include:servers.mcsv.net ~all

Der sichtbare Eintrag allein zeigt nicht, ob das Budget überschritten wird. Verschachtelte Includes und Redirect-Auswertung müssen berücksichtigt werden.

Rufen Sie zunächst die DNS-Werte ab:

dig +short txt yourdomain.com
nslookup -type=txt yourdomain.com

Eine solche Abfrage beweist noch keinen PermError. Prüfen Sie die gesamte Auswertung und den aktuellen Anbieterbedarf. Entfernen Sie einen vor sechs Monaten eingestellten Dienst nur nach Bestätigung, dass keine seltenen Versandwege ihn mehr nutzen. Mögliche getrennte Domains sind:

marketing.yourdomain.com
support.yourdomain.com
billing.yourdomain.com

Ein eigenes SPF-Budget wirkt nur, wenn der Sender tatsächlich die entsprechende Envelope-Domain verwendet und aktiviert wurde. DNS-Einträge allein teilen kein Budget auf. Prüfen Sie außerdem die gewünschte From-Ausrichtung.

TrekMails Dokumentation beschreibt die Vermeidung doppelter SPF-Einträge und das Zusammenführen passender Werte. Siehe DNS-Status prüfen.

Schritt 5: Möglichen Missbrauch von Fehlern unterscheiden

Nicht jeder DMARC-Fail erfordert eine Freigabe. Manche Nachrichten sind tatsächlich unbefugt, andere stammen aus legitimer, aber fehlerhafter oder veränderter Weiterleitung.

Unbekannte IP und doppelte Authentifizierungsfehler sind kein ausreichender Beweis. Gleichen Sie Inventar, Protokolle und Weiterleitungswege ab, statt blind freizugeben oder zu sperren. p=quarantine und p=reject stellen Behandlungsanforderungen an Empfänger dar, keine garantierten Aktionen.

Ein sinnvoller Prüfablauf:

1. Unbekannte Quelle anhand von Inventar, Protokollen und Weiterleitung identifizieren.
2. Bei legitimen Sendern die tatsächliche Plattform und Domainaktivierung bestätigen.
3. Bei fehlender Signierung unterstütztes DKIM konfigurieren und testen.
4. Ohne möglichen erfolgreichen ausgerichteten Pfad eine passende aktivierte Versanddomain oder einen kontrollierten Ersatzdienst planen.

Die Richtlinie kann bei Authentifizierungs- oder Ausrichtungsfehlern Einschränkungen anfordern. Empfänger können lokale Ausnahmen anwenden, auch unter Berücksichtigung von ARC; das macht den ursprünglichen DMARC-Fail nicht zum Pass. Die passenden Bedingungen erläutert Googles Absender-FAQ.

Typische DMARC-Probleme nach Senderart

Die Systemart liefert Hinweise, ersetzt aber keine Prüfung der betroffenen Nachricht.

DMARC-Fehler bei vielen Domains bearbeiten

Google Workspace, cPanel, SendGrid und Gmail-Weiterleitung können in einem Kundenportfolio zusammentreffen. Ohne aktuelle Dokumentation werden Authentifizierungsfehler schwerer zuzuordnen.

Ein gemeinsamer Prozess für DNS, Migration, Domainstatus, Weiterleitung und SMTP kann helfen. Auch dabei bleibt jeder tatsächliche Versandweg einzeln zu prüfen.

Als Preisorientierung nennt TrekMail ab $3.50 monatlich für bezahlte Tarife sowie eine angebotene 14-tägige Testphase. Eine kostenlose Option mit eigenem SMTP ist verfügbar. Je nach Tarif können Domains, IMAP-Postfächer, Catch-all, Weiterleitung, IMAP-Import und API-Zugriff zusammengeführt werden. Prüfen Sie aktuelle Funktionen und Limits. IMAP kopiert Mail und ersetzt keinen MX- oder Anwendungswechsel.

Für viele Kundendomains erläutert Mehrdomain-E-Mail-Hosting mögliche Arbeitsabläufe, die Sie mit Ihrer bisherigen DNS-Verwaltung vergleichen können.

Kurze Checkliste zur DMARC-Fehleranalyse

Beginnen Sie mit einer betroffenen Nachricht, bestimmen Sie die erfolgreich authentifizierten Domains und vergleichen Sie sie mit From. Untersuchen Sie danach den konkreten fehlenden Pfad statt nur einen Oberflächenstatus.

1. Vertrauenswürdige empfangsseitige Authentication-Results lesen.
2. SPF-Erfolg und die tatsächliche Envelope-Domain prüfen.
3. DKIM-Erfolg und die Domain im d= prüfen.
4. Erfolgreiche Pfade mit Header From vergleichen.
5. Ohne ausgerichteten erfolgreichen Pfad die passende Domainkonfiguration korrigieren.
6. Bei Weiterleitung Signaturgültigkeit und Erhaltung signierter Daten testen.
7. SPF-Auswertung und tatsächliche Anbieter prüfen; Domainaufteilung nur mit aktivierter Envelope-Konfiguration.
8. Unbekannte Quelle mit SPF- und DKIM-Fehlern untersuchen, statt sie automatisch als Fälschung einzustufen.

Nachvollziehbare Ergebnisse und kontrollierte Änderungen bilden den Kern des Ablaufs.

Fazit: Den tatsächlich fehlgeschlagenen Pfad korrigieren

DMARC fail kann aus Ausrichtungsfehlern, veränderter Weiterleitung, SPF PermError oder unbefugtem Versand entstehen. Das Ergebnis allein beweist keine dieser Ursachen.

Prüfen Sie die betroffene Ebene und testen Sie gezielte Änderungen. TrekMail kann je nach Tarif gemeinsamen Speicher, pauschales Mehrdomain-Hosting, eigenen SMTP mit Nano, verwalteten SMTP und IMAP-Import bieten. Weitere Informationen finden Sie bei TrekMail und auf https://trekmail.net/pricing; aktuelle Bedingungen und Grenzen sind zu berücksichtigen.