DMARC fail: was es bedeutet und wie Sie es beheben

„DMARC fail“ heißt: Der empfangende Server fand keinen Grund zu glauben, dass die Nachricht von der Domain im Von-Feld stammt. DMARC besteht, wenn mindestens eine von zwei Prüfungen besteht und ausgerichtet ist:

SPF besteht für die Umschlagdomain (die verborgene Rücklaufadresse), und diese Domain stimmt mit der Von-Domain überein;
DKIM bestätigt eine Signatur, die mit der Von-Domain erstellt wurde (das d= der Signatur), im voreingestellten lockeren Modus auch mit einer ihrer Subdomains.

Eine Nachricht kann also SPF bestehen, DKIM bestehen und trotzdem an DMARC scheitern, weil beides für die Domain eines anderen bestanden hat.

Zuerst das Urteil lesen

Lassen Sie sich eine abgelehnte Nachricht als Anhang schicken und öffnen Sie die Kopfzeilen, oder fügen Sie sie in den E-Mail-Header-Analyzer ein. Suchen Sie die Zeile, die der Empfänger hinzugefügt hat:

Authentication-Results: mx.example.net;
  spf=pass smtp.mailfrom=bounces.mailtool.example;
  dkim=pass header.d=mailtool.example;
  dmarc=fail header.from=ihre-domain.de

Beide Prüfungen haben bestanden, aber für mailtool.example. Für ihre-domain.de wurde nichts signiert oder gesendet: Der Dienst ist für Ihre Domain nicht authentifiziert.

Gateways formulieren es anders. Mimecast meldet DNS Authentication: DMARC Fail, Microsoft 550 5.7.509, Gmail 550-5.7.26. Alle meinen dasselbe, und die Lösung liegt beim Absender.

Die sechs üblichen Ursachen

1. Ein Dienst sendet in Ihrem Namen ohne DKIM für Ihre Domain. Die häufigste: ein Newsletter-Tool, ein CRM, eine Rechnungssoftware. Richten Sie dort die Domain-Authentifizierung ein, damit mit d=ihre-domain.de signiert wird. Das include: im SPF reicht oft nicht, weil viele Dienste ihre eigene Rücklaufadresse verwenden.

2. Weiterleitung. Eine über einen Zwischenserver weitergeleitete Nachricht kommt von dessen Adresse, und SPF scheitert. DKIM übersteht die Weiterleitung, solange die Nachricht unverändert bleibt. Deshalb sollte jeder Dienst mit DKIM signieren und sich nicht auf SPF verlassen.

3. dkim=fail (body hash did not verify). Die Nachricht wurde nach dem Signieren verändert: eine Fußzeile oder ein Disclaimer vom Gateway, Links, die ein Sicherheitsfilter umschreibt, eine Mailingliste, die Text ergänzt. Signieren Sie nach dem letzten System, das die Nachricht verändert, oder lassen Sie dieses System selbst signieren.

4. SPF permerror. Mehr als zehn DNS-Abfragen, zwei SPF-Einträge oder ein Syntaxfehler: SPF scheitert für jede Nachricht. Der SPF-Check zeigt es, und Zu viele DNS-Abfragen erklärt die Behebung.

5. Strikte Ausrichtung. adkim=s oder aspf=s im DMARC-Eintrag verlangen eine exakte Übereinstimmung. Von news.ihre-domain.de signierte E-Mails scheitern dann für ihre-domain.de. Entfernen Sie die beiden Tags, wenn es keinen Grund für sie gibt.

6. Zwei DMARC-Einträge oder keiner lesbar. Empfänger ignorieren eine Domain mit mehreren _dmarc-Einträgen. Der DMARC-Check meldet das.

Was Sie nicht tun sollten

Gehen Sie nicht auf p=none zurück, um einen Fehler verschwinden zu lassen. Das öffnet Ihre Domain wieder für alle Fälscher, um einen einzigen Absender zu reparieren. Finden Sie den Absender in Ihren DMARC-Berichten (der DMARC-Berichtsleser ordnet die Quellen nach Ergebnis), authentifizieren Sie ihn, und die Fehler hören auf.

Ihre E-Mails scheitern nur bei einem Empfänger

Lehnt ein einziges Unternehmen Sie ab, während andere dieselbe Nachricht annehmen, ist sein Gateway oft strenger als Ihre Richtlinie: Manche lehnen DMARC-Fehler sogar bei p=none ab. Die Lösung bleibt dieselbe, die Nachricht muss bestehen, aber das erklärt, warum „es bei allen anderen funktioniert“.

Für den Weg von der Beobachtung zur Durchsetzung, sobald alles besteht: Von p=none zu p=reject.