DMARC einführen

SPF, DKIM, DMARC - viele Begriffe und das Marketing sagt, dass sie Kunden bei GMAIL nicht mehr erreichen können. Was müssen Sie tun, um DMARC-konform zu sein?

Kurzfassung

Spam und Phishing sind aktive Threads beim Empfang von Mails im Internet. Schon viele Jahre können Mailserver-Administratoren schon "ihre" legitimen Mailserver für ihre Domains veröffentlichen, Sie veröffentlichen dazu die IP-Adressen ihrer Server mittels SPF oder signieren die Mails per DKIM. Wie der Empfänger diese Prüfungen umsetzt, konnten sie damit aber nicht steuern. Das erfolgt per DMARC. Als Absender können Sie eine Mailadresse für Fehlerreports und eine Richtlinie zur Anwendung von SPF/DKIM veröffentlichen. Es bleibt aber immer noch dem Empfänger überlassen, ob er dies beachtet. Er sollte es aber und die meisten tun es auch. Also liegt es an ihnen, SPF, DKIM und letztlich auch DMARC umzusetzen. Die Frage ist nun, wie dies am besten strukturiert erfolgt.

Checkliste für DMARC p=none

Es gibt immer wieder Verwirrungen über den richtigen DMARC-Eintrag. Seit Google hier gewisse Forderungen stellt, haben Firmen oft überstützt einen DMARC-Eintrag mit "P=none" angelegt. Damit war Google erst einmal wieder happy aber es ist zu kurz gesprungen. Per DMARC steuern sie, wie das Zielsystem mit Fehlern bei SPF/DKIM umzugehen hat. Für eine Einführung sind daher folgende Schritte aus meiner Sicht korrekt:

  Erledigt

DMARC-Mailadresse definieren

DMARC enthält eine "Report-Funktion", d.h. ein Empfänger kann an den Inhaber einer SMTP-Domain einen Report senden, wie bei ihm die Mails angekommen und bewertet wurden. Legen Sie am besten eine eigene Mailadresse für den Empfang der DMARC-Reports fest. Das kann eine Shared Mailbox auf ihrem Exchange Server mit einer Adresse wie "dmarc@ihredomain.tld" sein oder eine Adresse bei einem kommerziellen DMARC-Auswerter.

Definieren Sie DMARC mit "p=None und ruf=dmarc@<ihremaildomain.tld>"

Der erste Schritt ist nun ein DMARC-Eintrag, der die Reportadresse veröffentlicht und zugleich den Empfänger rät, dass er die Ergebnisse einer SPF und DKIM-Prüfung ignoriert. Ob der Empfänger dies macht und ob er ihnen einen Bericht sendet, können Sie nicht erzwingen. Aber speziell die großen Provider wie Google, Microsoft etc. liefern Daten.

Ab jetzt könnte es aber sein, dass Spammer eine so "ungeschützte Domain" bevorzugt für Phishing verwenden und einige Empfänger das DMARC-Alignment (DMARC-Validation) umsetzen und es doch zu nicht zustellbaren Mails kommt.

Dieser Zeitraum sollte eher Wochen denn Monate dauern.

Nachsteuern

Anhand der Reports können Sie nun erkennen, wer Mails mit ihrer Domain sendet. Da sind sicher einige ihrer Server und Dienste darunter, aber vielleicht auch ein paar Phishing-Versuche. Als Administrator müssen Sie nun die Einträge finden, bei denen legitime Server als nicht autorisiert eingestuft wurde. Sorgen Sie dafür, dass diese Server z.B. auf dem SPF-Record addiert werden oder DKIM signieren.

Enforce p=reject

Nach einigen Wochen oder maximal wenige Monate sollten Sie aber alle legitimen Server ermittelt und eingetragen haben. Dann ist es an der Zeit, die DMARC-Vorgaben zu erzwingen.

Ich halte von p=quarantine aber nichts, da dann auch eigene Mails von neuen Servern beim Empfänger quasi unbemerkt in der Quarantäne landen. Dann besser zurückweisen lassen, dass man einen Fehler korrigieren kann.

Betrieb

Ab sofort können nur noch ihre Server an Gegenstellen senden, die DMARC, SPF und DKIM umsetzen und beachten. Es ist aber kein 100% Schutz gegen Phishing oder Missbrauch aber die meisten Provider setzen mittlerweile DMARC um.
Denken Sie aber neue legitime Server, die Sie selbst installieren. Wenn diese nicht im SPF-Eintrag enthalten sind oder keine gültige DKIM-Signatur addieren, dann gelten diese auch als "nicht legal". und bekommen ihre Mails nicht versendet. Beachten Sie dazu auch die Reports an ihre DMARC-Adresse

p=None, p=quarantine oder p=Reject

Ohne DMARC-Eintrag wertet ein entsprechender Empfänger den SPF-Eintrag aus aber wie er mit einer DKIM-Signatur umgeht, ist nicht vorgeschrieben. Soll er eine DKIM-Signatur als Bonus bewerten? Das wird er sicher nicht tun, denn Spammer werden ganz sicher eine DKIM-Signatur anbringen. Meist sind es Firmen mit eigenem Mailserver, die noch keine DKIM-Signatur angeben. Selbst eine fehlerhafte DKIM-Signatur könnte ein Empfänger zwar als Malus bewerten aber meist wird auch dies nicht weiter beachtet.

Den Aufwand für DKIM macht nur in Verbindung mit DMARC sinn und hier gibt es die vier Einstellmöglichkeiten:

DMARC Einstellung Bewertung

nicht vorhanden

