DMARC-Einrichtung und -Konfiguration: Schritt-für-Schritt-Anleitung

Auf hoher Ebene lässt sich der auf der Domain basierende Standard für Nachrichtenauthentifizierung, Berichterstellung und Konformität (DMARC) für ausgehende E-Mails einfach implementieren, indem der DNS-Eintrag einer Organisation um eine Textdatei ergänzt wird. In der Praxis können die komplexen Strukturen moderner Organisationen den Prozess jedoch erheblich erschweren und ein schrittweises Vorgehen erforderlich machen, damit keine legitimen E-Mail-Absender plötzlich als SPAM eingestuft werden.

Die grundlegenden Schritte sind:

1. Einen DMARC-Eintrag beim DNS-Provider veröffentlichen
2. DMARC-Berichte überwachen, um legitime Absender zu erfassen, die DMARC nicht bestehen
3. SPF, DKIM und DMARC nach Bedarf anpassen, damit legitime Quellen die Prüfung bestehen
4. DMARC-Einschränkungen verschärfen
5. DMARC-Berichte auf legitime Quellen überwachen, die die Prüfung nicht bestehen, sowie auf potenziell böswillige Quellen, die versuchen, die Organisation zu imitieren

Natürlich erfordern diese grundlegenden Schritte für die Umsetzung oft zusätzliche Details. Daher behandelt dieser Artikel die folgenden Punkte ausführlicher:

• So richten Sie einen DMARC-Eintrag ein
• DMARC-Eintrags-Tags im Detail
• DMARC-Tests und -Implementierung
• Fazit: Eine wirksame DMARC-Einrichtung implementieren und von den Vorteilen profitieren

Wer sein Wissen zu DMARC auffrischen möchte, sollte zuerst Was ist DMARC? Definitionen, Vor- und Nachteile und mehr lesen.

So richten Sie einen DMARC-Eintrag ein

Das Erstellen eines DMARC-Eintrags kann unkompliziert sein. Allerdings hängt dieser Standard von anderen E-Mail-Authentifizierungsstandards ab. Zum Einrichten eines DMARC-Eintrags müssen zunächst diese abhängigen Standards eingerichtet und anschließend der DMARC-Eintrag veröffentlicht werden.

Abhängige E-Mail-Authentifizierungsstandards

DMARC setzt die erfolgreiche Einrichtung des Sender Policy Frameworks (SPF) und von DomainKeys Identified Mail (DKIM) voraus. Zwar ist es möglich, eine DMARC-Richtlinie in einem DNS-Eintrag zu definieren, ohne SPF und DKIM zuvor einzurichten, doch sie könnte dann nichts bewirken. DMARC-Richtlinien legen fest, wie SPF- und DKIM-Einträge von E-Mail-Servern verarbeitet werden.

Die Konfiguration von SPF, DKIM und DMARC muss getestet werden, um sicherzustellen, dass die definierten Richtlinien wie vorgesehen funktionieren und nicht versehentlich legitime E-Mails blockieren. Dieser Test wird weiter unten im Abschnitt „DMARC-Tests und -Implementierung“ ausführlicher behandelt und erklärt, warum es empfehlenswert ist, mit den Optionen „none“ und „quarantine“ in einer weniger strengen Konfiguration zu beginnen.

DMARC veröffentlichen

Zum Einrichten von DMARC veröffentlicht eine Organisation bei ihren DNS-Registraren eine Textdatei, den sogenannten DMARC-Eintrag. DMARC-Einträge können kostenlos veröffentlicht werden, und das Unternehmen kann die Textdatei beliebig oft ändern. Der DMARC-Eintrag besteht aus einer einfachen einzeiligen Eingabe. Viele Organisationen können einen Eintrag veröffentlichen, indem sie:

