DMARC-Implementierung

  • Aktualisiert

DMARC steht für Domain-Based Message Authentication Reporting and Conformance (DMARC) und ist ein Mechanismus, der dem sogenannten E-Mail-Spoofing entgegenwirken soll. Unter E-Mail-Spoofing versteht man den Versand von Spam-E-Mails mit gefälschten Absender-Domains meist im Namen von bekannten Unternehmen und Marken, die sich dieses Missbrauchs gar nicht bewusst sind. Diese führen oft zu hohen Bounce-Raten, Spam Trap Hits und Spam Beschwerden, welche technisch auch dem wirklichen Domain-Eigentümer angehaftet werden und sich negativ auf die Reputation seiner Domain und damit Versendungen auswirken.

DMARC trägt also in großem Maße zum Schutz der Online-Reputation Ihrer Domains und Ihrer Marke bei, indem dieser den Domain-Missbrauch verhindert oder zumindest reduziert. Weiterhin vergeben teilnehmende Internet Service Provider Versendern mit einem DMARC-Eintrag eine bessere Reputation und ermöglichen so auch bessere Zustellungsergebnisse. Zusätzlich ist DMARC ein Basiskriterium für die Einrichtung von BIMI (Brand Indicators for Message Identification).

DMARC wird bereits u. a. von folgenden ISPs unterstützt: Gmail, Yahoo, AOL, Microsoft, Netease (126.com, 163.com), Tencent (qq.com), Mail.ru, Comcast, AT&T, British Telecom, Virgin Media, Italia Online. 1&1 (GMX, Web.de) befindet sich in der Implementierung.

Funktionsweise und Voraussetzungen

Das Handling von potenziellen Spam-E-Mails obliegt generell dem empfangenden ISPs. Dieser arbeitet zum Schutz seiner Empfänger mit einer Vielzahl von Sicherheitsmetriken, unter anderem Sender Policy Framework (SPF) und DomainKeys Identified Mail (DKIM), um deren Postfächer vor Spam-, Scam- oder Phishing-E-Mails zu schützen.

Mittels DMARC können Sie als Versender dem empfangenden Mailbox-Provider nun selbstbestimmt mitteilen, wie dieser mit E-Mails verfahren soll, wenn diese sich nicht per SPF und DKIM authentifizieren können. Man kann DMARC also als eine dritte Schutzschicht sehen, welche auf den bestehenden Authentifizierungsmechanismen SPF und DKIM basiert und diese ergänzt. Die Umsetzung dieser beiden Authentifizierungsstandards wird bei Optimizely standardmäßig im Onboarding oder beim Setup zusätzlicher Versand-Domains verlangt.

Zudem macht das mögliche DMARC-Reporting Fälle von Domain-Abuse erstmalig sichtbar. Dies hilft Ihnen, aktuelle Zustellungstrends Ihrer E-Mails zu verstehen und Ihre Reputation zu monitoren.

DMARC-Eintrag

DMARC kann generell für die gesamte Haupt-Domain oder speziell für eine zum Versand genutzte Subdomain eingerichtet werden. Idealerweise wird DMARC für die Haupt-Domain gesetzt, um die komplette Domain, alle zugehörigen Subdomains und damit auch die Marke als Ganzes vor Missbrauch zu schützen. Wichtig für die Zustellung ist das Bestehen eines DMARC-Eintrags für die Sender Domain.

Der DMARC-Eintrag vererbt sich auf die jeweils zur DMARC-Domain gehörenden Subdomains. Wird er also auf der Haupt-Domain gesetzt, so findet er auf allen darunterliegenden Subdomains Anwendung.

Für den DMARC-Eintrag muss dazu eine Subdomain mit dem Namen _dmarc zu der Domain angelegt werden, für welche letztendlich DMARC Anwendung finden soll. Der von Optimizely empfohlene Eintrag lautet wie folgt:

  • Beispieldomain. example.com
  • DMARC-Domain. _dmarc.example.com
  • Record-Typ. TXT
  • DMARC-Record. v=DMARC1; p=reject; rua=mailto:dmarc@example.com;

DMARC-Policies

