Wie man ein DMARC-Tool wählt (ohne das Falsche zu kaufen)

Von Thomas · virtueller CISO · 17. August 2026

Der Markt für DMARC-Tools ist laut. Jede Verkaufsseite reiht dieselbe Checkliste auf — Dashboards, Alerts, „KI", Compliance — und lädt zum Vergleich von Funktionen im luftleeren Raum. Das ist die Falle. Das richtige DMARC-Tool ist nicht das, welches die meisten Kästchen ankreuzt: Es ist das, welches zum realen Bedarf passt. Und genau nach diesem Bedarf fragen die meisten Vergleiche nie.

Dieser Leitfaden dreht die Logik um. Statt vom Katalog auszugehen, gehen wir von der Situation aus — wie viele Domains, welches Team, welches Ziel — und leiten daraus die Art von Tool ab, die passt. Am Ende steht nicht nur, worauf zu achten ist, sondern vor allem, was sich ignorieren lässt.

Der Bedarf zuerst, nicht die Funktionsliste

Die meisten wählen ein DMARC-Tool so, wie man einen Laptop wählt: durch den Vergleich von Datenblättern. Das ist ein Fehler, denn DMARC ist kein Produkt, sondern ein Projekt. Das Tool ist nur ein Mittel zu einem präzisen Ergebnis — eine p=reject-Policy zu veröffentlichen, ohne die legitime Post zu zerstören, und sie dann über die Zeit zu erhalten. Zwei Organisationen mit demselben Ziel können radikal unterschiedliche Tools brauchen, nicht weil die eine „recht" und die andere „unrecht" hat, sondern weil ihr Kontext sich unterscheidet.

Noch vor dem ersten Dashboard stehen vier Fragen, ehrlich zu beantworten. Diese allein entscheiden 90 % der Wahl.

Die vier Fragen, die den Bedarf bestimmen

1. Wie viele Domains sind zu schützen? Eine einzige aktive Domain oder eine Konstellation aus Marken, Tochtergesellschaften und geparkten Domains? Die Antwort ändert alles. Für eine Domain reicht oft ein leichtgewichtiges Tool — sogar ein einmaliger Durchlauf durch einen Analyzer. Für zwanzig Domains wird die Fähigkeit, alles auf einen Blick zu sehen, Postures zu vergleichen und alarmiert zu werden, wenn eine abdriftet, zum zentralen Kriterium. Für Multi-Domain zu zahlen lohnt bei einer einzigen Domain nie; zwanzig Domains von Hand einzeln durchzukurbeln ebenso wenig.

2. Wie technisch ist das Team, das es tatsächlich nutzen wird? Ein Ingenieur, der mit DNS-Einträgen, SPF und DKIM vertraut ist, kann aggregierte Berichte von Hand lesen und auf viel Unterstützung verzichten. Ein Marketing-Team oder eine überlastete IT-Abteilung braucht, dass man ihr die Berichte in Aktionen übersetzt: „Die E-Mail-Plattform sendet ohne Ausrichtung, hier ist der fehlende Eintrag". Die Raffinesse eines Tools sollte umgekehrt proportional zu der des Teams sein — je selbstständiger das Team, desto weniger muss das Tool die Hand halten.

3. Lautet das Ziel, einmal zu verschärfen, oder kontinuierlich zu überwachen? Das ist die am meisten unterschätzte Frage. Manche wollen eine Domain einfach einmal verschärfen — reject erreichen, prüfen und weiterziehen. Andere brauchen dauerhafte Wachsamkeit, weil jeden Monat neue Versandquellen auftauchen. Der erste Bedarf wird von einem Diagnose-Tool bedient; der zweite verlangt eine Plattform, die die Berichte kontinuierlich einliest und alarmiert. Die beiden zu verwechseln bedeutet entweder, für eine ungenutzte Überwachung zu überzahlen, oder zu glauben, ein einmaliger Check schütze dauerhaft — das tut er nicht.

4. Bestehen Souveränitäts- oder Compliance-Anforderungen? Wenn die DMARC-Berichte — die IP-Adressen und Versand-Metadaten enthalten — einen bestimmten rechtlichen Rahmen nicht verlassen dürfen, oder wenn ein Audit-Nachweis zu erbringen ist, engt das das Feld stark ein. Manche hosten dann ihren eigenen Stack; andere verlangen einen Anbieter mit klarer Datenresidenz. Dieses Kriterium, am Anfang oft ignoriert, disqualifiziert manchmal ansonsten attraktive Tools.

