DMARC-Richtlinien eines Unternehmens in zehn Sekunden lesen (und was sie dir nicht verraten)

Eine DNS-Abfrage verrät dir, was ein Unternehmen den Mail-Servern der Welt geraten hat, mit gefälschter Mail in seinem Namen zu tun. Der Eintrag ist öffentlich, und der Befehl ist eine Zeile: dig +short TXT _dmarc.example.com. Was zurückkommt, ist eine kurze Reihe von Einstellungen, und darin ist eine Anweisung — p=none, p=quarantine oder p=reject — die die Vorliebe des Domain-Besitzers angibt, wenn eine Nachricht mit dieser Domain die Authentifizierung nicht besteht.

Die aktuelle Spezifikation, RFC 9989, im Mai 2026 als IETF Standards Track-Dokument veröffentlicht, ersetzte die ältere RFC 7489. Sie definiert die drei Werte bemerkenswert knapp:

• p=none — „Der Domain-Besitzer äußert keine Vorliebe."
• p=quarantine — „Der Domain-Besitzer hält solche Mail für verdächtig. Es ist möglich, dass die Mail legitim ist, obwohl der Fehler erhebliche Bedenken hervorruft."
• p=reject — „Der Domain-Besitzer hält alle solchen Fehler für einen klaren Hinweis darauf, dass die Verwendung des Domain-Namens nicht legitim ist."

Lies diese Worte noch mal, denn sie sind schwächer, als die meisten Erklärungen zu DMARC zugeben. Eine Richtlinie ist eine Vorliebe, die vom Sender für Empfänger veröffentlicht wird, um sie zu berücksichtigen. Sie ist keine Anweisung, die ein Empfänger ausführen muss. RFC 9989 sagt das in einem Satz: „Die abschließende Behandlung jeder Nachricht ist immer eine Frage der lokalen Richtlinie und wird dem Ermessen des Mail-Empfängers überlassen." Derselbe Abschnitt fügt beide Seiten der Konsequenz hinzu — Empfänger „KÖNNEN sich dafür entscheiden, eine Nachricht abzulehnen oder unter Quarantäne zu stellen, auch wenn sie die DMARC-Validierungsprüfung besteht", und sie „SOLLTEN NICHT Nachrichten allein wegen einer veröffentlichten Richtlinie von 'reject' ablehnen", genau damit legitime Mail, die auf Wegen versendet wird, die DMARC nicht beschreiben kann, und Mailing-Listen nicht zerstört werden.

Was gesteht p=none also wirklich ein? Weniger, als es gewöhnlich beschuldigt wird. In den Begriffen der Spezifikation ist es Monitoring Mode: Der Domain-Besitzer sammelt aggregierte Berichte und „äußert keine Behandlungsvorliebe für Nachrichten, die die DMARC-Validierung nicht bestehen", während ein Empfänger, der DMARC einsetzt, „kann dennoch" die Verwendung der Domain validieren. Was es nicht tut, ist etwas auf der Empfängerseite auszuschalten. Der Spam-Filter deines Anbieters, Reputations-Scoring, URL-Checks und Attachment-Analyse sind separate Maschinen, die unabhängig davon laufen, was der Sender veröffentlicht hat. Eine gefälschte Nachricht, die bei einer p=none-Domain ankommt, wird durch den Eintrag nicht in deinen Posteingang befördert; sie wird einfach dem Empfänger ohne erklärte Vorliebe übergeben, und der Empfänger entscheidet.

Das andere Missverständnis läuft in die andere Richtung. DMARC liest nicht den gefährlichen Teil einer Phishing-E-Mail. Seine eigene Spezifikation listet auf, was bewusst außerhalb des Geltungsbereichs liegt, und „content analysis" steht auf dieser Liste, in diesen Worten. Sie besagt auch, dass DMARC „nicht die Verwendung visuell ähnlicher Domain-Namen oder den Missbrauch des RFC5322.From-Anzeigenamens mit menschlicher Lesbarkeit adressiert" — die zwei Tricks, die die meiste Brand-Impersonation-Mail tragen. Und zum Wert eines bestandenen Tests: „Ein DMARC-Pass garantiert von selbst nicht, dass die Zustellung zum Posteingang des Empfängers sicher oder wünschenswert wäre." Eine ordnungsgemäß authentifizierte Nachricht von einer Wegwerf-Domain besteht DMARC sauber. DMARC beantwortet, wer berechtigt war, die Domain im From:-Header zu verwenden. Nichts weiter.