Einer der wichtigsten Bestandteile des DMARC ist der Policy-Tag. Damit gibt der Domain-Inhaber an, wie ein DMARC-unterstützender ISP mit E-Mails verfahren soll, die sich nicht korrekt mit SPF und DKIM authentifizieren können. Die folgenden drei Policies können gesetzt werden. Optimizely empfiehlt das Setzen der Reject-Policy.

  • p=reject. Weist den Empfänger an, eine E-Mail abzulehnen, die sich nicht mit SPF und DKIM authentifizieren kann.
  • p=quarantine. Weist den Empfänger an, eine E-Mail in den Spamordner zuzustellen, die sich nicht mit SPF und DKIM authentifizieren kann.
  • p=none. Weist den Empfänger an, keine spezielle Policy auf eine E-Mail anzuwenden, die sich nicht mit SPF und DKIM authentifizieren kann.

Mit der Reject-Policy können Sie E-Mails, die ein nicht autorisierter Dritter im Rahmen eines Spam-Angriffs in Ihrem Namen zu senden versucht, vom empfangenden ISP ablehnen lassen.

DMARC-Tags

Die folgende Tabelle gibt einen Überblick über die möglichen DMARC-Tags. In dem von Optimizely empfohlenen DMARC-Eintrag werden dabei nur drei explizit gesetzt.

—Tabelle: DMARC-Tags—
Tag Bedeutung Empfehlung
v Version Die Version muss standardmäßig mit v=DMARC1 gesetzt werden.
p Policy Die DMARC-Policy muss standardmäßig gesetzt werden. Optimizely empfiehlt die stärkste Policy p=reject zu setzen, um Spam-E-Mails von Ihrer Domain ablehnen zu lassen.
sp Subdomain Policy Soll auf Subdomains eine andere DMARC-Policy greifen, so kann diese mit dem sp-Tag angegeben werden, z. B. sp=quarantine. Dieses Setting ist optional.
rua Aggregate Report Optimizely empfiehlt eine Reporting-Adresse für den Erhalt von aggregierten DMARC-Reports anzugeben, z. B. rua=mailto:dmarc@example.com.
ruf (Forensic) Failure Report Optimizely empfiehlt auf die Nutzung von forensischen Reports zu verzichten. Sie beinhalten E-Mail-Adressen von Spam-Empfängern und sind damit möglicherweise nicht DSGVO-konform.
adkim DKIM Alignment Es ist kein separater Tag nötig, somit greift das Default-Setting: adkim=r (Relaxed).
aspf SPF Alignment Es ist kein separater Tag nötig, somit greift das Default-Setting: aspf=r (Relaxed).
rf Reporting Format Es ist kein separater Tag nötig, somit greift das Default-Setting: rf=afrf.
ri Report Interval Es ist kein separater Tag nötig, somit greift das Default-Setting: ri=86400 (1 Tag).
pct Percentage Es ist kein separater Tag nötig, somit greift das Default-Setting: pct=100.
fo Failure Reporting Options Es ist kein separater Tag nötig, somit greift das Default-Setting: fo=0. Generell bestehen die folgenden Möglichkeiten:
  • fo=0. Es soll ein Report gesendet werden, wenn SPF- und DKIM-Check gleichzeitig fehlschlagen.
  • fo=1. Es soll ein Report gesendet werden, wenn entweder der SPF- oder der DKIM-Check fehlschlägt.
  • fo=d. Es soll ein Report gesendet werden, wenn nur der DKIM-Check fehlschlägt.
  • fo=s. Es soll ein Report gesendet werden, wenn nur der SPF-Check fehlschlägt.

DMARC Identifier Alignment

Die DMARC-Prüfung selbst basiert auf dem sogenannten DMARC Identifier Alignment. Dieses verlangt, dass zumindest eine der Domains, die per SPF und DKIM authentifiziert werden, gleich der sichtbaren Absender-Domain ist.

Im Falle des SPF Alignment muss die technische Domain (RFC5321), auch Returnpath oder Envelope-From genannt, der sichtbaren Absender-Domain (RFC5322), auch From-Domain oder Header-From genannt, entsprechen, und eine der beiden Varianten erfüllen:

  • Relaxed SPF Alignment. Die technische und die sichtbare Domain haben die gleiche Haupt-Domain.
  • Strict SPF Alignment. Die technische und die sichtbare Domain haben die gleiche Subdomain.

Im Falle des DKIM Alignment muss die Domain, welche mit DKIM signiert wird und damit im E-Mail-Header unter dem d= Parameter zu finden ist, der sichtbaren Absender-Domain entsprechen, und eine der beiden Varianten erfüllen:

  • Relaxed DKIM Alignment. Die DKIM-Domain und die sichtbare Domain haben die gleiche Haupt-Domain.
  • Strict DKIM Alignment. Die DKIM-Domain und die sichtbare Domain haben die gleiche Subdomain.