1. sich bei ihrem Domain-Registrar anmelden
2. auf die Option zum Verwalten oder Konfigurieren der DNS-Einstellungen klicken
3. auf die Option „Add a New Record“ klicken und einen „TXT“-Eintrag auswählen
4. den Text des DMARC-Eintrags in das entsprechende Feld kopieren und einfügen

In vielen Host-Konfigurationen wird der Domainname automatisch zum Dateinamen hinzugefügt. Andernfalls muss der Eintrag manuell benannt werden:

• Syntax: _dmarc.<Domain oder Subdomain>
• Subdomain-Beispiel: _dmarc.mailservers.ExampleDomain.com
• Domain-Beispiel: _dmarc.NonProfitHealthcareExample.org

Verschiedene DNS-Provider können unterschiedliche Anforderungen oder Verfahren haben. Daher sollte eine Organisation ihre Optionen beim jeweiligen Provider sorgfältig prüfen. DMARC-Richtlinien können für Subdomains separat eingerichtet werden. Eine Subdomain ohne eigene DMARC-Richtlinie übernimmt jedoch die DMARC-Richtlinie der übergeordneten Domain.

Natürlich lässt sich der DMARC-Eintrag einfach veröffentlichen und besteht nur aus einer Textdatei. Dennoch unterschätzen manche, wie leicht sich dabei ein Fehler machen lässt. Um Probleme zu vermeiden, müssen wir die Tags des DMARC-Eintrags im Detail verstehen.

DMARC-Eintrags-Tags im Detail

Um den DMARC-Eintrag zu verstehen, beginnen wir mit einem Beispiel und sehen uns anschließend die detaillierten Optionen für jedes Tag an.

v=DMARC1;p=none;rua=mailto:dmarc@dxampledomain.com;ruf=mailto:dmarc@exampledomain.com;rf=afrf;pct=100

Von diesen Feldern sind nur die ersten beiden, „v“ und „p“, erforderlich und müssen an erster Stelle und in dieser Reihenfolge aufgeführt werden. Die übrigen Variablen sind optional, die meisten werden jedoch empfohlen. Sie können in beliebiger Reihenfolge stehen, solange „v“ zuerst und anschließend „p“ kommt.

Tags werden durch Semikolons ( ; ) ohne zusätzliche Leerzeichen getrennt. Bei Verwendung des Tags „rua“ zum Versand von DMARC-Berichten per E-Mail muss vor jeder E-Mail-Adresse das Präfix mailto: ergänzt werden. Obwohl nur beim Tag „v“ die Groß- und Kleinschreibung berücksichtigt wird, empfiehlt es sich, für alle Tags außer „v“ ausschließlich Kleinbuchstaben zu verwenden.

v=DMARC1 

Das Tag „v“ steht für den Versionsbezeichner, der immer „DMARC1“ lautet. Ein empfangender Server sucht danach, wenn er den DNS-Eintrag der Domain prüft, von der die Nachricht gesendet wurde. Enthält die Domain keinen Texteintrag, der mit „v=DMARC1“ beginnt, führt der empfangende Server keine DMARC-Prüfung durch. Das Tag „v“ ist die einzige Option, bei der die Groß- und Kleinschreibung relevant ist; DMARC1 muss vollständig in Großbuchstaben geschrieben werden.

p=none 

Das Tag „p“ steht für Richtlinie und weist den teilnehmenden empfangenden E-Mail-Server an, was mit E-Mails geschehen soll, die die SPF- oder DKIM-Prüfungen nicht bestehen, aber vorgeben, von Ihrer Domain zu stammen. In diesem Fall lautet die Richtlinie „none“.

Die drei Richtlinienoptionen sind:

