Blockiert ein DMARC-Eintrag Spoofing wirklich, oder nur die Kampagnen, die das Marketing-Team noch immer über einen falsch ausgerichteten Router verschickt? DMARC (Domain-based Message Authentication, Reporting and Conformance) ist ein DNS-Eintrag, der empfangenden Servern, Gmail, Outlook, Yahoo, mitteilt, welche Richtlinie bei einer E-Mail gilt, die das SPF– oder DKIM-Alignment nicht besteht. Allein veröffentlicht, ohne die beiden Protokolle, die er überwacht, blockiert er gar nichts. Ende 2025 hatten 83,9 % der von Red Sift untersuchten Domains keinen veröffentlichten DMARC-Eintrag, bei einer Stichprobe von 73,3 Millionen Domains. Der folgende Abschnitt erklärt die genaue Syntax des Eintrags, die drei verfügbaren Richtlinien und das Lesen der rua-Berichte.
Was ist DMARC?
Eine Domain, die SPF und DKIM ohne _dmarc veröffentlicht, überlässt jedem empfangenden Server selbst die Entscheidung, wie er mit einem Authentifizierungsfehler umgeht. Manche weisen die Nachricht zurück, andere liefern sie trotzdem aus und markieren sie als verdächtig, wieder andere ändern gar nichts. DMARC beendet diese Unklarheit: Der Domain-Inhaber legt die Richtlinie selbst fest, in einem TXT-Eintrag auf dem Host _dmarc.ihredomain.de. Der Standard ist seit 2015 in RFC 7489 dokumentiert, die Verbreitung bleibt aber uneinheitlich. Große börsennotierte Unternehmen liegen in länderbezogenen Analysen über 85 % Abdeckung, der weltweite Durchschnitt bleibt unter 15 % (Red Sift, 2025). Der Unterschied liegt vor allem an der als kompliziert wahrgenommenen Syntax, selten an ihrer tatsächlichen Schwierigkeit.
Warum DMARC wichtig ist
Eine Domain ohne DMARC-Richtlinie lässt jeden eine E-Mail mit ihrem Namen versenden, ohne dass ein Mechanismus den Empfänger warnt. Das ist der Hauptvektor für Phishing durch Markenidentitätsdiebstahl, jene Art, bei der ein Buchhalter auf eine gefälschte Rechnung seines eigenen Lieferanten klickt. Das Dashboard eines E-Mail-SaaS kann eine solide Zustellbarkeit anzeigen, ohne etwas darüber auszusagen, was ein Dritter außerhalb dieser Plattform verschickt: die intern gemessene Zustellbarkeit und die externe Angriffsfläche für Spoofing bleiben zwei verschiedene Kennzahlen. Eine Domain, die Ziel einer Spoofing-Kampagne wird, verliert außerdem an Sender Reputation bei den Filtern von Gmail und Outlook, ein Signal, das später in den Kennzahlen von Google Postmaster Tools sichtbar wird, auch wenn keine einzige betrügerische E-Mail tatsächlich von der eigenen Infrastruktur des Unternehmens abgeht. Filter orientieren sich am sichtbaren Domainnamen, nicht an der versendenden IP.
Wie DMARC auf SPF und DKIM aufbaut