DMARC Identifier Alignment ist bei Ihrem Domain-Setup mit Optimizely Campaign standardmäßig eingerichtet.

DMARC-Reporting

Ein zusätzliches Feature, welches SPF und DKIM nicht bieten, ist die Einrichtung von DMARC-Reports. Mittels diesem Reporting werden Sie benachrichtigt, wenn bei E-Mails, die mit Ihrer Domain versendet werden, Authentifizierungsfehler des SPF und DKIM festgestellt werden und somit ein potenzieller Missbrauch Ihrer Domain stattfindet.

DMARC-Reports können Ihnen helfen zu verstehen, ob und wie stark Domain-Missbrauch vorliegt. Spam-E-Mails, die in Ihrem Namen und mit Ihrer Domain versendet werden, wirken sich letztendlich auch negativ auf Ihre Sender Reputation und Zustellungs-Performance aus. Zudem können die gelieferten Informationen Ihnen Aufschluss über die Herkunft von Spam-Attacken geben und Ihnen dabei helfen, diese zu bekämpfen.

Optimizely empfiehlt die Einrichtung von sogenannten aggregierten Reports.

—Bild: DMARC-Report—

Bild: DMARC-Report

Quelle: DMARC.org

Der Report enthält im Bereich <report_metadata> allgemeine Informationen zum Versender sowie zum Betrachtungszeitraum. Weiterhin werden im Bereich <policy_published> die DMARC-Policy sowie weitere verwendete Tags wie z. B. Domain Alignment oder DMARC-Percentage dargestellt. Der letzte und wichtigste Abschnitt <record> beinhaltet die Versand-IP und -Domain, welche einen SPF und/oder DKIM-Fehler hervorgerufen haben. <dkim>fail</dkim> gibt dabei an, dass die Domain-Signatur nicht verifiziert werden konnte, <spf>fail</spf> hingegen weist darauf hin, dass die Versand-IP nicht im SPF-Eintrag der Versand-Domain enthalten war.

Neben dem aggregierten Report existiert auch ein zweites Reporting-Format, der forensische Report. Dieser enthält jedoch personenbezogene Daten von unabhängigen Empfängern und wird daher, u. a. vom eco – Verband der Internetwirtschaft e. V., als nicht DSGVO-konform eingestuft und ist daher nicht empfohlen.

DMARC implementieren

Um DMARC zu implementieren, führen Sie die folgenden Schritte aus:

  1. Domain auswählen
  2. Domain überprüfen
  3. E-Mail-Adresse auswählen
  4. DMARC-Eintrag einrichten
  5. Ergebnisse analysieren

Domain auswählen

Wählen Sie die Domain aus, auf der Sie DMARC implementieren möchten. Dabei haben Sie zwei Möglichkeiten:

  • Wählen Sie eine Domain aus, die ausschließlich zum Versand mit Optimizely benutzt wird. Dies ist im Regelfall eine Subdomain.
  • Wählen Sie die Haupt-Domain aus. Diese Domain kann die bei Optimizely aufgesetzte Versand-Domain sein oder auch nicht.

Damit DMARC für Ihre Versendungen und Zustellbarkeit sinnvoll ist, muss dieser zumindest für die bei Optimizely genutzte Versand-Domain gesetzt werden. Empfohlen ist jedoch die Einrichtung von DMARC auf Ihrer Haupt-Domain, um die gesamte Domain und Marke zu schützen.

DMARC wird auf alle Subdomains der DMARC-Domain vererbt.

Domain überprüfen

Wenn Sie eine Domain verwenden, die zum Versand mit Optimizely genutzt wird, werden Domain Alignment sowie beide Authentifizierungsmechanismen SPF und DKIM beim Domain-Setup eingerichtet. Prüfen Sie, ob Domain Alignment, SPF und DKIM korrekt implementiert sind.

  • Senden Sie Test-E-Mails und prüfen Sie im E-Mail-Header, ob Ihre Versand-Domain der Returnpath-Domain oder der DKIM-Domain, aufgeführt unter dem d= Header, zumindest auf Ebene der Haupt-Domain, entspricht.
  • Prüfen Sie zudem im E-Mail-Header, ob diese sich per SPF und DKIM authentifizieren können. Finden Sie in Ihrem Campaign-Account keinen Warnhinweis auf ein fehlerhaftes DNS-Setup, sind die E-Mails höchstwahrscheinlich korrekt authentifiziert.

