DMARC einrichten
Wie funktioniert DMARC (Domain-based Message Authentication, Reporting and Conformance)?
Um DMARC zu aktivieren, hinterlegen Sie eine DMARC-Richtlinie in der DNS-Zone Ihrer Domäne. Wie bei SPF und DKIM auch wird die DMARC-Richtlinie in einem RFC-normierten TXT-Eintrag - kurz DMARC-Eintrag - gespeichert.
Die Richtlinie beinhaltet Information dazu, welche Prüfungen vom Empfänger gemacht werden müssen – also SPF und/oder DKIM. Zusätzlich legt sie fest, was der Empfänger tun soll, wenn die Prüfungen fehlschlagen: trotzdem annehmen, in Quarantäne legen oder abweisen.
Des Weiteren werden in der DMARC-Richtlinie E-Mail-Adressen hinterlegt, an die Berichte geschickt werden sollen – das R in DMARC steht für Reporting. Diese Berichte werden von allen Servern im Internet erstellt, die DMARC beim E-Mail-Empfang unterstützen und E-Mails von der jeweiligen Domain erhalten haben. Um zu verhindern, dass die durch die Berichte erzeugte Menge an Daten zu groß wird, kann in der DMARC-Richtlinie außerdem der Prozentsatz an E-Mails bestimmt werden, für die ein Bericht generiert wird. Des Weiteren werden die Berichte gesammelt und standardmäßig nur einmal am Tag an die jeweilige Reporting-Adresse geschickt.
Wie sieht ein DMARC-Eintrag aus?
Der für eine DMARC-Policy eingesetzte TXT-Eintrag kann die folgenden Felder enthalten:
|
Feld |
Bedeutung |
Beispiele |
|---|---|---|
|
v |
Version des DMARC-Eintrags |
v=DMARC1 |
|
p |
Policy, wie E-Mails der Hauptdomäne behandelt werden sollen, deren Authentifizierung fehlschlägt |
p=none: nichts unternehmen p=quarantine: in Quarantäne legen p=reject: abweisen |
|
sp |
Policy, wie E-Mails der Subdomäne behandelt werden sollen, deren Authentifizierung fehlschlägt |
p=none: nichts unternehmen p=quarantine: in Quarantäne legen p=reject: abweisen |
|
pct |
Prozentsatz an E-Mails, die gemäß der DMARC-Richtlinie reportet werden sollen |
pct=100 (Standard) |
|
rua |
Legt fest, ob und an welche E-Mail-Adresse ein summarischer Bericht („aggregated report“) über die empfangenen E-Mails gesendet werden soll. |
rua=mailto:report@example.com |
|
ruf |
Legt fest, ob und an welche E-Mail-Adresse ein forensischer Bericht über die empfangenen E-Mails gesendet werden soll. Dieser enthält alle Details zu den jeweiligen E-Mails. Datenschutz beachten! |
ruf=mailto:report@example.com |
|
fo |
Failure Reporting Options. Detaileinstellung, wann E-Mails gemeldet werden sollen. Gilt nur in Verbindung mit “ruf”. |
fo=0: SPF und DKIM sind fehlgeschlagen (Standard) fo=1: SPF oder DKIM sind fehlgeschlagen fo=d: DKIM gilt als fehlgeschlagen, wenn die Signatur nicht stimmt – auch dann, wenn der Schlüssel übereinstimmt. fo=s: SPF gilt als fehlgeschlagen, wenn die SPF-Evaluation aus irgendeinem Grund scheitert, auch dann, wenn die SPF-Einträge in Kopfzeile und DNS-Eintrag übereinstimmen. |
|
rf |
Reporting Format. Das Dateiformat für die Berichte. Gilt nur in Verbindung mit “ruf”. |
rf=afrf: Authentication Failure Reporting Format (Standard) rf=iodef: Incident Object Description Exchange Format |
|
ri |
Reporting Interval. Häufigkeit in Sekunden, in der Berichte gesendet werden. |
ri=86400, also einmal täglich (Standard) |
|
aspf |
Abgleichmodus für die Prüfung von SPF |
s=strict, also streng. Die ‘MAIL FROM’-Adresse muss exakt mit der Header-From-Adresse übereinstimmen. Beispiel: info@example.com r=relaxed, also locker. Es darf sich auch um eine Subdomäne handeln. Beispiel: info@newsletter.example.com Weitere Informationen finden Sie bei mxtoolbox. |
|
adkim |
Abgleichmodus für die Prüfung von DKIM |
s.o. |
Beispiele für DMARC-Einträge
Beispiel 1
v=DMARC1; p=reject; fo=0; rua=mailto:dmarc-reports@example.com, mailto:dmarc@example.com
Hier werden alle nicht-authentifizierten E-Mails abgewiesen, wenn SPF- und DKIM-Prüfungen fehlgeschlagen sind (fo=0). Außerdem werden summarische Berichte an die angegebenen Adressen geschickt.
Beispiel 2
v=DMARC1; p=none; sp=quarantine; rua=mailto:reports@example.com
Bei nicht-authentifizierten E-Mails an die Hauptdomäne wird hier nichts unternommen, nicht-authentifizierte E-Mails an die Subdomäne werden in Quarantäne gelegt. Da fo=0 die Standardeinstellung ist, gelten diese Regelungen, wenn SPF- und DKIM-Prüfungen fehlgeschlagen sind – auch wenn es nicht explizit angegeben ist.
WARNING: Wir raten dringend davon ab, dauerhaft die Policy p=none einzusetzen. Siehe DMARC Policy: Warum p=none keine gute Idee ist (Blogartikel)
Best Practices für Einführung von DMARC
Wir empfehlen, die Implementierung von DMARC in mehreren Schritten vorzunehmen. Fangen Sie bei einer reinen Überwachung Ihrer Domäne an und erweitern Sie die Richtlinie nach und nach bis zum Abweisen aller E-Mails, die die DMARC-Prüfung nicht bestehen (p=reject).
Überwachen
Beginnen Sie mit einer reinen Überwachung einer Unterdomäne und/oder Hauptdomäne und fordern Sie die regelmäßigen Berichte an. Für diesen Schritt ist die Nutzung von SPF und DKIM noch nicht erforderlich. Der entsprechende DMARC-Eintrag könnte folgendermaßen aussehen:
v=DMARC1; p=none; sp=none; rua=mailto:report@example.com
Quarantänerichtlinie einrichten
Bevor Sie diesen Schritt durchführen, müssen Sie SPF und DKIM vollständig implementiert haben. Haben Sie dies erledigt, implementieren Sie eine DMARC-Quarantänerichtlinie. Diese weist empfangende Server an, E-Mails von Ihrer Domäne, die die DMARC-Prüfung nicht bestehen, in den Spam-Ordner zu legen. Der entsprechende DMARC-Eintrag könnte folgendermaßen aussehen:
v=DMARC1; p=quarantine; sp=quarantine; rua=mailto:report@example.com
Abweisen aller nicht-authentifizierten E-Mails
Im letzten Schritt weisen Sie empfangende Server an, E-Mails von Ihrer Domäne, die die DMARC-Prüfung nicht bestehen, abzuweisen. Der entsprechende DMARC-Eintrag könnte folgendermaßen aussehen:
v=DMARC1; p=reject; sp=reject; rua=mailto:report@example.com