Was ein DMARC-Tool wirklich tut

Hinter dem Marketing-Vokabular tut ein ernsthaftes DMARC-Tool nur wenige Dinge, aber es muss sie gut tun:

Die aggregierten (rua) Berichte empfangen und einlesen — jene komprimierten XML-Dateien, die Empfänger täglich zurücksenden. Bleibt ihr Inhalt unklar, beginnt alles beim Verständnis dessen, was aggregierte DMARC-Berichte sind.
Die Versandquellen identifizieren — rohe IP-Adressen in benannte Absender verwandeln (das Mailsystem, die E-Mail-Plattform, das Rechnungstool). Das ist der Unterschied zwischen „40.92.x.x hat 300 Nachrichten gesendet" und „der Microsoft-365-Tenant sendet ohne DKIM-Ausrichtung".
Die Ausrichtung Quelle für Quelle zeigen — SPF und DKIM, als Trend über mehrere Wochen, nicht als Momentaufnahme.
Nennen, was zu korrigieren ist — und idealerweise alarmieren, wenn eine neue Quelle auftaucht oder eine legitime zu scheitern beginnt.

Alles andere — Diagramme, dunkle Themes, PDF-Exporte — ist zweitrangig. Ein Tool, das diese vier Dinge sauber erledigt, schlägt eines, das dreißig Zusatzfunktionen stapelt. Wir schlüsseln die Funktionen, die in einem Analyzer wirklich zählen separat auf; festzuhalten bleibt, dass die nützliche Liste kurz ist.

Kostenlos, kostenpflichtig, selbst gehostet: drei Modelle, kein Ranking

Sobald der Bedarf klar ist, treten drei große Tool-Familien auf. Keine ist im Absoluten „besser"; jede bedient ein Profil.

Kostenlos — typischerweise ein Online-Analyzer — glänzt bei einer einmaligen Diagnose und für eine Organisation mit einer einzigen Domain, die einmal verschärft. Seine Grenzen zeigen sich, sobald über die Zeit zu verfolgen oder mehrere Domains abzudecken sind. Wir vergleichen genau, was kostenlos abdeckt gegenüber kostenpflichtig, in einem eigenen Beitrag.

Kostenpflichtig / verwaltet fügt hinzu, was kostenlos nicht bieten kann: kontinuierliche Einlesung, Historie, Alerting, Multi-Domain, Remediation-Begleitung. Die Kehrseite sind wiederkehrende Kosten, und was diesen Preis wirklich bestimmt gehört vor der Unterschrift verstanden.

Selbst gehostet (Open Source) spricht Teams an, die volle Datensouveränität und keine Gebühr pro Domain wollen — zum Preis von echter Ingenieur- und Wartungszeit. Das vollständige Duell wird in selbst gehostet oder verwaltet behandelt.

Der richtige Weg, diese drei Modelle zu lesen: nicht „welches ist am vollständigsten", sondern „welches passt zu meinen vier Antworten". Eine Domain, ein technisches Team, ein einmaliges Ziel → kostenlos reicht. Zwanzig Domains, ein nicht-technisches Team, kontinuierliche Überwachung → ein verwalteter Dienst ist gerechtfertigt. Starke Souveränitätsanforderungen plus Ingenieurskapazität → Selbsthosting verdient die Prüfung.

Ein konkretes Beispiel

Nehmen wir zwei Organisationen, die auf dem Papier dasselbe wollen: p=reject erreichen.

Die erste ist eine Agentur mit zehn Personen und einer einzigen Domain. Sie sendet von ihrem Mailsystem und einem Rechnungstool — zwei Quellen, an einem Nachmittag ausrichtbar. Ihr Bedarf ist eine klare Diagnose, einmal, um zu bestätigen, dass sie ohne Bruch verschärfen kann. Hier wäre es absurd, die Kreditkarte für eine Multi-Domain-Überwachungsplattform zu zücken: Ein kostenloser Analyzer zeigt die Ausrichtung ihrer zwei Quellen, sie korrigiert, sie veröffentlicht reject, sie ist fertig. Mehr zu zahlen würde nur Funktionen kaufen, die sie nie öffnet.