Für die Implementierung von DMARC auf der Haupt-Domain müssen eventuelle weitere Mailstreams wie E-Mails über Ihre eigene Infrastruktur oder andere E-Mail-Service Provider berücksichtigt werden und Domain Alignment, SPF und DKIM anwenden. Andernfalls kann DMARC zum ungewollten Blocking dieser E-Mails führen.

Reporting-Adresse auswählen

Um DMARC-Reports zu erhalten, müssen Sie eine E-Mail-Adresse festlegen. Die Reporting-Adresse sollte ebenfalls dieselbe Haupt-Domain enthalten, wie die Domain, für welche DMARC gesetzt wird. Da Sie möglicherweise viele Reports erhalten werden, macht es Sinn, ein eigenes Postfach dafür anzulegen.

Möchten Sie eine andere als Ihre Versand-Domain oder deren Haupt-Domain verwenden, so ist dies mit einer zusätzlichen DNS-Konfiguration möglich.

Beispiel: Ihre Versand- bzw. Haupt-Domain lautet example.com, jedoch möchten Sie Ihre DMARC-Reports an eine E-Mail-Adresse mit der Domain otherdomain.com schicken. Die Reporting-Domain otherdomain.com muss nun erst für den Erhalt von DMARC-Reports authorisiert werden, da andernfalls Missbrauch mit dieser Adresse betrieben werden könnte.

Legen Sie dafür ein zusätzliches Domain-Konstrukt nach folgendem Beispiel für die Authorisierungsprüfung an: example.com._report._dmarc.otherdomain.com

Und setzen Sie folgenden DNS-Record auf die externe Reporting-Domain:

  • Reporting Domain: otherdomain.com
  • Record-Typ. TXT
  • DMARC-Record. v=DMARC1;

Nun können Ihre DMARC-Reports an die angegebene Reporting-Adresse versendet werden.

Sollten Sie ein offizielles Tool zur DMARC-Analyse nutzen wollen, wird Ihnen häufig eine E-Mail-Adresse vorgegeben.

DMARC-Eintrag einrichten

Für den DMARC-Eintrag muss ein TXT-Record mit dem Präfix _dmarc zu der Domain angelegt werden, für welche DMARC Anwendung finden soll. Der von Optimizely empfohlene Eintrag lautet wie folgt:

  • Beispieldomain. example.com
  • DMARC-Domain. _dmarc.example.com
  • Record-Typ. TXT
  • DMARC-Record. v=DMARC1; p=reject; rua=mailto:dmarc@example.com;

Senden Sie Test-E-Mails und prüfen Sie im E-Mail-Header, ob diese sich per SPF, DKIM und DMARC authentifizieren können. Dies ist in einem Gmail-Header besonders gut sichtbar.

Ergebnisse analysieren

Sollte Ihre Domain für den Versand von Spam-E-Mails missbraucht werden, werden Sie DMARC-Reports an Ihre festgelegte Reporting E-Mail-Adresse erhalten. Idealerweise können Sie dadurch Rückschlüsse auf Ihre aktuelle Zustellbarkeits-Situation ziehen. Gleichzeitig bekommen Sie Gewissheit, wie viele potenzielle Spam-E-Mais von Ihrer Domain geblockt wurden und den Empfänger nie erreicht haben.

Zudem können folgende oder ähnliche Tools zur Analyse und Visualisierung benutzt werden:

Möglicherweise fallen zur Nutzung dieser Kosten an. Die Nutzung des DMARC selbst ist kostenlos.

Optionen zur stufenweisen Einführung

Optimizely empfiehlt, die vollständige Anwendung der Reject-Policy als Ziel zu setzen.

Sollten Sie unsicher sein, ob alle Ihre Mailstreams von Ihrer DMARC-Domain bereits mit SPF und DKIM authentifiziert sind, oder ob Sie eventuell weitere legitime E-Mails ohne Authentifizierung versenden, können Sie mit einer Testphase arbeiten und erst einmal Ihre Reports auswerten. Ist eine stufenweise Einführung geplant, kann das wie folgt umgesetzt werden:

  • Policy-Ebene. Hierbei kann mit der None-Policy gestartet werden, welche dann im nächsten Schritt auf eine Quarantine-Policy ausgeweitet wird, und letztendlich auf eine Reject-Policy angepasst wird.
  • Percentage-Ebene. Hierbei kann man bereits mit einer Reject-Policy starten, diese aber zu Beginn auf eine begrenzte Prozentzahl des Versandvolumens anwenden, z. B. 10 %, und diese langsam steigern.

Weitere Informationen finden Sie auf DMARC.org.