Grenzen und Risiken von DMARC: Was es nicht schützt und was es lahmlegen kann

Eine p=none-Richtlinie blockiert keine einzige Nachricht, während eine schlecht vorbereitete p=reject-Richtlinie legitime Mails ablehnt. Dazwischen lässt DMARC den Anzeigenamen und ähnlich aussehende Domains außen vor, und auch ein gekapertes Konto entgeht ihm. Kurz gesagt: Das Protokoll stoppt die exakte Fälschung der Absenderdomain und sonst nichts. Die Einführung dagegen riskiert verlorene Kundenmails und vergessene Drittabsender. Die Grenzen gleicht man mit anderen Werkzeugen aus, die Risiken beherrscht man durch einen schrittweisen Rollout.

Das Dashboard des Mailing-Tools zeigt „alles in Ordnung“, und die Kampagnen landen trotzdem im Spam: Die Authentifizierung gehört zu den ersten Stellen, die man prüfen sollte. Beim Betrug beziffert das FBI die Verluste durch Business Email Compromise auf 3,05 Milliarden Dollar (24.768 Beschwerden) in seinem IC3-Bericht 2025, gegenüber 2,77 Milliarden für 2024 (21.442 Beschwerden).

Was DMARC prüft

DMARC baut auf SPF und DKIM auf. Eine Nachricht besteht die Prüfung, wenn eines der beiden Verfahren erfolgreich ist und die authentifizierte Domain mit der Domain im From-Header übereinstimmt, einem durch RFC 5322 definierten Feld. Dieses Alignment entdecken die Teams meist als Letztes: Ein gültiges SPF für die Domain eines Dienstleisters genügt nicht, wenn die angezeigte Adresse Ihre eigene Domain trägt. Schlägt die Prüfung fehl, wendet der Empfänger die vom Domaininhaber veröffentlichte Richtlinie an: quarantine schickt die Nachricht in den Spam, reject lehnt sie ab, none unternimmt nichts.

Zwei Einstellungen legen die Strenge dieses Alignments fest. Standardmäßig gilt „relaxed“: mail.beispiel.de passt zu beispiel.de, weil beide dieselbe Organisationsdomain haben. Im Modus „strict“, gesetzt über adkim=s für DKIM und aspf=s für SPF, müssen beide Namen identisch sein. Strict schließt Lücken, bricht aber auch jeden Dienstleister, der mit einer Subdomain signiert, und das zeigt sich selten vor dem Wechsel auf reject.

Der Standard zieht seine Grenzen selbst. Seit Mai 2026 definiert die RFC 9989 (Standards Track der IETF) DMARC und ersetzt die RFC 7489 (März 2015) und die RFC 9091 (2021). Abschnitt 2.2 stellt klar, dass DMARC weder optisch ähnliche Domains noch den Missbrauch des lesbaren Absendernamens behandelt, und Abschnitt 2.4 ordnet Display-Name-Angriffe außerhalb des Geltungsbereichs ein. Der Text von 2015 sagte bereits dasselbe.

Display Name und Look-alike-Domains: zwei dokumentierte blinde Flecken

Eine Nachricht mit der Anzeige „Kundenservice Bank X“, gesendet von support@bank-x-sicherheit.com, besteht DMARC ohne Probleme. Die Absenderdomain gehört dem Angreifer, der dort sein eigenes SPF und seinen eigenen DKIM-Schlüssel veröffentlicht hat, daher sind SPF, DKIM und DMARC alle grün. Geprüft wird die technische Domain. Der Name, den das Mailprogramm hervorhebt, wird nicht untersucht.

Bei Look-alike-Domains (Typosquatting, zusätzliche Bindestriche, andere Endung) gilt dieselbe Logik: Ihr Eintrag schützt Ihre Domain, nicht die ähnlichen. Dagegen helfen die Beobachtung neu registrierter, ähnlicher Domains und Filter auf der Empfängerseite.

Ein gekapertes Konto besteht alle Prüfungen

Ein Postfach, dessen Zugangsdaten abgeflossen sind, sendet über die richtige Infrastruktur und mit der richtigen Signatur. Der Einstiegspunkt ist häufig Phishing oder ein Datenleck. DMARC hat dann nichts zu beanstanden, weil die Nachricht echt ist. Multi-Faktor-Authentifizierung und Warnungen bei ungewöhnlichen Anmeldungen setzen weiter vorn an, außerhalb des Protokolls.

Weiterleitungen und Mailinglisten: Das Alignment bricht unterwegs

Leitet ein Firmenalias oder eine Mailingliste eine Nachricht weiter, steht die IP des Relays nicht im SPF der ursprünglichen Domain, SPF schlägt daher in der Regel fehl. Bleibt DKIM, das überlebt, solange der signierte Inhalt unverändert bleibt. Eine Mailman- oder Listserv-Liste, die eine Fußzeile anhängt, macht die Signatur ungültig: Die legitime Nachricht fällt bei beiden Prüfungen durch.

