Was ist DMARC, und wie stoppt es die E-Mail-Usurpation?

Die Schlüsselidee: die Ausrichtung

Die Ausrichtung ist das, was DMARC stärker macht als SPF und DKIM zusammen. Man stelle sich einen Angreifer vor, der boesewicht.com kontrolliert. Er kann ein perfektes SPF und DKIM für boesewicht.com einrichten – also besteht seine Post diese Kontrollen. Aber wenn er From: kontakt@beispiel-unternehmen.de usurpiert, stellt DMARC eine härtere Frage: stimmt die authentifizierte Domain mit der Domain des From: überein? Für den Angreifer nein (boesewicht.com ≠ beispiel-unternehmen.de): DMARC scheitert und die Richtlinie der usurpierten Domain greift. Das ist der Schutz, den SPF und DKIM allein nie geboten haben. Für die vertiefte Version siehe unseren Leitfaden zu wie SPF, DKIM und DMARC zusammenarbeiten.

Wie ein DMARC-Eintrag aussieht

Ein DMARC-Eintrag ist ein einziger DNS-TXT-Eintrag, veröffentlicht unter _dmarc.beispiel.de:

_dmarc.beispiel.de.  IN TXT
  "v=DMARC1; p=none; rua=mailto:berichte@beispiel.de; adkim=s; aspf=s"

Die Tags, die am meisten zählen:

• p – die Richtlinie: none, quarantine oder reject.
• rua – die Adresse, die die täglichen aggregierten Berichte empfängt (die Rückkopplungsschleife).
• adkim / aspf – die Strenge der Ausrichtung: s (strict) oder r (relaxed).
• sp – die Richtlinie für die Subdomains (oft auf p abgestimmt).

Die drei Richtlinien

Die Durchsetzung von DMARC ist eine Leiter, und die gewählte Sprosse ändert, was die Empfänger mit nicht authentifizierter Post tun:

• p=none – reine Beobachtung. Nichts ändert sich für die Zustellbarkeit; es werden nur Berichte gesammelt. Hier fängt man an, und hier bleiben leider die meisten Domains für immer.
• p=quarantine – die nicht authentifizierte Post landet im Spam. Eine echte, wenn auch nachgiebige Verteidigung.
• p=reject – die nicht authentifizierte Post wird am Eingang abgelehnt. Das ist das Ziel: Die im Namen der Domain usurpierte Post wird schlicht nicht zugestellt.

Nur p=reject stoppt die Usurpation wirklich. Ein Überwachen im p=none schützt niemanden – es misst nur das Ausmaß der Exposition. Genau das bestätigt im Übrigen unser DMARC-Observatorium: In den meisten analysierten Branchen bleibt die Mehrheit der Domains im p=none stecken, also sichtbar, aber ungeschützt.

Was DMARC garantiert – und was nicht

Aus Sicht der nicht-technischen Geschäftsleitung läuft DMARC auf ein präzises Versprechen hinaus: Sobald p=reject erreicht ist, kann niemand mehr eine E-Mail zustellen, die exakt die geschützte Domain im From: anzeigt, ohne Autorisierung ihres Inhabers. Das ist eine starke Garantie – sie schützt Kunden, Lieferanten und Mitarbeiter vor gefälschten Rechnungen und betrügerischen Zahlungsaufforderungen „im Namen des Unternehmens" –, aber sie hat einen Geltungsbereich, und ihn zu kennen bewahrt vor einem falschen Sicherheitsgefühl.

DMARC blockiert keine Doppelgänger-Domains: Ein Angreifer, der beispiel-unternehmen-rechnung.de registriert oder ein „l" durch eine „1" ersetzt, läuft an der Kontrolle vollständig vorbei, denn er usurpiert eine Domain, die ihm tatsächlich gehört. Es verhindert auch nicht die Täuschung über den Anzeigenamen – „Geschäftsführung" vor einer beliebigen Webmail-Adresse – und ebenso wenig den Versand aus einem kompromittierten legitimen Postfach, der sich einwandfrei authentifiziert, weil er wirklich aus der eigenen Infrastruktur kommt. Und es filtert kein eingehendes Phishing von fremden Domains: Den Posteingang schützt das DMARC der anderen, so wie das eigene deren Posteingang schützt. Diese benachbarten Techniken kartieren wir in unserem Überblick zur E-Mail-Usurpation. DMARC ist also ein unverzichtbarer Baustein, kein Totalschild: Es verriegelt die exakte Identität und überlässt die übrigen Vektoren der Sensibilisierung und dem eingehenden Filtern.