Das ist der Ort, an dem die Bulk-Sender-Regeln von 2024 regelmäßig falsch berichtet werden, auch in der ersten Fassung dieses Artikels. Googles Sender-Richtlinien erfordern von Sendern von 5.000 oder mehr Nachrichten pro Tag an Gmail-Konten, „DMARC-E-Mail-Authentifizierung für deine Sending-Domain einzurichten", und sagen dann im selben Atemzug: „Deine DMARC-Enforcement-Richtlinie kann auf none gesetzt werden." Yahoos eigenes Sender Hub, das separat gelesen werden muss, anstatt angenommen zu werden, dass es Google kopiert, gibt die Anforderung als „Veröffentliche eine gültige DMARC-Richtlinie mit mindestens p=none - DMARC muss bestehen" an und veröffentlicht überhaupt keine numerische Volumenschwelle. Beide Anforderungssätze traten im Februar 2024 in Kraft. Keiner zwingt jemanden weg von p=none. Was beide tatsächlich erzwingen, ist Authentifizierung, die sich deckt: Google erfordert, dass „die Domain im From:-Header des Senders entweder mit der SPF-Domain oder der DKIM-Domain übereinstimmen muss", und Yahoo sagt, dass entspannte Ausrichtung akzeptabel ist. Ausrichtung, nicht Severity, ist das Tor.

Was die echte Ursache dafür bleibt, dass Domains bei Monitoring verweilen, ist operativ statt feige. Ein Wechsel zu quarantine oder reject bedeutet, zuerst jeden Service zu finden, der Mail in deinem Namen versendet — Gehalt, Ticketing, Marketing, einen Helpdesk, den niemand dokumentiert hat — und jeden so zu authentifizieren, dass er sich deckt. Der Standard selbst erkennt die Gefahren an, die dies verlangsamen: Drittanbieter-Sender werden weder von DMARC vorgestellt noch ausgeschlossen, Weiterleitungen und Mailing-Listen können die Ausrichtung durch keinen Fehler des Senders brechen, und die Spezifikation zeigt Empfängern RFC 7960 für genau diese Fehlermodi. Eine Organisation, die p=none veröffentlicht und ihre Berichte liest, macht die Arbeit in der von der Spezifikation beschriebenen Reihenfolge. Eine, die p=none veröffentlicht und die Berichte ignoriert, nicht. Von außen kann der Eintrag allein dir nicht verraten, welche der beiden du anschaust.

Du brauchst kein Terminal zum Nachschlagen. Kostenlose Lookup-Tools — dmarcians Domain-Checker, MXToolbox's DMARC-Check — rufen den Eintrag ab und geben dir die Richtlinie aus. Mach es für deine Bank, deinen Gehaltsabrechnung-Anbieter, die Airline, mit der du fliegst. Lies nur die Antwort für das, was sie ist: eine Absichtserklärung des Domain-Besitzers, ein Input unter vielen in eine Entscheidung, die dein Mail-Provider auf eigene Faust trifft, über eine spezifische Art der Fälschung. Das ist eine wirklich nützliche Sache, die du in zehn Sekunden lesen kannst. Es ist kein Schiedsspruch darüber, ob die nächste Nachricht, die vorgeben soll, von dieser Brand zu stammen, sicher ist.

Korrektur, 20. Oktober 2026. Eine frühere Fassung dieses Artikels beschrieb p=none als die Zustellung von Fälschungen zum Posteingang und p=reject als die einzige Einstellung, die eine gefälschte Nachricht blockiert, sagte, dass die 2024 Google- und Yahoo-Bulk-Sender-Regeln Sender weg von p=none zwangen, und zitierte eine Zahl von ungefähr eine von drei Domains bei Enforcement. Die Richtlinienbeschreibungen wurden nach RFC 9989 korrigiert; Google und Yahoo akzeptieren tatsächlich p=none, wie oben aus ihrer eigenen Dokumentation zitiert; und die Enforcement-Zahl wurde entfernt, weil der zugrunde liegende Bericht seine Stichprobe oder seinen Nenner nicht veröffentlicht. Der Artikel gibt jetzt auch an, was DMARC nicht untersucht.