Die RFC 9989 (Abschnitt 7.4) nennt als Beispiel eine Bank, deren Kunden eine Alumni-Adresse wie jones@alumni.example.edu angegeben haben, die an ein anderes Postfach weiterleitet: Die Nachricht kommt von der IP des Relays, die im SPF des Absenders fehlt (RFC 5321 von 2008, MailFrom), sofern nicht umgeschrieben wird. Die DKIM-Signaturen (RFC 6376 von 2011) bleiben dabei in der Regel gültig, solange der Nachrichtentext nicht verändert wird. Eine Mailingliste, die eine Fußzeile anhängt, macht sie ungültig.

Die RFC 9989 (Abschnitt 7.4, der auf die RFC 7960 von 2016 zu Mailinglisten verweist) leitet daraus zwei Empfehlungen ab: Eine Domain mit p=reject darf sich nicht allein auf SPF verlassen und muss mit DKIM signieren. Eine Domain, deren Nutzer an öffentliche Mailinglisten schreiben, sollte kein p=reject veröffentlichen. Das ARC-Protokoll (Authenticated Received Chain, RFC 8617 von Juli 2019) bewahrt das ursprüngliche Authentifizierungsergebnis, sofern das Relay es aktiviert hat.

Subdomains: Wer gewinnt, die Domain oder die Subdomain?

Die Subdomain gewinnt, sobald sie einen eigenen Eintrag veröffentlicht, andernfalls erbt sie vom Parent. Die RFC 9989 fasst das in zwei Regeln. Der Empfänger sucht zuerst einen Eintrag auf der exakten From-Domain und steigt dann im DNS-Baum nach oben (DNS tree walk, Abschnitt 4.10, auf 8 DNS-Abfragen begrenzt): Ein eigener Eintrag der Subdomain hat also Vorrang vor dem des Parents. Und ohne sp=-Tag gilt die p=-Richtlinie der Hauptdomain auch für Subdomains.

Praktische Folge: Ein _dmarc.newsletter.beispiel.de, das nach einem Test auf p=none stehen geblieben ist, lässt diesen Bereich in reiner Beobachtung, obwohl beispiel.de auf reject steht. Umgekehrt öffnet ein sp=none auf der Hauptdomain alle Subdomains ohne eigenen Eintrag. Während des Audits ist das nützlich, danach sollte es entfernt werden. Das sp=-Tag wird in einem auf einer Subdomain veröffentlichten Eintrag ignoriert. Seit der RFC 9091, die die RFC 9989 übernimmt, regelt außerdem ein np=-Tag den Fall von Subdomains, die im DNS gar nicht existieren.

p=none, der Beobachtungsmodus mit trügerischer Sicherheit

Der Eintrag existiert, die Konformitätsprüfung ist bestanden, doch nichts wird blockiert. Google hält auf seiner Seite zur Einführung (abgerufen am 27. Oktober 2026) fest, dass Nachrichten unter p=none normal zugestellt werden. Eine Domain, die jahrelang dort verbleibt, nimmt weiterhin gefälschte Nachrichten an.

p=reject: Legitime Mails, die verschwinden

Nach dem Wechsel auf reject werden alle Absender abgelehnt, deren SPF und DKIM nicht ausgerichtet sind. Die Personalabteilung verschickt Gehaltsabrechnungen über ein externes Tool, der Support läuft über ein Helpdesk, die Rechnungsstellung über ein SaaS-Modul: Jedes schreibt im Namen der Domain und wird am Tag der Umstellung abgelehnt, wenn es nicht ausgerichtet ist. Google sagt es ohne Umschweife: Nachrichten, die die Prüfung nicht bestehen, werden abgelehnt und nie zugestellt. Bei quarantine landen sie bestenfalls im Spam-Ordner. Die rua-Berichte des nächsten Tages listen dann die IPs mit fehlgeschlagenen Nachrichten auf, auch solche, die niemand erfasst hatte. Deshalb der Weg über quarantine und die Kennzeichnung der Testphase mit t=y, bevor reject folgt.

Die häufigste Falle sind Versanddienstleister. Bei einer gemeinsamen oder dedizierten IP validiert SPF die Domain des Dienstleisters. Das DMARC-Alignment hängt dann an einer DKIM-Signatur im Namen Ihrer Domain, es sei denn, ein eigener Return-Path ist eingerichtet. Ohne sie scheitert die Kampagne beim ersten Wechsel auf reject. Der DKIM-Schlüssel wird unter einem eigenen Selector veröffentlicht, in der Form selector._domainkey.beispiel.de, und die Signatur muss die Domain des From tragen.

TXT-Fehler und das SPF-Limit von 10 DNS-Abfragen

