DMARC-Fehler beheben: 8 Ursachen für «dmarc=fail»

So entscheidet der Empfänger über DMARC

DMARC (Domain-based Message Authentication, Reporting and Conformance) baut auf zwei Prüfungen auf. SPF prüft, ob der sendende Server für die Absenderdomain im Umschlag der Mail zugelassen ist. Diese Adresse heisst Return-Path und ist für Empfänger nicht sichtbar. DKIM prüft eine digitale Signatur, die eine bestimmte Domain an die Mail anhängt.

DMARC besteht nur, wenn mindestens eine der beiden Prüfungen besteht und ihre Domain zur sichtbaren Absenderadresse (From) passt. Dieses Passen heisst Alignment (Ausrichtung). Standardmässig gilt die lockere Ausrichtung: Die Domains müssen nur dieselbe Hauptdomain haben. bounce.example.com passt also zu example.com, newsletter.example.net nicht.

Die Ursache in der Mail-Kopfzeile finden

Senden Sie eine Testmail an ein externes Postfach und öffnen Sie die vollständigen Kopfzeilen. In Gmail heisst der Befehl «Original anzeigen», in Outlook finden Sie die Kopfzeilen unter den Eigenschaften der Nachricht. Suchen Sie die Zeile Authentication-Results. Sie sieht etwa so aus:

Authentication-Results: spf=pass smtp.mailfrom=bounce.newsletter.example.net;
 dkim=pass header.d=newsletter.example.net;
 dmarc=fail action=none header.from=example.com

Vergleichen Sie drei Domains: header.from ist Ihre sichtbare Absenderdomain. smtp.mailfrom ist die Domain, für die SPF geprüft wurde. header.d ist die Domain der DKIM-Signatur. Passt keine der beiden zu header.from, scheitert DMARC, obwohl SPF und DKIM einzeln bestehen.

Die Ursache im DMARC-Bericht finden

Die DMARC-Berichte der Empfänger zeigen alle Mails mit Ihrer Domain, gruppiert nach sendender IP-Adresse. Für jede Quelle sehen Sie das Ergebnis von SPF und DKIM, die geprüften Domains und das DMARC-Ergebnis. Suchen Sie Quellen mit nennenswertem Volumen, bei denen DMARC rot ist. Wie Sie die XML-Dateien lesen, erklärt der Ratgeber DMARC-Bericht lesen – was in den XML-Dateien steht und was Sie damit tun

Fehler 1: SPF und DKIM bestehen, aber nicht für Ihre Domain

Woran Sie es erkennen: In Kopfzeile oder Bericht steht spf=pass und dkim=pass, aber dmarc=fail. Die Domains bei smtp.mailfrom und header.d gehören dem Dienstleister, nicht Ihnen. Das ist der klassische DMARC-Alignment-Fehler.

So beheben Sie es: Sorgen Sie dafür, dass mindestens eine Prüfung mit Ihrer Domain läuft. Am zuverlässigsten ist eine DKIM-Signatur mit d=example.com. Zusätzlich bieten viele Dienste eine eigene Return-Path-Domain an, etwa bounce.example.com per CNAME-Eintrag. Dann passt auch SPF.

Fehler 2: Drittsysteme ohne eigene DKIM-Signatur

Woran Sie es erkennen: Ihre Hauptmails aus Microsoft 365 oder Google Workspace bestehen, aber Newsletter, CRM, Buchhaltungssoftware oder Webshop fallen durch. Im Bericht erscheinen fremde IP-Adressen mit dkim=none oder einer Signatur des Anbieters.

So beheben Sie es:

1. Listen Sie alle Systeme auf, die mit Ihrer Adresse senden, auch Drucker, Ticketsystem und Kontaktformular.
2. Suchen Sie im jeweiligen Tool die Einstellung zur Absenderdomain. Sie heisst oft «Domain authentifizieren» oder ähnlich.
3. Tragen Sie die angezeigten DKIM-Einträge im DNS ein, zum Beispiel einen CNAME unter s1._domainkey.example.com. Der Selektor s1 ist hier nur ein Beispiel; nehmen Sie genau den Namen, den das Tool angibt.
4. Lösen Sie im Tool die Prüfung aus und senden Sie eine Testmail.

Kann ein System gar nicht mit Ihrer Domain signieren, lassen Sie es über Ihren eigenen Mailserver senden oder geben Sie ihm eine eigene Subdomain.

Fehler 3: SPF überschreitet zehn DNS-Abfragen

Woran Sie es erkennen: Die Kopfzeile zeigt spf=permerror, oft bei allen Quellen gleichzeitig. Meist ist kurz vorher ein weiteres include: in den SPF-Eintrag gekommen.

So beheben Sie es: SPF erlaubt höchstens zehn DNS-Abfragen. Darüber gilt der ganze Eintrag als fehlerhaft, und SPF kann DMARC nicht mehr retten. Entfernen Sie ungenutzte Dienste und verlassen Sie sich bei Drittsystemen auf DKIM. Wie Sie zählen und kürzen, steht im Ratgeber SPF-Fehler «too many DNS lookups» – warum zehn Abfragen reichen müssen

