Wenn legitime E-Mails bei DMARC durchfallen, steckt fast immer eine von wenigen vorhersehbaren Ursachen dahinter: ein fehlendes oder falsch ausgerichtetes SPF- oder DKIM-Ergebnis, Weiterleitung, die SPF bricht, oder ein Drittanbieter-Absender, der nie für Ihre Domain authentifiziert wurde. Die Lösung ist selten, Ihre Richtlinie aufzuweichen. Es geht darum, die Quelle zu finden und sie korrekt zu authentifizieren.
Wie erkenne ich, was fehlschlägt?
Beginnen Sie mit Ihren Berichten, denn die zeigen Ihnen genau, welche Quelle fehlschlägt und warum. Ihre Sammelberichte schlüsseln E-Mails nach sendender IP auf und zeigen die SPF- und DKIM-Ergebnisse samt Ausrichtung für jede Quelle. Eine Quelle, die pass bei der Rohprüfung zeigt, aber fail nach der Ausrichtung, ist das häufigste Muster und weist direkt auf das Problem hin. Falls Sie sich mit dem Lesen noch nicht sicher fühlen, führt how to read a DMARC report Sie durch die einzelnen Felder.
Sobald Sie sehen können, welche Quelle fehlschlägt, ist es fast immer eine der folgenden Ursachen.
Ursache 1: Eine Ausrichtungslücke
Das ist die häufigste Ursache. SPF oder DKIM besteht, aber für eine Domain, die nicht mit Ihrer sichtbaren Absenderadresse übereinstimmt, sodass DMARC es als Fehlschlag wertet. Meistens bedeutet das, dass ein Versanddienst sich mit seiner eigenen Domain statt mit Ihrer authentifiziert.
Die Lösung besteht darin, den Dienst in die Ausrichtung zu bringen. Für SPF bedeutet das, mit einem Return-Path (Bounce-Domain) auf Ihrer eigenen Domain zu senden. Für DKIM bedeutet es, mit einem Schlüssel zu signieren, der auf Ihrer Domain veröffentlicht ist, damit die Signaturdomain mit Ihrer Absenderadresse übereinstimmt. Die meisten E-Mail-Plattformen unterstützen genau dafür eine eigene Domain: Sie veröffentlichen ein oder zwei CNAMEs und die Ausrichtung passt. Das Konzept wird in how DMARC works erklärt.
Ursache 2: Weiterleitung
Weiterleitung bricht SPF stillschweigend. Wenn eine Nachricht weitergeleitet wird, schickt der weiterleitende Server sie weiter, und dieser Server steht nicht in Ihrem SPF-Record, sodass die SPF-Prüfung am endgültigen Ziel fehlschlägt. Gegen die Weiterleitungsregeln anderer Personen können Sie wenig tun.
Die gute Nachricht: DKIM übersteht Weiterleitung in der Regel, weil die Signatur mit der Nachricht mitreist. Genau deshalb besteht DMARC bei SPF oder DKIM: Solange Ihr DKIM korrekt eingerichtet und ausgerichtet ist, besteht weitergeleitete E-Mail DMARC auch dann, wenn SPF wegfällt. Die praktische Lösung für Weiterleitungsfehler: Stellen Sie sicher, dass DKIM korrekt eingerichtet und ausgerichtet ist, und hören Sie auf, sich über die SPF-Spalte bei weitergeleiteter E-Mail Sorgen zu machen.
Ursache 3: Ein vergessener Drittanbieter-Absender
Fast jede Organisation versendet über mehr Dienste, als sie in Erinnerung hat: ein CRM, einen Helpdesk, ein Rechnungstool, eine Marketing-Plattform, einen Umfragedienst. Jeder einzelne muss für Ihre Domain authentifiziert sein, sonst fallen seine E-Mails bei DMARC durch. Neue Quellen in Ihren Berichten sind meistens einer davon.
Arbeiten Sie sie einzeln ab. Folgen Sie für jeden legitimen Dienst dessen Anweisungen, um SPF und DKIM auf Ihrer Domain einzurichten (oft lautet die Formulierung "authenticate your domain" oder "use a custom sending domain"). Prüfen Sie dann in Ihren nächsten Berichten, ob die Quelle auf bestanden und ausgerichtet umgesprungen ist. Führen Sie eine laufende Liste, denn dieser Teil verschiebt sich, wenn Teams neue Tools einführen.
Ursache 4: SPF zu breit oder über dem Lookup-Limit
Zwei SPF-spezifische Fallen. Wenn Ihr SPF-Record über 10 DNS-Lookups hinausgewachsen ist (ein festes Limit in der Spezifikation), kann er komplett fehlschlagen und ansonsten einwandfreie E-Mails mit sich reißen. Und ein zu freizügiger Record kann E-Mails durchlassen, die Sie nicht autorisieren wollten. Prüfen Sie Ihren SPF-Record, konsolidieren Sie include:-Einträge, wenn Sie nahe am Limit sind, und entfernen Sie Dienste, die Sie nicht mehr nutzen.
Was Sie nicht tun sollten
Beheben Sie Fehler nicht, indem Sie Ihre Richtlinie auf p=none zurücksetzen und es dabei belassen. Das sorgt dafür, dass die Berichte Sie nicht mehr stören, aber es schützt auch niemanden mehr, und das Spoofing-Problem, das Sie lösen wollten, steht wieder weit offen. Behandeln Sie einen Fehler als Signal, eine Quelle zu authentifizieren, nicht als Grund zum Rückzug. Der legitime Weg zum Abschwächen ist, p= eine Stufe zurückzunehmen und die Berichte weiter zu lesen, was what is a DMARC policy behandelt.
Alles zusammensetzen
Lesen Sie den Bericht, finden Sie die fehlschlagende Quelle, entscheiden Sie, ob sie legitim ist, und authentifizieren Sie sie entweder oder erkennen Sie sie als Spoofing, das Sie jetzt blockieren. Arbeiten Sie die Liste ab, bis jeder echte Absender besteht und ausgerichtet ist und Ihre Richtlinie sicher auf reject stehen kann. Falls Sie noch in der Einrichtungsphase sind, behandelt how to set up DMARC die Grundlagen, und der authentication guide von Bird enthält die domainspezifischen Records. Die meisten Fehler sehen alarmierend aus, entpuppen sich aber als fünfminütiger Ausrichtungsfix, sobald Sie wissen, welche Quelle Sie verfolgen müssen.