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

Die E-Mail wurde in einer Zeit des Vertrauens entworfen. Nichts im ursprünglichen Protokoll hindert einen Absender daran, irgendeine Adresse in das Feld From: zu schreiben – auch deine. Diese eine Lücke erklärt, warum Phishing, CEO-Betrug und Markenusurpation Jahrzehnte später noch funktionieren. DMARC ist der Standard, der sie schließt. Dieser Leitfaden erklärt, was DMARC ist, wie es funktioniert und wie du es nutzt, um deine Domain wirklich zu schützen – nicht nur, um sie endlos zu überwachen.

Das Problem, das DMARC löst

Wenn ein Mailserver eine Nachricht empfängt, ist die Adresse, die ein Mensch sieht – die Kopfzeile From: –, nur ein vom Absender gewählter Text. Ein Angreifer kann dort rechnung@dein-unternehmen.de eintragen und von seinem eigenen Server aus eine überzeugende gefälschte Rechnung versenden. Ohne Authentifizierung hat der empfangende Server keine verlässliche Möglichkeit zu wissen, dass die Nachricht nicht von dir stammt. Genau das ist der Mechanismus hinter den meisten Überweisungsbetrügereien: eine E-Mail, die scheinbar von der Geschäftsleitung oder einem Lieferanten kommt und die technisch durch nichts von der echten zu unterscheiden ist.

SPF und DKIM waren die ersten Antworten. SPF erlaubt es, zu veröffentlichen, welche Server für deine Domain senden dürfen; DKIM hängt eine kryptografische Signatur an, die der Empfänger überprüft. Beide sind nötig – aber keines allein schützt die Adresse, die der Nutzer tatsächlich liest. SPF prüft den verborgenen Umschlag-Absender; DKIM beweist, dass eine Signatur existiert, ohne zu verlangen, dass sie mit deiner sichtbaren Domain übereinstimmt. Ein Angreifer kann SPF und DKIM für seine eigene Domain bestehen und dennoch deine im From: anzeigen.

Was DMARC wirklich ist

DMARC (Domain-based Message Authentication, Reporting and Conformance), ursprünglich definiert durch die RFC 7489 und 2026 durch DMARCbis (RFC 9989) modernisiert, ist eine kurze, in deinem DNS veröffentlichte Richtlinie. Sie leistet drei Dinge:

1. Verknüpft SPF und DKIM mit der sichtbaren Domain. Eine Nachricht besteht DMARC nur, wenn sie durch SPF oder DKIM validiert wird und die so authentifizierte Domain mit der Domain des From: übereinstimmt. Diese Übereinstimmungsregel heißt Ausrichtung (Alignment), und darin liegt der ganze Nutzen von DMARC.
2. Sagt den Empfängern, was mit fehlgeschlagener Post zu tun ist. Du wählst eine Richtlinie: nichts tun, in den Spam legen oder ablehnen.
3. Schickt dir Berichte. Die Empfänger senden dir tägliche Zusammenfassungen jeder Quelle, die in deinem Namen sendet – die Daten, die du brauchst, um risikofrei zu korrigieren.

Die vollständigen Mechanismen findest du auf unserer DMARC-Referenzseite.

Die Schlüsselidee: die Ausrichtung

Die Ausrichtung ist das, was DMARC stärker macht als SPF und DKIM zusammen. Stell dir 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: du@dein-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 ≠ dein-unternehmen.de): DMARC scheitert und deine Richtlinie greift. Das ist der Schutz, den SPF und DKIM allein dir nie gegeben 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.deine-domain.de:

_dmarc.deine-domain.de.  IN TXT
  "v=DMARC1; p=none; rua=mailto:berichte@deine-domain.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 deine 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; du sammelst nur Berichte. 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 in deinem Namen usurpierte Post wird schlicht nicht zugestellt.

Nur p=reject stoppt die Usurpation wirklich. Ein Überwachen im p=none schützt niemanden – es sagt dir nur, wie sehr du exponiert bist. 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.

Wie DMARC-Berichte funktionieren

Da man eine Richtlinie nicht durchsetzen kann, ohne zu wissen, wer legitim für dich sendet, enthält DMARC einen Rückkopplungskanal. Empfänger wie Google, Microsoft und Yahoo senden täglich aggregierte Berichte (XML) an deine rua=-Adresse und fassen zusammen, wie sich die Post verhalten hat, die sich auf dich 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). Beruhige dich sofort: das ist kein Bruch. Die Einträge beginnen weiterhin mit v=DMARC1, und du musst nichts ä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: Dein aktueller Eintrag bleibt gültig, aber es ist der richtige Moment, ein unnütz gewordenes pct zu entfernen und ein np=reject auf deine 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. Verschärfe die Richtlinie, bevor jede einzelne authentifiziert und ausgerichtet ist, und du riskierst, deine eigene legitime Post in den Spam zu schicken. 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. Du inventarisierst jede Quelle aus den aggregierten Berichten, richtest jede in SPF/DKIM aus, dann hebst du die Richtlinie von quarantine auf reject an und prüfst dabei, dass die Berichte sauber bleiben. Wir gehen die gesamte Abfolge in p=reject erreichen, ohne seine E-Mails zu ruinieren durch.

Prüfe, wo deine Domain steht

Du musst nicht raten. Starte eine kostenlose und sofortige Überprüfung der DMARC-, SPF- und DKIM-Posture deiner Domain mit unserem Domain-Analyzer – er zeigt deine aktuelle Richtlinie, die Ausrichtung und eine klare Note. Du kannst auch das DMARC-Observatorium 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 deine Domain nur einen einzigen _dmarc-TXT-Eintrag haben. Ein zweiter macht die Richtlinie mehrdeutig, und die Empfänger können beide ignorieren – und lassen dich exponiert, obwohl du dich gedeckt glaubst. Führe alles zu einem einzigen Eintrag zusammen.
• Direkt zu p=reject springen. Durchzusetzen, bevor jede legitime Quelle ausgerichtet ist, ist der schnellste Weg, deine eigenen Rechnungen, Belege und Passwort-Zurücksetzungen ins Leere zu schicken. Steige über none, dann quarantine auf und überwache bei jedem Schritt die Berichte.
• Die Subdomain-Richtlinie ignorieren. Das Tag sp steuert die Subdomains, und mit DMARCbis deckt das Tag np nun nicht existierende Subdomains ab. Wenn du auf deiner Wurzeldomain durchsetzt, aber sp permissiv lässt, usurpieren die Angreifer einfach news.deine-domain.de oder mail.deine-domain.de. Setze sp (und np) bewusst, 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 deine Exposition.
• Ohne rua-Adresse veröffentlichen. Ohne aggregierte Berichte navigierst du im Blindflug: Du kannst nie gelassen verschärfen, da du nicht siehst, wer legitim für dich sendet. Füge immer ein rua ein.
• Die ruhenden Domains vergessen. Domains, die dir gehören, von denen du aber nicht sendest, sind bevorzugte Usurpationsziele, gerade weil niemand sie überwacht. Veröffentliche ein striktes p=reject auf jeder ruhenden Domain.

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 dir anstelle von Vermutungen liefert.

Lass Thomas übernehmen

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

Analysiere deine Domain kostenlos → oder erstelle ein Konto und lass Thomas die schwere Arbeit erledigen.