DMARC Policy: Warum p=none keine gute Idee ist
Bei der Absicherung von E-Mail-Domains gegen Missbrauch spielt DMARC (Domain-based Message Authentication, Reporting, and Conformance) eine zentrale Rolle. Doch die korrekte Konfiguration einer DMARC Policy ist entscheidend: Eine scheinbar harmlose Einstellung wie „p=none“ kann zu erheblichen Sicherheitsrisiken führen. In diesem Artikel erläutern wir, warum „p=none“ keine gute Wahl ist und wie ein effektiver DMARC Record aussehen sollte.
DMARC (Domain-based Message Authentication, Reporting, and Conformance) ist ein offizieller IETF- Standard. Er wurde entwickelt, um E-Mail-Domains vor Missbrauch, insbesondere vor Spoofing und Phishing, zu schützen. Es ergänzt und erweitert die bestehenden Authentifizierungsmechanismen Sender Policy Framework (SPF) und DomainKeys Identified Mail (DKIM) um Richtlinien für die E-Mail-Verarbeitung und Reporting-Funktionen.
DMARC ermöglicht es dem Absender einer E-Mail, zusätzliche Informationen über die Verarbeitung der gesendeten E-Mail mitzuteilen. Er teilt dem Empfänger mit
- wie von ihm gesendete E-Mails authentifiziert werden sollen,
- was mit nicht authentifizierten E-Mails geschehen soll und
- an wen und wie oft Berichte an den Absender zurückgeschickt werden sollen.
SPF, DKIM und DMARC – wie hängen sie zusammen?
Mit SPF und DKIM kann die Authentizität und Integrität von E-Mails sichergestellt werden. Allerdings geben weder SPF noch DKIM dem empfangenden Server klare Anweisungen, was mit E-Mails geschehen soll, die die SPF- und DKIM-Prüfungen nicht bestanden haben. Diese Lücke wird durch DMARC (Domain-based Message Authentication, Reporting and Conformance) geschlossen – vorausgesetzt, Sie haben im entsprechenden DMARC Record die richtigen Einstellungen vorgenommen.
Wie sieht ein DMARC Record 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 Policy 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. |
p=none ist schlimmer als gar keine DMARC Policy
Entscheidend bei diesen Beispielen sind die unterschiedlichen Einstellungen für das Feld p.
Während im ersten Beispiel alle nicht authentifizierten E-Mails abgewiesen werden, wird bei nicht authentifizierten E-Mails an die Hauptdomäne nichts unternommen – was bedeutet, dass jeglicher Schutz, den SPF und DKIM bieten, verloren geht.
Das ist nicht nur problematisch, sondern geradezu fahrlässig: Versender von Spam-, Phishing- und Malware-Mails verwenden gezielt Domänen als Absenderadresse, die entweder keine DMARC Policy haben oder p=none einsetzen.
Aber nicht nur das: p=none ist noch problematischer als gar keine DMARC Policy zu haben, denn Gateways wie NoSpamProxy, die sich an die RFCs halten, lehnen E-Mails auch dann nicht ab, wenn die Prüfungen zu SPF und DKIM fehlschlagen – es sei denn, es würde Schadsoftware, Spam oder ähnliches gefunden.
Die Reputation Ihrer Domäne leidet
So können Angreifer weiterhin erfolgreich E-Mails unter Ihrer Domain versenden, was Ihre Domain anfällig für Phishing-Angriffe und Spam macht. Zudem nimmt Ihre Domain-Reputation Schaden, wenn Angreifer Ihre Domain für böswillige Zwecke missbrauchen. Dies kann dazu führen, dass legitime E-Mails von Ihrer Domain häufiger im Spam-Ordner landen oder blockiert werden.
Wozu eigentlich p=none?
Wenn p=none in einer DMARC Policy gefährlich ist und DMARC faktisch unwirksam macht – warum gibt es diese Einstellung eigentlich?
Die Einstellung p=none kann tatsächlich nützlich sein, beispielsweise in einer Einführungsphase von DMARC. Mittels p=none können Probleme identifiziert werden, ohne E-Mails zu blockieren. Sie erhalten so einen Überblick über die ausgehenden E-Mails, die im Namen Ihrer Domain gesendet werden. Wenn Sie über genügend Informationen in Form von DMARC-Berichten verfügen, können Sie die Konfiguration ändern und die Konformität verbessern, um die Umstellung auf eine strengere DMARC Policy in Ihrem Unternehmen vorzubereiten.
In einer Testphase können so Berichte gesammelt und überprüft werden, ob SPF und DKIM korrekt implementiert sind.
DMARC richtig einführen
Wir empfehlen, DMARC in mehreren Schritten zu implementieren. Beginnen Sie mit einer einfachen Überwachung Ihrer Domäne und erweitern Sie die Policy nach und nach, bis alle E-Mails, die die DMARC-Prüfung nicht bestehen, abgewiesen werden (p=reject).
Schritt 1: Überwachen
Beginnen Sie mit der reinen Überwachung einer Subdomain und/oder einer Hauptdomain und fordern Sie regelmäßige Berichte an. Für diesen Schritt ist die Verwendung von SPF und DKIM noch nicht erforderlich. Der entsprechende DMARC Record könnte wie folgt aussehen:
“v=DMARC1; p=none; sp=none; rua=mailto:report@example.com”.
Achten Sie darauf, p=none am Ende der Überwachung zu entfernen und in Schritt 3 auf p=reject zu ändern.
Schritt 2: Quarantäne-Richtlinie einrichten
Bevor Sie diesen Schritt durchführen, müssen Sie SPF und DKIM vollständig implementiert haben. Sobald dies geschehen ist, richten Sie eine DMARC-Quarantänerichtlinie ein. Diese weist die empfangenden Server an, E-Mails von Ihrer Domain, die die DMARC-Prüfung nicht bestehen, in den Spam-Ordner zu verschieben. Der entsprechende DMARC Record könnte wie folgt aussehen:
“v=DMARC1; p=quarantine; sp=quarantine; rua=mailto:report@example.com”.
Schritt 3: Alle nicht authentifizierten E-Mails zurückweisen
Im letzten Schritt weisen Sie die empfangenden Server an, E-Mails von Ihrer Domain, die die DMARC-Prüfung nicht bestehen, abzuweisen. Der entsprechende DMARC Record könnte wie folgt aussehen:
“v=DMARC1; p=reject; sp=reject; rua=mailto:report@example.com”.
DMARC Record prüfen
Mit Hilfe von Tools wie mxtoolbox können Sie schnell und einfach prüfen, ob für Ihre Domain ein DMARC-Eintrag vorliegt.
DMARC Record einrichten und E-Mail-Sicherheit verbessern
Domänen-Inhaber haben mit Hilfe von DMARC eine verbesserte Kontrolle über die elektronische Kommunikation ihres Unternehmens und verbessern die Sicherheit ihrer IT-Infrastruktur. Erhebungen haben auch gezeigt, dass die Verwendung von Domäne als Absende-Adresse in Spam-Mails deutlich nachlässt, sobald die Domain DMARC-geschützt ist.
Die Nutzung von DMARC als Einflussgröße für die Senderreputation ist ein Meilenstein für die Sicherheit und Effizienz in der E-Mail-Kommunikation. Sie bedeutet gleichzeitig, dass man im Vergleich zu Spam-Versendern nicht ins Hintertreffen gerät, da sich auch dort herumgesprochen hat, welchen Vorteil DMARC-geschützte Domänen bieten. Die Bewertung der Reputation des Absenders ist ein äußerst verlässliches Instrument im Kampf gegen stetig steigende Mengen an Spam und immer perfider werdende Angriffsszenarien mit Malware.
Kostenfreier Praxisratgeber: DMARC, DKIM, SPF und DANE
In unserem kostenfreien Ratgeber geben wir Ihnen eine Schritt-für-Schritt-Anleitung für das Einrichten von SPF, DKIM, DMARC und DANE. Sichern Sie jetzt Ihren E-Mail-Verkehr ab!
