Sie haben SPF eingerichtet. Sie haben DKIM konfiguriert. Ihre E-Mails sind authentifiziert, und Sie fühlen sich mit Ihrer Sicherheitslage wohl. Dann stellen Sie fest, dass jemand seit Monaten Tausende Phishing-E-Mails von Ihrer Domain verschickt – und keine Ihrer Authentifizierungsmaßnahmen hat etwas bewirkt, weil Sie nie festgelegt haben, was bei Fehlern passieren soll.
Genau diese Lücke schließt DMARC. SPF und DKIM sind Prüfmechanismen – sie können einem empfangenden Server mitteilen, ob eine E-Mail legitim ist. Aber sie definieren nicht, was passieren soll, wenn die Prüfung fehlschlägt. Soll die E-Mail trotzdem zugestellt werden? Quarantiniert? Komplett abgelehnt? Ohne explizite Anweisungen liefern die meisten Server die E-Mail standardmäßig aus, vielleicht mit einem Warnhinweis, den Nutzer ignorieren.
DMARC—Domain-based Message Authentication, Reporting, and Conformance—ist die Policy-Schicht. Es sagt der Welt: 'Hier ist, was ich mit E-Mails möchte, die die Authentifizierung nicht bestehen. Und übrigens: Schickt mir Berichte darüber, was ihr seht.'
Die drei DMARC-Richtlinien
DMARC-Policies werden mit dem 'p=' Tag in Ihrem DMARC-Record festgelegt. Es gibt drei Optionen, und die richtige Wahl hängt davon ab, wo Sie sich auf Ihrer E-Mail-Authentifizierungsreise befinden.
'p=none' ist der Monitoring-Modus. Es sagt empfangenden Servern: 'Unternimmt bei Fehlern nichts Besonderes, aber schickt mir Berichte darüber, was ihr seht.' Hier sollte jeder starten. Sie erhalten Sichtbarkeit in Ihr E-Mail-Ökosystem, ohne das Risiko, dass legitime E-Mails blockiert werden.
'p=quarantine' ist der Mittelweg. Es sagt Servern: 'Wenn die Authentifizierung fehlschlägt, behandelt die E-Mail als verdächtig.' In der Praxis bedeutet das meist, dass die E-Mail im Spam- oder Junk-Ordner landet. Nutzer können sie bei Bedarf finden, aber sie ist nicht im Posteingang.
'p=reject' ist die vollständige Durchsetzung. Es sagt Servern: 'Wenn die Authentifizierung fehlschlägt, liefert die E-Mail gar nicht aus.' Das ist das Ziel – vollständiger Schutz vor Domain-Spoofing. Es ist aber auch am gefährlichsten, wenn Ihre Authentifizierung nicht korrekt konfiguriert ist, denn dann werden legitime E-Mails blockiert.
Der Weg von 'none' zu 'reject' dauert typischerweise Wochen oder Monate. Sie starten mit Monitoring, analysieren die Berichte, um alle legitimen E-Mail-Quellen zu finden, stellen sicher, dass diese korrekt authentifiziert sind, und erhöhen dann nach und nach die Durchsetzung. Zu schnell auf 'reject' zu wechseln, bevor Sie bereit sind, ist eine sichere Methode, Ihre E-Mail zu beschädigen.
DMARC Alignment verstehen
Hier wird DMARC subtil – und viele Leute sind genau hier verwirrt. DMARC prüft nicht nur, ob SPF und DKIM bestehen – es prüft, ob sie mit der sichtbaren From‑Adresse 'alignen'.
Stellen Sie sich dieses Szenario vor: Ein Angreifer sendet eine E-Mail mit einer From‑Adresse von [email protected]. Er verschickt sie über seinen eigenen Server, der gültiges SPF für attackerdomain.com hat. Die E-Mail besteht SPF – aber für die falsche Domain. Ohne Alignment-Prüfung würde dieser Angriff erfolgreich sein.
DMARC Alignment verlangt, dass die durch SPF oder DKIM authentifizierte Domain mit der Domain im From‑Header übereinstimmt. 'Übereinstimmen' kann entweder eine exakte Übereinstimmung (strict alignment) oder eine Übereinstimmung auf Ebene der Organisationsdomain (relaxed alignment) bedeuten.
Bei relaxed alignment (Standard) alignen mail.yourcompany.com und yourcompany.com. Bei strict alignment nicht – nur exakte Übereinstimmungen zählen. Die meisten Organisationen verwenden relaxed alignment, weil es praktischer ist, insbesondere wenn Sie Subdomains für verschiedene E-Mail-Ströme nutzen.
Damit DMARC besteht, muss entweder SPF bestehen UND alignen oder DKIM bestehen UND alignen (oder beides). Deshalb ist es wichtig, sowohl SPF als auch DKIM konfiguriert zu haben – wenn eines fehlschlägt (z. B. SPF aufgrund von Weiterleitung), kann das andere immer noch ein bestandenes Ergebnis liefern.
DMARC-Berichte: Ihr Fenster in den E-Mail‑Missbrauch
Die Reporting-Funktion von DMARC ist arguably genauso wertvoll wie die Policy-Durchsetzung. Wenn Sie einen DMARC-Record mit einem 'rua=' Tag veröffentlichen, senden Ihnen empfangende Server aggregierte Berichte über E-Mails, die sie gesehen haben und die vorgeben, von Ihrer Domain zu stammen.
Diese Berichte sind (meist) tägliche XML-Dateien. Sie enthalten Daten zu E-Mail-Volumen, Authentifizierungsergebnissen und Versandquellen. Für jede Quell-IP sehen Sie, wie viele E-Mails gesendet wurden, ob SPF und DKIM bestanden haben und welche Policy angewendet wurde.
Beim ersten Blick in DMARC-Berichte werden Sie wahrscheinlich überrascht sein. Sie sehen E-Mails aus Quellen, die Sie vergessen haben – das alte Marketing-Tool, das Sie nicht mehr nutzen, aber nie ausgemustert haben, das Abrechnungssystem, das Quittungen sendet, der Monitoring-Service, der Alarme verschickt. Sie werden wahrscheinlich auch unautorisierte Quellen sehen: Spammer, Phisher oder einfach fehlkonfigurierte Systeme, die irgendwie als Ihre Domain senden.
Rohe DMARC-Berichte sind schwer zu lesen. Die meisten Organisationen nutzen einen DMARC-Analyse-Dienst (es gibt kostenlose und kostenpflichtige Optionen), der Berichte aggregiert, die Daten visualisiert und Sie auf Probleme hinweist. Das ist dringend zu empfehlen – XML-Berichte manuell zu parsen, skaliert nicht.
Es gibt auch 'ruf=' für forensische Berichte, die detaillierte Informationen zu einzelnen fehlerhaften E-Mails senden. Diese sind stärker datenschutzsensitiv (sie können E-Mail-Inhalte enthalten) und viele Empfänger senden sie nicht, dennoch können sie bei der Untersuchung konkreter Vorfälle nützlich sein.
Der Weg zur Durchsetzung
Der Wechsel von p=none zu p=reject ist ein Prozess, kein Ereignis. So läuft es in der Praxis typischerweise ab.
Sie beginnen mit der Veröffentlichung eines DMARC-Records mit p=none und einer rua-Adresse für Berichte. Perfektes SPF und DKIM brauchen Sie an diesem Punkt nicht – Sie sammeln zunächst Daten. Warten Sie mindestens zwei Wochen, besser einen Monat, um genug Berichte zu sammeln und das Gesamtbild zu sehen.
Analysieren Sie die Berichte. Identifizieren Sie jede legitime Quelle von E-Mails für Ihre Domain. Verifizieren Sie für jede Quelle, dass SPF und DKIM korrekt konfiguriert sind. Hier entdecken Sie häufig vergessene Dienste oder Fehlkonfigurationen. Beheben Sie diese.
Sobald Ihre legitimen Quellen die Authentifizierung konsistent bestehen, wechseln Sie zu p=quarantine. Gehen Sie aber nicht sofort auf Vollgas – nutzen Sie das 'pct=' Tag, um die Policy nur auf einen Prozentsatz der fehlerhaften E-Mails anzuwenden. Starten Sie mit pct=10, d. h. 10% der Fehler werden quarantiniert, während 90% weiterhin normal zugestellt werden.
Überwachen Sie die Berichte. Wenn Sie sehen, dass legitime E-Mails quarantiniert werden, untersuchen und beheben Sie die Ursache. Wenn alles gut aussieht, erhöhen Sie den Prozentsatz schrittweise: 25%, 50%, 75%, 100%.
Wenn Sie bei p=quarantine mit pct=100 angekommen sind und alles stabil ist, wiederholen Sie den Prozess für p=reject. Auch hier starten Sie mit einem niedrigen Prozentsatz und erhöhen schrittweise. Wenn Sie p=reject mit pct=100 erreichen (oder ohne pct Tag, was standardmäßig 100% bedeutet), haben Sie volle DMARC-Durchsetzung.
Dieser Prozess dauert typischerweise 2–6 Monate, abhängig von der Komplexität Ihres E-Mail-Ökosystems. Zu hastig vorzugehen, riskiert, legitime E-Mails zu blockieren. Zu langsam zu sein, lässt Sie anfällig für Spoofing. Finden Sie das richtige Tempo für Ihre Organisation.
Häufige DMARC-Fehler
Der häufigste Fehler ist, direkt auf p=reject zu springen, ohne vorher zu monitoren. Sie werden etwas kaputt machen. Vielleicht ist es das HR‑System, das Angebotsbriefe versendet, das Finanz‑Tool, das Rechnungen verschickt, oder die Legacy‑Anwendung, an die sich niemand mehr erinnert. Beginnen Sie immer mit p=none.
Ein weiterer häufiger Fehler ist, DMARC einzurichten, aber nie in die Berichte zu schauen. Die Berichte sind der eigentliche Zweck der Monitoring-Phase. Wenn Sie sie nicht analysieren, fliegen Sie blind. Richten Sie ein DMARC-Analyse-Tool ein und prüfen Sie die Daten wirklich.
Viele Organisationen stolpern über Subdomains. Standardmäßig gilt die DMARC-Policy nur für die exakte Domain, nicht für Subdomains. Wenn Sie marketing.yourcompany.com schützen wollen, benötigen Sie entweder einen separaten DMARC-Record für diese Subdomain oder ein 'sp=' Tag in Ihrem Haupt-Record, das die Subdomain-Policy festlegt.
Fehlkonfigurationen bei Drittanbieter-Diensten sind weit verbreitet. Wenn Sie einen neuen E-Mail-Dienst hinzufügen, müssen Sie sowohl SPF aktualisieren (um deren Server zu autorisieren) als auch sicherstellen, dass sie mit DKIM auf Ihrer Domain signieren (nicht mit ihrer Standard-Domain). Viele Dienste erfordern eine explizite Konfiguration, um das DKIM Ihrer Domain zu verwenden.
Schließlich führt die Behandlung von DMARC als 'einrichten und vergessen' zu Problemen. Ihr E-Mail-Ökosystem verändert sich im Laufe der Zeit. Neue Dienste kommen hinzu, alte werden entfernt, Konfigurationen driften. Prüfen Sie Ihre DMARC-Berichte regelmäßig, auch nach Erreichen der vollständigen Durchsetzung.
Frequently asked questions
Kann ich DMARC ohne SPF oder DKIM nutzen?
Technisch ja, aber es ist sinnlos. Die DMARC-Policy basiert auf den Ergebnissen von SPF und DKIM. Ohne mindestens eines davon konfiguriert, wird jede E-Mail an DMARC scheitern. Sie benötigen SPF, DKIM oder beides, damit DMARC sinnvoll ist.
Was ist der Unterschied zwischen rua- und ruf-Berichten?
rua (Aggregat-)Berichte sind tägliche Zusammenfassungen der Authentifizierungsergebnisse – Volumina und Pass/Fail-Raten nach Quelle. ruf (forensische) Berichte enthalten detaillierte Informationen zu einzelnen fehlerhaften E-Mails. Die meisten Organisationen nutzen nur rua; ruf-Berichte werden seltener gesendet und werfen Datenschutzfragen auf.
Wie lange sollte ich bei p=none bleiben, bevor ich zu quarantine wechsle?
Mindestens 2–4 Wochen, länger, wenn Sie ein komplexes E-Mail-Ökosystem haben. Sie benötigen genug Daten, um alle legitimen E-Mail-Quellen zu identifizieren und zu verifizieren, dass sie korrekt authentifiziert sind. Diese Phase zu überstürzen ist die häufigste Ursache für DMARC-bezogene E-Mail-Probleme.
Stoppt DMARC sämtliches Phishing?
Nein. DMARC verhindert exaktes Domain-Spoofing (jemand sendet als @yourcompany.com), stoppt aber keine Lookalike-Domains (yourcompany-secure.com) oder Display-Name-Spoofing ('Ihr Unternehmen `<[email protected]>`'). Es ist eine wichtige Schicht, aber keine vollständige Anti-Phishing-Lösung.