Fehler 4: Weiterleitungen

Woran Sie es erkennen: Im Bericht taucht eine kleine Menge Mails von Servern auf, die Sie nicht kennen, etwa von einem Hochschul- oder Vereinsserver. SPF schlägt fehl, DKIM besteht meist.

So beheben Sie es: Bei einer Weiterleitung sendet ein fremder Server, SPF scheitert zwangsläufig. Wichtig ist, dass alle Ihre Mails eine DKIM-Signatur mit Ihrer Domain tragen. Sie übersteht die Weiterleitung, solange niemand den Inhalt verändert.

Ausführlich, auch zu SRS und ARC: Weiterleitung: SPF fail und weitergeleitete Mails im Spam

Fehler 5: Falsche Syntax im DMARC-Eintrag

Woran Sie es erkennen: Statt dmarc=fail steht dmarc=none oder ein permerror. Berichte bleiben aus, obwohl Sie eine Adresse angegeben haben.

So beheben Sie es: Ein korrekter Eintrag ist ein TXT-Eintrag unter _dmarc.example.com mit dem Wert v=DMARC1; p=none; rua=mailto:dmarc@example.com. Typische Fehler:

• v=DMARC1 steht nicht am Anfang, oder p= folgt nicht direkt danach.
• Kommas statt Semikolons zwischen den Angaben.
• Die Berichtsadresse ohne mailto:.
• Zwei TXT-Einträge mit v=DMARC1. Dann wenden Empfänger gar kein DMARC an.
• Der DNS-Editor hängt die Domain selbst an. Aus _dmarc.example.com wird so _dmarc.example.com.example.com. Tragen Sie als Name nur _dmarc ein.

Fehler 6: Subdomains

Woran Sie es erkennen: Mails mit einer Absenderadresse wie info@rechnung.example.com scheitern, die Hauptdomain besteht. Oder alles scheiterte erst, nachdem Sie adkim=s oder aspf=s gesetzt haben.

So beheben Sie es: Ohne eigenen DMARC-Eintrag gilt für Subdomains der Eintrag der Hauptdomain, mit sp= falls vorhanden, sonst mit p=. SPF hingegen vererbt sich nicht: Braucht die Subdomain SPF, braucht sie einen eigenen SPF-Eintrag. Richten Sie für sendende Subdomains SPF und DKIM ein. Die strenge Ausrichtung (s für strict) verlangt exakt gleiche Domains. Bleiben Sie bei der lockeren Standardeinstellung, solange es keinen klaren Grund dagegen gibt.

Fehler 7: Zu früh auf p=reject

Woran Sie es erkennen: Der Fehler ist eigentlich alt, aber erst jetzt merken Sie ihn. Kunden melden fehlende Mails, und Absender erhalten Rückläufer mit «rejected due to DMARC policy».

So beheben Sie es: p=reject verursacht kein dmarc=fail, es macht nur die Folgen sichtbar. Gehen Sie vorübergehend auf p=quarantine oder p=none zurück, beheben Sie die Quelle, und verschärfen Sie wieder, wenn die Berichte einige Wochen sauber sind. Was bei der Ablehnung passiert, erklärt «Rejected due to DMARC policy» – die eigene Domain blockiert die eigenen Mails und wann der Wechsel sicher ist, steht in DMARC von p=none auf quarantine und reject – wann ist es sicher?

Fehler 8: DKIM-Schlüssel rotiert oder gelöscht

Woran Sie es erkennen: Es lief monatelang, plötzlich steht dkim=fail oder «no key for signature». Oft nach einem Hosterwechsel, einer DNS-Aufräumaktion oder einem Schlüsselwechsel im Mailsystem.

So beheben Sie es: Lesen Sie in der Kopfzeile den Selektor ab (header.s oder s= in der Signatur) und prüfen Sie, ob unter <selektor>._domainkey.example.com ein vollständiger Eintrag steht. Bei Microsoft 365 müssen beide CNAME-Einträge selector1 und selector2 bestehen bleiben, auch wenn gerade nur einer aktiv ist. Weitere DKIM-Fehlermeldungen erklärt DKIM-Signatur ungültig: «body hash did not verify» und andere Fehler

So prüfen Sie, dass die Korrektur wirkt

1. Warten Sie, bis die DNS-Änderung sichtbar ist. Das dauert je nach Einstellung Minuten bis einige Stunden.
2. Senden Sie aus dem betroffenen System eine Testmail an ein externes Postfach und prüfen Sie dmarc=pass in der Kopfzeile.
3. Kontrollieren Sie die DMARC-Berichte der nächsten Tage. Die Quelle muss dort grün sein, bei allen grossen Empfängern.

Was DomainRadar dabei übernimmt

DomainRadar gibt Ihnen eine Berichtsadresse, wertet die DMARC-Berichte täglich aus und ordnet die IP-Adressen den Diensten zu. Sie sehen auf einen Blick, welche Quelle scheitert und ob SPF, DKIM oder die Ausrichtung der Grund ist. Taucht eine neue Quelle mit Fehlern auf oder verschwindet ein DKIM-Selektor, erhalten Sie einen Alarm.