• p=none: Die nachsichtigste Einstellung. „none“ weist den empfangenden E-Mail-Server an, keine Maßnahmen gegen nicht qualifizierte E-Mails zu ergreifen.
• p=quarantine: Dieser etwas strengere Befehl weist den empfangenden E-Mail-Server an, nicht qualifizierte E-Mails zu isolieren, in der Regel durch Verschieben in den Spam-Ordner.
• p=reject: Die strengste Einstellung. „reject“ weist den empfangenden E-Mail-Server an, alle nicht qualifizierten E-Mails für die Domain abzulehnen. Nur E-Mails, die nachweislich von Ihrer Domain signiert wurden, dürfen versuchen, den Posteingang des Empfängers zu erreichen. Alle anderen E-Mails werden verworfen, um Fehlklassifizierungen zu vermeiden.

Beachten Sie, dass DMARC-Anweisungen vom empfangenden E-Mail-Server ignoriert oder geändert werden können. Microsoft Office 365 behandelt beispielsweise „reject“ und „quarantine“ gleich und verschiebt E-Mails mit fehlgeschlagener DMARC-Prüfung in den Spam-Ordner.

rua=mailto:dmarc@exampledomain.com

Ein besonders wichtiges Element der DMARC-Richtlinie ist der integrierte Berichtsmechanismus. Er ermöglicht Domainadministratoren zu erkennen, ob E-Mails die Prüfung nicht bestehen oder ein Angreifer versucht, eine bestimmte Domain zu fälschen.

„rua=mailto:“ und die auf das Tag folgende E-Mail-Adresse legen fest, an welche Adresse zusammengefasste Berichte über DMARC-Fehler gesendet werden sollen. Diese Berichte enthalten allgemeine Informationen zu DMARC-Fehlern, jedoch keine Details.

ruf=mailto:dmarc@exampledomain.com 

Wie das andere E-Mail-Tag legt „ruf=mailto:“ die E-Mail-Adresse fest, die für detaillierte forensische Berichte zu DMARC-Fehlern verwendet wird. Diese forensischen Berichte enthalten umfangreiche Details zu jedem Fehler. Empfangende E-Mail-Server senden diese Dateien in Echtzeit, sobald die Fehler auftreten.

In unserem Beispiel verwenden „rua“ und „ruf“ dieselbe E-Mail-Adresse. Organisationen können jedoch unterschiedliche Empfänger auswählen. Sie sollten allerdings beachten, dass die für „ruf“ verwendete „mailto:“-E-Mail-Adresse – anders als beim Tag „rua“ – aus der Domain stammen muss, in der der veröffentlichte DMARC-Eintrag liegt.

rf=afrf

Das „rf“-Tag oder Berichtsformat ist standardmäßig auf „afrf“ beziehungsweise „aggregate failure reporting format“ eingestellt.

pct=100 

Die Variable „pct“ oder Prozentsatz teilt dem empfangenden E-Mail-Server mit, welchem prozentualen Anteil der eingehenden E-Mails die Vorgaben der DMARC-Richtlinie entsprechen müssen. Der Wert kann zwischen 1 und 100 liegen. In unserem Beispiel verlangt „pct=100“, dass 100 % aller E-Mails, die die DMARC-Prüfung nicht bestehen, abgelehnt werden. Wäre der Wert hingegen auf 5 % gesetzt, würden nur 5 % der fehlerhaften E-Mails abgelehnt.

sp

Das sp-Tag für die Subdomain-Richtlinie legt fest, ob der empfangende E-Mail-Server die DMARC-Richtlinie auf die Subdomains der Organisation anwenden soll.

aspf=r

Das „aspf“- oder SPF-Alignment-Tag legt fest, ob eine MailFROM-Domain und der „From“-Wert im Header (der ebenfalls anhand von SPF geprüft wird) exakt übereinstimmen müssen oder ob eine Übereinstimmung zwischen übergeordneter und untergeordneter Domain zulässig ist. Der Wert „r“ steht für „relaxed“ (eine Übereinstimmung zwischen übergeordneter und untergeordneter Domain ist zulässig), während „s“ eine strikte, exakte Übereinstimmung erfordert.

Beispiel:

adkim 