Die zweite ist eine Gebietskörperschaft mit fünfzehn Fachbereichen, gut dreißig Domains und neuen Versandquellen, die jedes Quartal auftauchen (Newsletter, Bürgerwarnungen, Event-Dienstleister). Ihr Bedarf ist keine einmalige Diagnose — es ist dauerhafte Wachsamkeit. Ein kostenloser Check gäbe ihr eine Momentaufnahme, die binnen eines Monats veraltet ist. Hier ist eine Plattform, die Berichte kontinuierlich einliest, die Quellen benennt und alarmiert, wenn ein Fachbereich ein neues Tool anschließt, jeden Euro wert: Ohne sie driftet die Posture still ab und eine vergessene Domain wird wieder fälschbar.

Dasselbe Ziel, zwei gegensätzliche Tools — weil die vier Antworten ebenfalls gegensätzlich sind. Genau dieses Denken verhindert der Funktionskatalog.

Ein Ausstiegskriterium: kommen die Daten zurück?

Ein Punkt, den fast niemand vor der Unterschrift prüft und den danach viele bereuen: die Umkehrbarkeit. Die aggregierten Berichte häufen sich Monat für Monat; nach einem Jahr ist diese Historie ein Aktivposten — sie erzählt die Entwicklung der Posture, dient als Compliance-Nachweis, dokumentiert jede Quelle. Die Frage vor der Wahl lautet also nicht nur „was gibt mir das Tool?", sondern „was nehme ich mit, wenn ich gehe?".

Ein gutes Tool lässt die Historie in einem offenen Format exportieren und hält die Daten nicht als Geisel. Ein schlechtes sperrt ein: Am Tag des Wechsels beginnt alles bei null, das Jahr an Historie verloren. Für eine Organisation mit Archivierungs- oder Audit-Pflichten kann dieses Kriterium jede glänzende Funktion aufwiegen. Die Frage gehört früh gestellt — die Antwort sagt viel über die Beziehung aus, die der Anbieter führen will, und sie knüpft an die Souveränitätsfrage an: bleiben die Daten die des Kunden, oder werden sie seine?

Häufige Fehler

Funktionslisten vergleichen, statt beim eigenen Bedarf zu beginnen. Die beeindruckendste Funktion ist wertlos, wenn sie einen Bedarf beantwortet, den es nicht gibt. Die vier Antworten gehören vor jede Demo erneut gelesen.
Ein Diagnose-Tool für kontinuierlichen Schutz halten. Ein einzelner Durchlauf durch einen Analyzer nennt den Stand von heute, nicht den von morgen. Bewegen sich Quellen, braucht es Überwachung, keine Momentaufnahme.
„Für alle Fälle" überdimensionieren. Eine Enterprise-Plattform für eine einzige Domain zu kaufen ist Verschwendung, verkleidet als Vorsicht. Ein Aufstieg bleibt immer möglich, an dem Tag, an dem der Bedarf wächst.
Wählen, ohne die eigenen Berichte angesehen zu haben. Viele unterschreiben einen Vertrag, bevor sie überhaupt wissen, wie viele Quellen sie haben. Am Anfang steht die Beobachtung der eigenen Realität — der kostenlose DMARC-Analyzer zeigt sie in einer Minute — und danach die Wahl aus einer informierten Position.
Datensouveränität ignorieren, bis es zu spät ist. Wenn die Berichte einen Rahmen nicht verlassen dürfen, ist das ein Eintrittskriterium, keine Option am Ende des Prozesses.

Der Rahmen, in einem Satz

Die richtige Wahl ist das einfachste DMARC-Tool, das die vier Fragen beantwortet — Anzahl der Domains, Reife des Teams, einmaliges oder kontinuierliches Ziel, Souveränitätsanforderungen — und keines mehr. Raffinesse ist ein Kostenfaktor, keine Tugend; das richtige Maß ist die Passung.

Diese Wahl ergibt nur Sinn im Verhältnis zu einem Ziel: die Domains von der Überwachung zur Durchsetzung zu bewegen. Ist dieser Kurs noch nicht gesetzt, entfaltet p=reject erreichen, ohne die E-Mails zu zerstören die Trajektorie, und die Absenderanforderungen von Gmail und Yahoo erinnern daran, warum das Thema nicht warten kann.

Der Ausgangspunkt, welches Tool danach auch fällt, bleibt derselbe: die realen Quellen ansehen. Eine Eingabe der Domain in unseren Analyzer zeigt die Ausrichtung Quelle für Quelle, und ein Konto trägt diese Posture über die Zeit. Die Entscheidung wird leichter, sobald sie von Fakten ausgeht statt von einer Vergleichstabelle.