Ein Konfigurationsfehler genügt, um DMARC ohne Warnung außer Kraft zu setzen. Das DNS meldet ihn nicht: Der Eintrag wird ohne Validierung veröffentlicht, ein Tippfehler in der Zone fällt daher erst Tage später beim Lesen der Berichte auf. Ein in zwei falsch verbundene Strings zerlegter Eintrag, ein aus einer Textverarbeitung kopiertes typografisches Anführungszeichen oder ein vergessenes Semikolon zwischen zwei Tags reichen aus. Zwei DMARC-Einträge auf demselben Namen? Die RFC 9989 verwirft dann alle an dieser Stelle gefundenen Einträge (Abschnitt 4.10). Ein falsch geschriebenes v=DMARC1 lässt den ganzen Eintrag ignorieren, ein unbekanntes Tag wird ohne Warnung übergangen, ein Fehler in rua= entzieht Ihnen die Berichte, ohne sichtbar etwas zu zerstören. Eine Berichtsadresse auf einer anderen Domain verlangt zusätzlich einen Autorisierungseintrag bei dieser Domain (RFC 9990).

Auf der SPF-Seite begrenzt die RFC 7208 (Abschnitt 4.6.4) die Auswertung auf 10 DNS-Abfragen: include, a, mx, ptr, exists und redirect zählen, ip4 und ip6 nicht. Leere Abfragen sind auf 2 begrenzt. Darüber hinaus lautet das Ergebnis permerror (die Obergrenze stand bereits in der RFC 4408 vom April 2006), und SPF trägt nichts mehr zu DMARC bei. Jedes über ein include eingebundene Tool bringt die Domain näher an diese Schwelle.

Grenzen und Risiken in einer Tabelle

Von none zu reject, ohne Mails zu verlieren

Der Weg besteht aus drei Schritten: Absender erfassen, unter none beobachten, dann stufenweise über quarantine bis reject verschärfen. Am Anfang steht das Inventar der Absender: Mailing-Tool, CRM, Helpdesk, Gehaltsabrechnung, Rechnungsstellung, Anwendungsserver. Irgendeinen vergessen die Teams immer. Die aggregierten rua-Berichte helfen, ihn zu finden, denn sie listen jede IP auf, die im Namen der Domain gesendet hat, samt SPF- und DKIM-Ergebnis.

Die Schritte bleiben immer gleich: p=none, Berichte lesen, quarantine, dann reject. In der Google-Workspace-Hilfe empfiehlt Google, SPF und DKIM mindestens 48 Stunden vor dem Veröffentlichen von DMARC einzurichten, eine Woche bei p=none zu bleiben und die Berichte täglich zu lesen, dann auf quarantine für einen kleinen Prozentsatz der Nachrichten zu wechseln: 10 % für eine kleine Organisation, 1 % für eine große (Seite „Empfohlene DMARC-Einführung“). Ein Startwert sieht etwa so aus: v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@beispiel.de, als TXT auf _dmarc.beispiel.de veröffentlicht. Achtung: Das pct=-Tag der RFC 7489 gibt es in der RFC 9989 nicht mehr. Sie hält fest, dass es außerhalb der Werte 0 und 100 sehr uneinheitlich angewendet wurde, und ersetzt es durch t=y (Test) oder t=n. Die RFC 9989 selbst rät, p=none mindestens einen Monat lang zu veröffentlichen und sich dabei auf die aggregierten Berichte zu stützen.

Die Zeit pro Schritt hängt von der Zahl der Versandflüsse ab: Bei wenigen Quellen kann eine Woche Berichte genügen, um sie zu erfassen, bei 20 Tools tauchen vergessene Absender Bericht für Bericht auf. Während des Aufbaus erlaubt ein separates sp=, die Hauptdomain zu verschärfen, während nicht geprüfte Subdomains bei none bleiben.

Gmail, Yahoo und die Zustellbarkeit

Seit dem 1. Februar 2024 verlangt Google von Absendern, die mehr als 5.000 Nachrichten pro Tag an Gmail senden, gültiges SPF und DKIM sowie eine DMARC-Richtlinie, die auch auf none stehen darf. Die im Google Postmaster Tools angezeigte Spam-Rate muss unter 0,30 % bleiben, Zielwert unter 0,10 % (Richtlinien für Absender von Google). Yahoo, das seine Regeln seit Februar 2024 auf Massenversender anwendet, verlangt ebenfalls mindestens DMARC auf none, mit einer From-Domain, die an SPF oder DKIM ausgerichtet ist (Best Practices von Yahoo). Die Details zu Gmail finden Sie im Artikel über die Gmail-Anforderungen an Absender.

DMARC öffnet also die Tür zum Posteingang, legt aber die Absenderreputation nicht fest. Diese hängt von Beschwerderate und Bounces ab: Eine Domain auf reject, die an eine Liste voller toter Adressen sendet, erzeugt Hard Bounces und schadet ihrer Zustellbarkeit. Wer vor der nächsten Kampagne eine Stichprobe der Liste durch ein Verifizierungstool laufen lässt, sieht diese Rate, bevor Gmail sie misst.

Enthält Ihr nächster rua-Bericht eine Versandquelle, die im Team niemand kennt?