Spam-Abwehr : DMARC in der Praxis : Fünf Must-haves für einen wirksamen E‑Mail-Schutz
DMARC ist der entscheidende Standard für eine sichere E‑Mail-Infrastruktur und den Schutz vor Angriffen wie Phishing, Spoofing oder CEO-Fraud. Allerdings kann nur ein vollständiges und korrektes DMARC-Setup seine volle Wirkung entfalten – dieser Beitrag stellt die fünf wichtigsten Schritte dafür vor.
Domain-based Message-Authentication, -Reporting and -Conformance (DMARC, siehe [1] sowie dmarc. org) hat sich in den vergangenen Jahren zu einem entscheidenden Standard entwickelt, um E‑Mail-Domains vor Missbrauch zu schützen. Angriffe wie Phishing, Spoofing und CEO-Fraud sind längst kein Randphänomen mehr – sie gehören zu den häufigsten Einfallstoren für Cyberkriminelle. Cyberkriminelle setzen dafür gezielt auf nicht oder nur unzureichend geschützte Domains.
Angreifer* scannen das Internet kontinuierlich nach Domains ohne DMARC-Policy oder mit schwachen Einstellungen wie p=none. Derart ungeschützte Absenderadressen eignen sich perfekt für den Versand großer Mengen an Spam-, Phishing- oder Malware-Mails, da der Missbrauch oft lange unentdeckt bleibt. Die Folgen reichen von massivem Reputationsverlust für Organisationen über blockierte legitime E‑Mails bis hin zu erheblichen Sicherheitsrisiken für Kunden, Partner und Mitarbeiter. Ein sauberes, vollständiges und wirksames DMARC-Setup sollte daher Pflicht für jede Organisation sein und ist zwingend notwendig, um Domains vor dem aufgeführten Missbrauch zu schützen.
Große E‑Mail-Anbieter, Cybersecurity-Organisationen und regulatorische Standards unterstützen nachdrücklich die strengste DMARC-Richtlinie p=reject, bei der nicht-authentifizierte Nachrichten einer Domain zurückzuweisen sind, als ultimatives Ziel für die E‑MailSicherheit. Auch Unternehmen wie Google, Yahoo, Microsoft, Apple und AOL empfehlen diese strikte Policy, um Phishing und Domain-Spoofing wirksam zu verhindern und gleichzeitig die Zustellbarkeit von E‑Mails zu verbessern. Umso überraschender ist es daher, dass viele Organisationen den theoretisch möglichen Schutz durch DMARC nicht vollständig herstellen. Die im Folgenden aufgeführten fünf Schritte verwirklichen einen entsprechenden Schutz:
Schritt 1: SPF und DKIM vollständig implementieren
DMARC funktioniert nicht für sich allein, sondern basiert auf den beiden Authentifizierungsmechanismen „Sender Policy Framework“ (SPF) und „DomainKeys Identified Mail“ (DKIM), deren Wirksamkeit es in der Praxis drastisch steigert. Nur wenn beide Verfahren korrekt eingerichtet und im gesamten E‑Mail-Versandprozess berücksichtigt werden, lässt sich per DMARC zuverlässig prüfen, ob eine Nachricht legitim ist oder nicht.
Das Zusammenspiel arbeitet wie folgt: SPF stellt sicher, dass nur autorisierte Server E‑Mails für eine Domain versenden dürfen – so kann der Empfänger prüfen, ob eine eingehende E‑Mail vom „richtigen“ Server stammt. DKIM versieht jede Nachricht überdies mit einer digitalen Signatur, die Manipulationen unterwegs zuverlässig erkennen lässt. DMARC regelt dann, wie mit Abweichungen umgegangen werden soll.
DMARC kann jedoch erst sicher greifen, wenn SPF und DKIM in allen relevanten Systemen ausgerollt sind: vom eigenen Mailserver über Newsletter-Tools bis hin zu Cloud-Diensten wie Microsoft 365.
Schritt 2: DMARC-Reports empfangen und über ein Dashboard visualisieren
DMARC ist nicht nur ein Schutzmechanismus, sondern auch ein Analysewerkzeug – das „R“ in DMARC steht schließlich für Reporting. Solche Reports werden standardmäßig von E‑Mail-Servern erzeugt, die eine E‑Mail erhalten haben, in der eine DMARC-geschützte Domain in der Absenderadresse verwendet wurde und liefern einem Domaininhaber täglich detaillierte Informationen:
- Wer sendet E‑Mails im Namen ihrer Domain?
- Welche Systeme bestehen die SPF- und DKIMPrüfungen?
- Wo treten Fehler auf?
- Gibt es Auffälligkeiten oder Missbrauchsversuche?
Wie bei allen Sicherheitsdaten gilt: Nur was sichtbar ist, kann auch verbessert werden. Daher ist es entscheidend, dass DMARC-Reports nicht nur irgendwo eingehen, sondern auch über ein Dashboard visualisiert und ausgewertet werden – übersichtlich, filterbar und leicht verständlich. So lassen sich Trends erkennen, Fehlerquellen aufdecken und Risiken frühzeitig identifizieren.
Schritt 3: Automatische Warnungen bei Auffälligkeiten nutzen
Ein gutes DMARC-Setup ist kein „Einmal einstellen und vergessen“-Projekt. Denn die E‑Mail-Landschaft ist dynamisch: Dienstleister ändern ihre IPs, neue Newsletter-Systeme kommen hinzu, SPF-Records werden zu lang oder enthalten Syntaxfehler oder DKIM-Keys laufen ab – all das kann zu Authentifizierungsfehlern führen.
Deshalb sollte ein modernes DMARC-Dashboard automatische Warnungen erzeugen, etwa bei:
- Veränderungen an DNS-Einträgen,
- Syntax-Fehlern in DNS-Records,
- plötzlichem Anstieg von SPF- oder DKIM-Fehlern,
- neuen, unbekannten Absenderquellen sowie
- potenziellem Domainmissbrauch.
Diese Warnungen ermöglichen schnelle Reaktionen, bevor die Probleme Nutzer oder Kunden betreffen.
Schritt 4: DMARC-Policy final auf p=reject setzen
DMARC bietet drei mögliche Policy-Einstellungen, wie empfangende E‑Mail-Server Nachrichten der betroffenen Domain behandeln sollen, die SPF- und DKIM-Prüfungen nicht bestehen. Letztlich steuern diese auch den Schutzlevel vor Phishing und Spoofing:
- p=none (Monitoring): E‑Mails werden in dieser Einstellung trotz Fehlern normal zugestellt. Dieser Modus dient in der Regel zum Einstieg, um DMARC-Berichte über die E‑Mail-Landschaft zu erhalten, ohne legitime E‑Mails zu blockieren.
- p=quarantine (Quarantäne): Nicht-authentifizierte E‑Mails werden in diesem Level als Spam markiert oder in den Spam-/Junk-Ordner verschoben. Dieser Modus bietet somit eine erste Sicherheitsstufe, die E‑Mails mit fehlgeschlagener Absenderprüfung aber nicht löscht, sondern isoliert, sodass der Empfänger diese noch prüfen kann.
- p=reject (Ablehnung): Erst in der striktesten Stufe werden E‑Mails, deren Authentifizierungsprüfung fehlschlägt, direkt vom empfangenden Server abgelehnt und nicht zugestellt. Dieser Modus bietet den höchsten Schutzlevel mit maximalem Schutz vor Phishing, da fehlerhafte E‑Mails (Spoofing) direkt blockiert werden.
Es wird generell empfohlen, schrittweise mit p=none zu beginnen, zu p=quarantine überzugehen und schließlich zu p=reject zu wechseln, sobald alle legitimen E‑Mail-Quellen validiert sind. Denn auch Quarantäne-Ordner verlagern Probleme schließlich nur an einen anderen Ort, lösen sie aber nicht. Aus rechtlichen und sicherheitstechnischen Erwägungen sollten sie daher abgeschafft, der Modus p=quarantine also entweder übersprungen oder zumindest nur kurz genutzt werden. DMARC entfaltet seine volle Schutzkraft erst dann, wenn die Policy auf p=reject steht, denn nur dann weist der empfangende Server gefälschte oder nicht authentifizierte E‑Mails konsequent ab.
Viele Organisationen verharren allerdings zu lange bei p=none oder p=quarantine, weil sie Angst vor Fehlkonfigurationen haben. Doch wenn die oben genannten ersten drei Schritte sauber etabliert sind und der Versand stabil läuft, gibt es keinen Grund mehr zu warten: Man sollte dann also schnellstmöglich die DMARC-Policy auf p=reject setzen – und Spoofing der eigenen Domain beziehungsweise E‑Mail-Adressen wirksam beenden.
Schritt 5: DMARC-Einträge auch für inaktive Domains setzen
Viele Organisationen haben eine Vielzahl von „toten“ oder ungenutzten Domains, die keinen aktiven Inhalt aufweisen, „geparkt“ sind oder deren Registrierung abgelaufen ist (Expired Domains). Sie dienen häufig als Platzhalter, zum Markenschutz oder werden nach Nichtverlängerung zur Neuregistrierung freigegeben. Doch auch wenn eine Domain selbst keine E‑Mails versendet, ist sie nicht vor Missbrauch geschützt: Angreifer nutzen tote oder ungenutzte Domains sogar besonders gern, weil deren Logs selten überprüft werden.
Zu einem sicheren Setup gehört daher auch, dass wirklich jede eigene Domain einen DMARC-Record enthält und bei ungenutzten Domains dieser Record über p=reject und sp=reject sämtliche Mails vollständig abweist. Nur so wird sichergestellt, dass eine Marke nicht über vergessene Domains für Angriffe missbraucht werden kann.
Der DMARC-Subdomain-Policy-Tag sp=reject weist dabei empfangende E‑Mail-Server an, E‑Mails von Subdomains einer Domain, die den SPF- oder DKIMCheck nicht bestehen, vollständig abzulehnen. So lassen sich auch Spoofing-Versuche über Subdomains blockieren, ohne die Hauptdomain-Richtlinie – gesetzt mit dem Tag p – zu beeinflussen. Wenn sp nicht gesetzt ist, erben Subdomains die Richtlinie der Hauptdomain.
Fazit
Wer DMARC implementiert, hat einen großen Schritt in Richtung E‑Mail-Sicherheit getan. Doch nur wenn alle fünf Must-haves erfüllt sind, funktioniert der Schutz ganzheitlich:
- SPF und DKIM sind flächendeckend eingerichtet,
- DMARC-Reports sind sichtbar und analysierbar,
- man erhält automatische Warnungen für schnelle Reaktionen,
- Policies stehen auf p=reject und
- auch für nicht genutzte Domains ist ein Schutz eingerichtet.
Unternehmen, die diese Punkte beachten, reduzieren Spoofing-Risiken für eigene E‑Mail-Adressen nahezu auf Null und stärken gleichzeitig das Vertrauen in ihre digitale Kommunikation.
Wichtig ist dabei zu bedenken, dass DMARC nicht nur den Versand, sondern auch den Empfang schützen kann. Die vorgenannten Maßnahmen beziehen sich auf den E‑Mail-Versand und sorgen dafür, dass eigene Domains nicht für Spoofing missbraucht werden können. Mindestens genauso wichtig ist jedoch die andere Seite: die konsequente DMARC-Bewertung eingehender E‑Mails. Denn nur, wenn auch die eigenen empfangenden Systeme alle DMARC-Informationen auswerten und entsprechend handeln, können Organisationen sich wirksam vor Spoofing, Phishing und manipulierten Absendern mit externen Adressen schützen.
Ein vollständiger Schutz entsteht also erst durch die Kombination aus korrekt konfigurierten DMARC-Einstellungen für ausgehende E‑Mails und einer konsequenten DMARC-Prüfung für eingehende E‑Mails. Das Ergebnis ist ein durchgängiges Sicherheitsmodell, das Absenderidentitäten zuverlässig absichert – in beide Richtungen.
Stefan Cink ist Director Business and Professional Services bei NoSpamProxy | Net at Work.
Literatur
[1] Murray Kucherawy, Elizabeth Zwicky (Hrsg.), Domain-based Message Authentication, Reporting, and Conformance (DMARC), Request for Comments (RFC) 7489, März 2015, https://datatracker.ietf.org/doc/html/rfc7489