Ohne DMARC Eintrag geben Sie als Absender nicht vor, wie ein Empfänger das Ergebnis von SPF/DKIM bewerten soll und sie bekommen auch keine Rückmeldung, wenn es folgende Fehler gibt. Es ist offensichtlich, dass diese heut keine gute Konfiguration mehr ist.

p=none

Der Empfänger möge das Ergebnis einer SPF/DKIM-Prüfung nicht weiter beachten aber, sofern konfiguriert, bitte einen Report an die "ruf=" oder eine Analyse an "rua=" senden. Das ist die richtige Einstellung, wenn Sie von "nicht vorhanden" auf Quarantäne oder reject gehen wollen. Ein "p=none"-Eintrag ist nur dann falsch, wenn er dauerhaft verbleibt. Es ist ein Zwischenschritt, der nach einigen Wochen aber wieder gewechselt werden sollte.

p=quarantine

Sie weisen den Empfänger an, eine Nachrichte mit SPF=FAIL und DKIM=FAIL (beide müssen Fail sein) nicht an das Zielpostfach zuzustellen, sondern in eine Quarantäne zu legen. Ich bin kein Freund dieser Einstellung, denn legitime Absender bekommen keine Information und welcher Empfänger kontrolliert die Quarantäne? Ich könnte mir vorstellen, dass die Einstellung genutzt wird, wenn ein Admin die so unterdrückten Mails zeitnah kontrolliert aber ansonsten sage ich: "Finger weg"

p=reject

Wenn ich als Absender sicher bin, dass meine Mails alle von per SPF legitimierten Servern oder über DKIM signierten Wege versendet werden, dann schütze ich damit meine Domain gegen Phishing, wenn meine Geschäftspartner eingehende Mails aus SPF/DKIM prüfen und DMARC beachten. Zudem erhalten ich Rückmeldungen von Missbrauchsversuchen. Gegen die kann ich eigentlich nichts tun aber interessanter ist hier die Prüfung, ob es vielleicht vergessene oder neu hinzugekommene legitime Absender sind.

Nach meiner Ansicht sollten Sie ganz schnell einen DMARC-Eintrag mit einer RUF-Adresse und p=NONE anlegen, die Rückläufer einige Wochen betrachten, ggfls. SPF/DKIM nachsteuern und dann den DMARC-Eintrag auf "p=reject" umstellen.

Übrigens: Kontrollieren Sie in dem Zuge auch ihren SPF-Record, dass er am Ende ein "-all" hat. Es gibt noch viele Mailserver, die DMARC nicht verstehen und daher nur den SPF-Eintrag auswerten.

Nacharbeiten

Gesetzt den Fall, sie haben alle ausgehenden Mailserver im SPF-Record der Domain addiert und idealweise signieren alle die ausgehenden Mails per DKIM und sie haben den DMARC-Eintrag auf "p=reject" gestellt, dann könnten sie sich zurücklehnen und sich anderen Problemen widmen, Das stimt aber leider nicht ganz, denn auch mit perfekter SPF, DKIM DMARC-Konfiguration wird es Probleme und Tickets beim Mailversand geben. Hier ein paar Beispiele und den Umgang damit.

  • Weiterleitungen von B zu C
    Wenn ihre Mitarbeiter als Absender A mit mit einer per SPF/DKIM/DMARC gesicherten Domain eine Mail an B senden, der dann eine Umleitung zu C macht, dann könne es sein, das C diese Mail nicht annimmt und sich entweder B beschwert oder A eine Unzustellbarkeit bekommt. Das hängt davon ab, ob B die Mail verändert (DKIM=FAIL) oder den Absender tauscht (SPF=FAIL, Alignment=FAIL). und daher der Empfänger C die Mail ablehnt. Siehe auch DMARC bricht SPF mit SRS. Um es kurz zu machen. So sind die Regeln und das wollen Sie ja genau so.
    Wenn B die Mails legitim, z.B. im Rahmen einer Migration, an C weiterleitet, dann sollte C für Mails von B andere Regeln oder z.B. ARC - Authenticated Received Chain anwenden.
  • DMARC Implementierungsfehler
    Letztlich sind SPF, DKIM und DMARC nur "Empfehlungen". Es gibt immer wieder Berichte über fehlerhafte Implementierungen oder Konfigurationen, dass eine Mail doch nicht per SPF=PASS oder DKIM=PASS bewertet wird. Wir kennen das z.B. wenn Mails an Exchange Online über 3rdParty-Gateways oder Hybrid-Systeme geroutet werden und EXO Enhanced Filtering nicht konfiguriert wurde.
  • DMARC Reports
    Durch Angabe einer Mailadresse als RUF/RUA erhalten Sie von einigen Empfängern auch DMARC-Reports. Dies sind XML-Dateien, die eigentlich nicht manuell gelesen werden können. Suchen Sie sich einen Service oder Tool um diese Anlagen auszuwerten. Sie finden darin eigentlich drei Szenarien:
    1. Korrekt zugestellte Mails ihrer eigenen Server: Sie erhalten quasi ein remote Monitoring ihrer eigenen Konfiugration
    2. Fehler mit legitimen Mails. Das kann passieren wenn ihre Umgebung einen Fehler oder Änderung erfahren hat. Kümmern sie sich darum
    3. Phishing-Versuche durch "dumme Spammer". Dagegen können sie eigentlich nichts tun.

Ein bisschen mehr Zeit für den Betrieb eines Mailserver mit SPF/DKIM/DMARC sollten Sie daher einplanen. Auf der anderen Seite können Sie aber Zeit gewinnen, weil es für Spammer und Phishing kaum mehr möglich ist, eine Mail mit ihrer geschützten Domain zu versenden.

Weitere Links