Das „adkim“- oder DKIM-Alignment-Tag kann entweder „s“ für „strict“ oder „r“ für „relaxed“ lauten. Die strikte Einstellung stellt sicher, dass DKIM nur dann erfolgreich ist, wenn das Feld „d=“ in der Signatur exakt mit der „From“-Domain übereinstimmt. Bei der lockeren Einstellung ist DKIM in allen Fällen erfolgreich, in denen das Feld „d=“ mit der Root-Domain der „From“-Adresse übereinstimmt.

fo

Die Option „fo“ für die Fehlerberichterstattung ist standardmäßig auf „0“ gesetzt. Eine Organisation kann jedoch manuell eine der folgenden Optionen auswählen:

• 0 = Ein DMARC-Fehler- oder forensischer Bericht wird gesendet, wenn die E-Mail sowohl beim SPF- als auch beim DKIM-Alignment fehlschlägt.
• 1 = Ein DMARC-Fehler- oder forensischer Bericht wird gesendet, wenn die E-Mail entweder beim SPF- oder beim DKIM-Alignment fehlschlägt.
• d = Ein DKIM-Fehlerbericht wird gesendet, wenn die E-Mail die DKIM-Validierung nicht besteht (unabhängig davon, ob sie korrekt ausgerichtet ist).
• s = Ein SPF-Fehlerbericht wird gesendet, wenn die E-Mail die SPF-Validierung nicht besteht (unabhängig davon, ob sie korrekt ausgerichtet ist).

ri 

Das „ri“-Tag ist standardmäßig auf „86400“ gesetzt und legt das Zeitintervall zwischen zwei aufeinanderfolgenden zusammengefassten Berichten fest.

DMARC-Tests und -Implementierung

Durch die Veröffentlichung des DMARC-Eintrags wird DMARC für eine bestimmte Domain eingerichtet. Das bloße Einrichten von DMARC ist jedoch nur der Anfang. Eine Organisation muss die Einträge auf ihre Korrektheit prüfen, unerwartete Ergebnisse überwachen, Probleme beheben und die DMARC-Einstellungen verschärfen, um nicht autorisierte E-Mails zu blockieren.

Hinweis: Die DNS-Propagation kann einige Zeit dauern. Daher sollten einige dieser Tests erst mehrere Tage nach der DNS-Aktualisierung durchgeführt werden.

SPF-, DKIM- und DMARC-Tests

Eine Google-Suche nach SPF-Tests, DKIM-Tests und DMARC-Tests liefert eine Liste von Quellen für Online-Tools, die Formatierungsprobleme und die fehlerhafte Verwendung von Variablen erkennen können. Diese Tests sollten zuerst durchgeführt werden, um die einfachen Fehler zu finden.

Diese Tests können jedoch keine Tippfehler bei Domains, E-Mail-Adressen oder IP-Adressen erkennen. Stattdessen muss die Organisation Test-E-Mails versenden, um diese Arten von Problemen zu prüfen. Detailliertere Informationen zur Fehlerbehebung und zu häufigen Fehlern finden Sie unter Warum DMARC fehlschlägt: 3 kritische Probleme bei der DMARC-Implementierung.

DMARC-Überwachung

Bei der erstmaligen Einrichtung von DMARC sollte eine Organisation „p=none“ festlegen und die Berichte auf unerwartete Ergebnisse prüfen. So kann eine Organisation beispielsweise feststellen, dass ein Drittanbieter-Versanddienst oder ein unerwarteter E-Mail-Server E-Mails versendet, die bei der Einrichtung von SPF oder DKIM übersehen wurden. Außerdem kann die Organisation zwar häufig die meisten Marketinganbieter, Supportsysteme, Posteingangsdienste und Drip-E-Mail-Dienste im Voraus identifizieren, doch zu den regelmäßig übersehenen E-Mail-Quellen gehören auch Warnmeldungen von Servern und Verwaltungstools.