Wie DMARC-Berichte funktionieren

Da man eine Richtlinie nicht durchsetzen kann, ohne zu wissen, wer legitim für die Domain sendet, enthält DMARC einen Rückkopplungskanal. Empfänger wie Google, Microsoft und Yahoo senden täglich aggregierte Berichte (XML) an die rua=-Adresse und fassen zusammen, wie sich die Post verhalten hat, die sich auf die Domain beruft: welche IPs sie versendet haben, in welchem Volumen und ob sie SPF, DKIM und die Ausrichtung bestanden hat. Diese Berichte sind die Karte, mit der man jede legitime Quelle findet und korrigiert, bevor man die Richtlinie verschärft. Wir behandeln sie im Detail in aggregierte DMARC-Berichte lesen.

DMARC entwickelt sich weiter: was DMARCbis ändert (2026)

Im Mai 2026 hat die IETF DMARCbis veröffentlicht – die modernisierte Version des Standards, verteilt auf drei RFCs: 9989 (das Protokoll selbst), 9990 (aggregierte Berichte) und 9991 (Fehlerberichte). Zusammen ersetzen sie die ursprüngliche RFC 7489 und bringen DMARC zum ersten Mal auf den Standards-Track (Proposed Standard). Zur sofortigen Beruhigung: das ist kein Bruch. Die Einträge beginnen weiterhin mit v=DMARC1, und es ist nichts zu ändern, um geschützt zu bleiben. Hier das Wesentliche dessen, was sich bewegt:

• Das Tag pct verschwindet. Das Ausrollen „über einen Prozentsatz der Post" erwies sich als unzuverlässig und wird zurückgezogen, ersetzt durch einen binären Testmodus: das Tag t (t=y signalisiert „ich experimentiere, wende noch nicht streng an"). Um hochzufahren, stützt man sich künftig auf Subdomain-Richtlinien und die Beobachtung der Berichte, nicht mehr auf einen Prozentsatz.
• Zwei neue Subdomain-Tags. np definiert die Richtlinie für nicht existierende Subdomains – ein klassisches Usurpationsziel, weil niemand sie überwacht – und psd markiert Public-Suffix-Domains (Registries).
• Der DNS Tree Walk ersetzt die Public Suffix List. Um die „organisatorische Domain" zu bestimmen, fragt DMARCbis das DNS schrittweise ab (maximal 8 Abfragen), statt von einer extern, von Hand gepflegten Liste abzuhängen – robuster und vorhersehbarer.

Der Rest – p, sp, rua, ruf, adkim, aspf, fo – behält exakt dieselbe Bedeutung. In der Praxis: Der bestehende Eintrag bleibt gültig, aber es ist der richtige Moment, ein unnütz gewordenes pct zu entfernen und ein np=reject auf die Phantom-Subdomains zu setzen.

Warum die meisten Domains im p=none stecken bleiben

p=none zu veröffentlichen ist einfach; es zu überwinden ist der Punkt, an dem die Teams ins Stocken geraten. Der Grund ist die Angst: Organisationen versenden von weit mehr Stellen, als sie glauben – die Marketing-Plattform, das CRM, die Rechnungsstellung, der Support, jene App, die ein Team vor zwei Jahren eingerichtet hat. Wird die Richtlinie verschärft, bevor jede einzelne authentifiziert und ausgerichtet ist, landet die eigene legitime Post im Spam. Also bleibt der Eintrag im p=none, in ewiger Überwachung, während die Usurpatoren frei operieren.

Der Ausweg ist nicht der Mut, sondern die Methode. Man inventarisiert jede Quelle aus den aggregierten Berichten, richtet jede in SPF/DKIM aus, hebt dann die Richtlinie von quarantine auf reject an und prüft dabei, dass die Berichte sauber bleiben. Wir gehen die gesamte Abfolge in p=reject erreichen, ohne seine E-Mails zu ruinieren durch.

DMARC in der Compliance-Praxis