DMARC ersetzt weder SPF noch DKIM. Es überwacht sie, gestützt auf ihre Ergebnisse. SPF prüft, ob der sendende Server berechtigt ist, für die im MAIL FROM angegebene Domain zu senden. DKIM signiert den Nachrichteninhalt mit einem kryptografischen Schlüssel, was jede Änderung während der Übertragung erkennbar macht. Eine E-Mail kann bei einem der beiden scheitern und beim anderen bestehen: DMARC verlangt, dass mindestens eines der beiden erfolgreich ist, und vor allem, dass die durch dieses Protokoll geprüfte Domain mit der im From-Header angezeigten Domain übereinstimmt, jener, die der Empfänger sieht. Diese Übereinstimmung trägt einen Namen, das Alignment.
Das Alignment kann strikt oder gelockert sein, festgelegt über die Tags aspf und adkim des DMARC-Eintrags. Im gelockerten Modus, dem Standard, richtet sich eine Subdomain wie newsletter.unternehmen.de nach unternehmen.de aus. Im strikten Modus wird nur eine exakte Übereinstimmung akzeptiert. Die meisten externen Versandplattformen veröffentlichen eigene SPF-Einträge und signieren mit eigenen DKIM-Schlüsseln, egal ob es sich um einen transaktionalen Router oder ein externes CRM handelt. Ohne ausdrückliche DNS-Konfiguration der versendenden Subdomain scheitern diese E-Mails am Alignment, selbst wenn sie völlig legitim sind. Das ist die häufigste Ursache für eine DMARC-Ablehnungsrate, die nach der Einführung eines neuen Marketing-Tools ansteigt, ganz ohne dass eine Phishing-Kampagne dahintersteckt.
Einen DMARC-Eintrag erstellen: Syntax und Beispiel
Die Einrichtung eines DMARC-Eintrags beginnt immer mit der Wahl des richtigen DNS-Hosts. Der Eintrag wird wie ein gewöhnlicher TXT-Eintrag veröffentlicht, auf dem Host _dmarc der DNS-Zone der Domain, niemals auf der Root-Domain. Hier ein kommentiertes Beispiel für einen schrittweisen Rollout:
v=DMARC1; p=quarantine; pct=50; rua=mailto:rua@unternehmen.de; ruf=mailto:ruf@unternehmen.de; aspf=r; adkim=r; sp=none
Jedes Tag hat eine genaue Rolle. v legt die Protokollversion fest, immer DMARC1. p definiert die für die Domain geltende Richtlinie. pct legt den Prozentsatz der nicht konformen Nachrichten fest, die von dieser Richtlinie betroffen sind. rua gibt die Adresse an, die die täglichen aggregierten Berichte empfängt. ruf gibt die Adresse für forensische Berichte an, die von den großen Mailbox-Providern selten eingehalten wird. sp legt die Richtlinie für Subdomains fest, die keinen eigenen Eintrag haben.
So wird der Eintrag erstellt und geprüft:
- Alle legitimen Absender der Domain identifizieren (ESP, CRM, Abrechnung, Helpdesk) und bestätigen, dass jeder SPF veröffentlicht oder mit DKIM signiert.
- Eine eigene Adresse für rua-Berichte anlegen.
- Den TXT-Eintrag auf _dmarc mit p=none für mindestens zwei bis vier Wochen veröffentlichen, nur beobachten.
- Die ersten aggregierten Berichte lesen, um Quellen mit Alignment-Fehlern zu finden und einzeln zu korrigieren.
- Die Richtlinie stufenweise anheben, pct=25, dann pct=50, dann pct=100, bevor auf quarantine und danach auf reject umgestellt wird.
Ein fehlerhaft formulierter Eintrag, ein doppeltes Tag oder eine ungültige rua-Adresse verhindert in der Regel nicht die Veröffentlichung in der DNS. Er blockiert stillschweigend den Empfang der Berichte, was die Steuerung unmöglich macht, ohne dass eine Warnung den Administrator erreicht.
Die drei DMARC-Richtlinien und der schrittweise Rollout
Für das Tag p sind drei Werte möglich. none ändert nichts an der Zustellung: Die E-Mail nimmt ihren gewohnten Weg, nur der rua-Bericht erfasst den Fehler. quarantine schickt die nicht konforme E-Mail in den Spam-Ordner des Empfängers oder ein Äquivalent. reject blockiert den Versand, bevor er überhaupt den Posteingang erreicht, mit einer an den Absender zurückgesendeten SMTP-Ablehnung.
Direkt zu p=reject zu wechseln, ohne eine Beobachtungsphase, blockiert auch legitime, nicht ausgerichtete E-Mails, eine Mailingliste, die den From-Header umschreibt, einen falsch konfigurierten externen CRM-Router, einen ausgelagerten Abrechnungsdienst. Der empfohlene Rollout beginnt mit none zur Beobachtung, steigt schrittweise zu quarantine und endet bei der vollständigen Ablehnung, wobei pct stufenweise erhöht wird. Eine Reject-Richtlinie bei 100 % öffnet außerdem den Weg zu BIMI, dem Markenlogo, das in den Postfächern von Gmail und Yahoo angezeigt wird und ein striktes DMARC als technische Voraussetzung verlangt.
DMARC-Berichte lesen: rua und ruf
rua-Berichte kommen als komprimiertes XML an. Jeder Mailbox-Provider, der Post von der Domain erhalten hat, verschickt in der Regel einen pro Tag, mit einer Liste der sendenden IPs, des verarbeiteten Volumens, des SPF- und DKIM-Alignment-Ergebnisses und der angewendeten Richtlinie. Das manuelle Lesen bleibt für eine Domain mit zwei oder drei Absendern machbar. Ab einem Dutzend aktiver Subdomains und mehreren Versandplattformen macht die Menge an XML-Zeilen ein zeilenweises Lesen ohne dediziertes Parsing-Tool unrealistisch.
ruf-Berichte dagegen beschreiben eine konkrete E-Mail, die gescheitert ist, mit vollständigen Headern. Gmail und Yahoo verschicken sie nicht, aus Gründen des Schutzes der in diesen Headern enthaltenen persönlichen Daten. Nur eine Minderheit kleinerer Mailbox-Provider hält sie noch ein. Der vollständige Leitfaden zum Lesen eines aggregierten DMARC-Berichts, ohne sich zu vertun, erklärt das XML-Parsing Feld für Feld.
Was DMARC nicht abdeckt
DMARC schützt genau die im Eintrag veröffentlichte Domain, nicht mehr. Eine E-Mail, die von unternehmen-support.de statt unternehmen.de verschickt wird, eine optisch ähnliche, von einem Angreifer registrierte Domain, umgeht die gesamte Maßnahme vollständig: Kein SPF, DKIM oder DMARC deckt eine Domain ab, die dem Unternehmen nicht gehört. Dieses Typosquatting bleibt der häufigste blinde Fleck bei DMARC-Einführungen, auch bei solchen, die bereits auf p=reject stehen. Die vollständige Liste der Grenzen, vom Nachrichteninhalt bis zum Schutz nicht registrierter Domains, sollte bekannt sein, bevor intern verkündet wird, eine Domain sei nun geschützt.
Wer 2026 einen DMARC-Eintrag veröffentlichen muss
Seit dem 1. Februar 2024 verlangt Google eine ausgerichtete SPF- und DKIM-Authentifizierung, plus einen DMARC-Eintrag mindestens auf p=none, für jeden Absender, der 5.000 oder mehr Nachrichten innerhalb von 24 Stunden an private Gmail-Konten sendet. Microsoft folgte ab dem 5. Mai 2025 bei Outlook.com, Hotmail und Live.com: Oberhalb derselben Schwelle werden nicht authentifizierte E-Mails direkt auf SMTP-Ebene mit dem Enhanced Status Code 550 5.7.15 abgelehnt, statt in den Spam-Ordner umgeleitet zu werden. Die über die Feedback-Loops der Mailbox-Provider gemeldete Complaint Rate muss unter 0,3 % bleiben, empfohlen wird ein Schwellenwert unter 0,1 %, um eine verschärfte Filterung zu vermeiden.
Google gibt an, dass die Schwelle von 5.000 Nachrichten über ein gleitendes 24-Stunden-Fenster bewertet wird: Ein Absender, der sie auch nur einmal überschreitet, unterliegt denselben Anforderungen, als würde er sie jeden Tag erreichen.
Unterhalb dieser Schwelle besteht keine rechtliche Pflicht, DMARC zu veröffentlichen. Aber eine aktive B2B-Domain bleibt, selbst bei geringem Volumen, ein bevorzugtes Ziel für Identitätsdiebstahl: Die betrügerische Rechnung, die auf einen Lieferanten abzielt, kümmert sich nicht um das Versandvolumen des Opfers. Noch ein Tool mehr im Stack, werden manche sagen, wenn sie feststellen, dass sie auch die Hard-Bounce-Rate und die Sender Reputation der Domain im Blick behalten müssen. DMARC ersetzt nichts von dem, was bereits existiert. Es nutzt vor allem Daten, die bereits in Google Postmaster Tools vorliegen. Die Mailingliste zu bereinigen, elementare List Hygiene, bevor die Richtlinie in Richtung DMARC-Reject verschärft wird, verhindert, eine zurückgewiesene Adresse mit einem falsch diagnostizierten Alignment-Fehler zu verwechseln, eine Verwechslung, die den Rollout in den meisten beobachteten Fällen um mehrere Wochen verzögert.
Wie lange ist es her, dass der rua-Bericht dieser Domain zuletzt gelesen wurde?