Typischerweise benötigen Organisationen mehrere Wochen bis mehrere Monate, um die DMARC-Ergebnisse zu überwachen und SPF sowie DKIM um zusätzliche E-Mail-Server zu ergänzen.

Bekannte E-Mail-Quellen auf DMARC, DKIM und SPF ausrichten

Sobald neue E-Mail-Quellen identifiziert wurden, muss das IT-Team diese Quellen in die DKIM- und SPF-Dateien aufnehmen, um die Ausrichtung für DMARC sicherzustellen. Die einzelnen Quellen zu identifizieren, kann schwierig sein. Eine Möglichkeit, dies zu erleichtern, besteht darin, eine Liste aller Quellen in der Organisation zu erstellen, von denen bekannt ist, dass sie E-Mails versenden.

Sobald neue Quellen in den Berichten auftauchen, kann die Organisation versuchen, sie bekannten Quellen wie E-Mail-Anbietern, E-Commerce-Systemen und Marketingdiensten zuzuordnen. Häufige Beispiele sind Google Apps (Gmail), Salesforce, Intercom, Campaign Monitor, Mailchimp und Microsoft 365.

Ohne den Einsatz von Drittanbietertools, die wichtige Daten ordnen und hervorheben, können Berichte schwer verständlich sein. Einige Berichtsanalyse-Tools liefern beispielsweise hilfreiche Informationen, indem sie die Quell-IP-Adresse von E-Mail-Servern auflösen und so den Standort und Inhaber der IP-Adresse anzeigen. Diese Informationen können entscheidend sein, um die Legitimität der E-Mail-Quelle zu bestimmen.

Dienste wie Zendesk, Campaign Monitor, Google Apps und Rackspace bieten Artikel dazu, welche SPF- oder DKIM-Einträge zu Ihrem DNS hinzugefügt werden müssen. In einigen Fällen kann die Schwierigkeit, die Anforderungen eigener Server zu verwalten, dazu führen, dass Organisationen ihre E-Mail auf einen Dienst migrieren, der auch die Einrichtung von DKIM und SPF übernehmen kann.

Einige fehlerhafte Quelldomains/IPs ergeben keinen Sinn. Häufig handelt es sich dabei um legitime Nachrichten, die von Benutzern weitergeleitet wurden, es jedoch nicht geschafft haben, die SPF- und DKIM-Header zu erhalten. Kleinere E-Mail-Quellen, die in einem bestimmten Zeitraum weniger als 10 E-Mails versendet haben, können in der Regel ignoriert werden.

DMARC-Richtlinien-Tags verschärfen

Nachdem alle durch die Überwachung erfassten E-Mail-Quellen zu SPF und DKIM hinzugefügt wurden, muss die Organisation das Richtlinien-Tag auf „quarantine“ oder „reject“ verschärfen. Solange diese letzte Anpassung nicht vorgenommen wird, werden Spoofer und Spammer, die versuchen, die Marke der Organisation zu imitieren, nicht aufgehalten.

Fazit: Eine wirksame DMARC-Einrichtung implementieren und von den Vorteilen profitieren

Die Implementierung einer wirksamen DMARC-Richtlinie kann die Zustellung von E-Mail-Marketingkampagnen um 5–10 % verbessern, die Reputation der Domain steigern und Spam- sowie Spoofing-E-Mails, die versuchen, die Marke einer Organisation zu imitieren, drastisch reduzieren. Von diesen erheblichen Vorteilen kann eine Organisation jedoch nur profitieren, wenn sie ihren DMARC-Eintrag ordnungsgemäß einrichtet. Der dafür erforderliche Zeit- und Arbeitsaufwand lohnt sich jedoch.

Dieser Artikel wurde ursprünglich von Sean Michael Kerner am 24. Januar 2018 verfasst und veröffentlicht und von Chad Kime am 1. Juni 2023 aktualisiert.