Überblick
LetsDMARC zeigt Fehler, die von E-Mail-Sicherheitsdiensten und von weiterleitenden Servern Ihrer Empfänger stammen. Hinter diesen Fehlern stehen Kopien von Nachrichten, die Sie korrekt versendet haben und die jemand anderes ein zweites Mal zugestellt hat. Der Fehler entsteht weder durch Ihre Systeme noch durch einen Fehler von LetsDMARC, und er ist kein Grund, den Wechsel zur Richtlinie reject aufzuschieben.
Vorbereitung
- Zugang zum LetsDMARC Dashboard für die Domain, die Sie betrachten.
- Die Liste der Quellen, die wirklich in Ihrem Namen versenden, etwa Ihr Gateway, Ihr Tenant, Ihre Marketingplattform und Ihr Ticketsystem.
- Der aktuelle DKIM-Status jeder dieser Quellen.
Funktionsweise
Ihre Nachricht verlässt Ihr Gateway und besteht bei der ersten Zustellung SPF, DKIM und DMARC. Der empfangende Server nimmt sie an, und genau diese Zustellung zählt für Sie und für Ihren Empfänger.
Viele Empfänger bewegen die Nachricht danach ein zweites Mal. Ihr Mailserver übergibt sie über einen Connector, eine Transportregel oder eine API an einen externen Sicherheitsdienst, oder eine Postfachregel leitet sie an eine andere Adresse weiter. In beiden Fällen wird die Nachricht erneut zugestellt, und diese zweite Zustellung startet von einer IP-Adresse, die dem Dienst oder dem weiterleitenden Server gehört.
Diese Adresse steht nicht in Ihrem SPF-Eintrag, also schlägt SPF fehl, und das ist richtig so, denn Sie haben diesen Host nie für den Versand Ihrer Domain autorisiert. Wenn der Dienst die Nachricht zusätzlich verändert, etwa durch einen Warnhinweis im Text, umgeschriebene Links oder einen geänderten Betreff, bricht auch die DKIM-Signatur. Ohne ausgerichtetes SPF und ohne ausgerichtetes DKIM schlägt DMARC fehl.
Das System, das diese zweite Kopie erhält, sendet einen aggregierten Bericht an Ihre Domain, denn im Header From steht weiterhin Ihre Domain. LetsDMARC liest diesen Bericht und zeigt den Fehler mit dem Namen des Dienstes als Quelle.
Symptome
Auf der Seite DMARC reports by sources sehen Sie Fehler von Hostnamen, die Sie nicht kennen und nie eingerichtet haben. Sie erscheinen auch im Bereich Top 5 failure sources, und dort beginnt meist die Frage. Die vollständige Liste steht in der großen Tabelle Details am Ende der Seite, mit einer Zeile für jede Quelle, die mit Ihrer Domain im Header From versendet hat.
Bisher beobachtete Quellnamen sind cloud-sec-av.com, inkyphishfence.com, perception-point.io, shield.security, ppe-hosted.com, mimecast.com, sonicwall.com und oraclecloud.com. Die Liste wächst weiter, denn sie hängt davon ab, welches Produkt jeder Ihrer Empfänger gekauft hat.
Diese Quellen zeigen eine Compliance nahe null, SPF und DKIM stehen beide auf null, während Ihre eigenen Versandplattformen bei neunundneunzig oder hundert Prozent bleiben. Ihr Volumen ist ein kleiner Teil Ihres Gesamtverkehrs.
Vier Anzeichen zusammen zeigen Ihnen, dass Sie diesen Fall vor sich haben.
| Worauf Sie achten | Was Sie in diesem Fall sehen |
|---|---|
| Quelle | Ein bekannter E-Mail-Sicherheitsdienst oder ein Server, der Nachrichten für einen Empfänger weiterleitet |
| Header From | Dieselbe Domain wie bei Ihren legitimen Quellen, denn die Nachricht ist eine Kopie Ihrer eigenen |
| Forwarded | Oft ein Wert über null. LetsDMARC ermittelt ihn selbst, und er liegt nicht immer bei hundert Prozent: manchmal ist er niedriger, manchmal bleibt er bei null, obwohl der Dienst sicher weiterleitet. Lesen Sie ihn als Hinweis, nicht als Beweis |
| Volumen | Im Rahmen Ihres normalen Verkehrs zu diesem Empfänger, ohne plötzliche Spitzen |
Ursache
Den Fehler erzeugt derjenige, der die zweite Zustellung durchführt. Ihn erzeugen nicht Ihre Server, die bei der ersten Zustellung korrekt gearbeitet haben, und er ist kein Fehler von LetsDMARC, das nur die Berichte anzeigt, die es von den Systemen mit dieser zweiten Kopie erhält.
Auf Ihrer Seite ist nichts kaputt. Es gibt keine Einstellung in Ihrem DNS, in Ihrem Gateway oder in LetsDMARC, die aus diesen Fehlern ein Bestehen macht, denn die fehlschlagende Zustellung führt ein Host durch, der Ihnen nicht gehört und den Sie nicht steuern können.
Lösung
- Öffnen Sie die große Tabelle Details am Ende der Seite und sehen Sie sich die fehlschlagende Quelle an. Handelt es sich um einen E-Mail-Sicherheitsdienst oder einen weiterleitenden Server eines Ihrer Empfänger, ist nichts zu tun.
- Versuchen Sie nicht, diese Fehler zum Bestehen zu bringen. Der Versuch, sie zu reparieren, führt als Einziges zu einer gefährlichen Änderung, und richtig ist, sie bei der Bewertung Ihrer Domain nicht mitzuzählen.
- Nehmen Sie die IP-Adressen oder den SPF-Include dieser Dienste niemals in Ihren eigenen SPF-Eintrag auf.
- Sorgen Sie dafür, dass jede Ihrer legitimen Quellen mit einem ausgerichteten DKIM-Schlüssel signiert. Eine unversehrte Signatur übersteht eine einfache Weiterleitung, sodass ein Teil dieser zweiten Zustellungen DMARC allein über DKIM bestehen kann.
- Wechseln Sie zur Richtlinie reject, sobald Ihre legitimen Quellen konform sind. Diese Fehler allein sind kein Grund zu warten.
Den Sicherheitsdienst eines Empfängers in Ihren SPF-Eintrag aufzunehmen ist die eine Änderung, die alles verschlimmert, denn ab diesem Moment kann jeder Nutzer dieser Plattform mit Ihrer Domain versenden und SPF bestehen.
Ergebnis prüfen
Filtern Sie die Tabelle Details auf Ihre eigenen Versandquellen und prüfen Sie, dass jede davon konform ist, mit ausgerichtetem SPF oder DKIM. Diese Zahl entscheidet, ob Sie für reject bereit sind.
Sehen Sie sich danach die fehlschlagenden Quellen erneut an. Sind es ausschließlich Sicherheitsdienste oder weiterleitende Server und bleibt das Volumen im Rahmen Ihres normalen Verkehrs, ist Ihre Domain in gutem Zustand, auch wenn der Fehlerzähler weiter steigt.
Bekannte Einschränkungen
- Ihre erste Zustellung ist nie betroffen. Die Nachricht, die Sie versenden, besteht DMARC, die Richtlinie reject betrifft sie also nicht, sie wird nicht blockiert und nicht als Fehler gezählt. Die sichtbaren Fehler betreffen nur die zweite Zustellung.
- Was mit der zweiten Kopie geschieht, lässt sich von Ihrer Seite aus nicht vorhersagen. Es hängt davon ab, wie der Empfänger den Dienst eingerichtet hat, was der Dienst mit der Nachricht macht und welches System die endgültige Entscheidung trifft, und ein schlecht eingerichteter Dienst kann dazu führen, dass diese Kopie abgewiesen wird.
- SPF kann die zweite Zustellung nicht überstehen, weil die Nachricht von einem Host ausgeht, den Sie nicht autorisiert haben. So ist SPF konzipiert.
- DKIM übersteht eine einfache Weiterleitung, bricht aber, sobald der Dienst die Nachricht verändert.
- Diese Berichte treffen weiter ein, solange Ihre Empfänger diese Dienste nutzen. Von Ihrer Seite aus können Sie sie nicht stoppen.