Wer den CISO- oder Datenschutzbeauftragten-Hut trägt, entdeckt an DMARC ein zweites Leben jenseits der reinen Technik: Es taucht in fast jedem Dossier auf, das zu verteidigen ist. Cyber-Versicherungsfragebögen und Lieferanten-Sicherheitsbewertungen fragen immer öfter ausdrücklich, welche DMARC-Richtlinie veröffentlicht ist – und ein p=none macht dort keine gute Figur. Die großen Mailbox-Anbieter verlangen DMARC inzwischen von Massenversendern, was aus einer früheren Empfehlung eine harte Zustellbarkeitsbedingung macht. Mehrere Staaten haben es für ihre eigenen Behörden verpflichtend gemacht – ein deutliches Zeichen, dass der Standard das Territorium des „Nice to have" längst verlassen hat. Und in einem Sicherheitsmanagementsystem nach Art von ISO 27001 dokumentiert eine durchgesetzte DMARC-Richtlinie ganz konkret eine Maßnahme gegen Betrug durch Identitätsusurpation, während die aggregierten Berichte einen überprüfbaren, fortlaufenden Nachweis liefern, dass die Maßnahme über die Zeit tatsächlich wirkt – genau die Art von Beleg, die ein Auditor sehen will.

Der Compliance-Blickwinkel hat eine große Tugend: Er hängt eine Frist an ein Projekt, das die Technik allein gern endlos schleifen lässt. Ein guter Ausgangspunkt, um die Dringlichkeit schwarz auf weiß zu belegen: die Prüfung, ob eine Domain heute usurpierbar ist, und das Ergebnis dem Dossier beilegen.

Wo eine Domain wirklich steht

Raten ist unnötig. Eine kostenlose und sofortige Überprüfung der DMARC-, SPF- und DKIM-Posture einer Domain läuft über unseren Domain-Analyzer – er zeigt die aktuelle Richtlinie, die Ausrichtung und eine klare Note. Das DMARC-Observatorium lässt sich ebenso durchstöbern, um zu sehen, wie sich ganze Branchen vergleichen.

Häufige DMARC-Fehler, die es zu vermeiden gilt

Selbst Teams, die DMARC veröffentlichen, stolpern oft über dieselben Details, und jedes untergräbt still den Schutz:

• Zwei DMARC-Einträge. Wie bei SPF darf eine Domain nur einen einzigen _dmarc-TXT-Eintrag haben. Ein zweiter macht die Richtlinie mehrdeutig, und die Empfänger können beide ignorieren – die Domain bleibt exponiert, obwohl sie gedeckt scheint. Alles gehört in einen einzigen Eintrag zusammengeführt.
• Direkt zu p=reject springen. Durchzusetzen, bevor jede legitime Quelle ausgerichtet ist, ist der schnellste Weg, die eigenen Rechnungen, Belege und Passwort-Zurücksetzungen ins Leere zu schicken. Der Aufstieg führt über none, dann quarantine, mit Überwachung der Berichte bei jedem Schritt.
• Die Subdomain-Richtlinie ignorieren. Das Tag sp steuert die Subdomains, und mit DMARCbis deckt das Tag np nun nicht existierende Subdomains ab. Wird auf der Wurzeldomain durchgesetzt, sp aber permissiv gelassen, usurpieren die Angreifer einfach news.beispiel.de oder mail.beispiel.de. sp (und np) sind bewusst zu setzen, in der Regel wie p.
• p=none als Ziellinie betrachten. Die Überwachung ist der Start, nicht das Ziel. Ein Eintrag, der nie über none hinauskommt, schützt niemanden – er dokumentiert nur die Exposition.
• Ohne rua-Adresse veröffentlichen. Ohne aggregierte Berichte geht die Fahrt im Blindflug: Ein gelassenes Verschärfen ist unmöglich, solange unsichtbar bleibt, wer legitim für die Domain sendet. Ein rua gehört immer dazu.
• Die ruhenden Domains vergessen. Domains, die einer Organisation gehören, von denen sie aber nicht sendet, sind bevorzugte Usurpationsziele, gerade weil niemand sie überwacht. Auf jeder ruhenden Domain gehört ein striktes p=reject veröffentlicht.

Keiner davon ist schwer zu korrigieren; es ist vor allem eine Frage der Geduld und guter Daten – genau das, was ein geführter, von den Berichten gesteuerter Prozess anstelle von Vermutungen liefert.

Thomas übernimmt

p=reject zu erreichen ist ein Projekt, aber es muss kein hausgemachtes Projekt sein. Thomas, der virtuelle CISO, benennt jede Sendequelle aus den Berichten, generiert das exakte DNS zum Einfügen (DMARCbis-Tags inklusive), bewertet die Bereitschaft anhand gleitender Daten und nennt den genauen Moment, um risikofrei zu verschärfen – von p=none bis p=reject, ohne eine einzige legitime E-Mail zu blockieren.

Eine Domain kostenlos analysieren oder ein Konto erstellen und Thomas die schwere Arbeit erledigen lassen.