DMARC auf p=none: warum der Beobachtungsmodus zum Dauerzustand wird

Ab Februar 2024 tauchte in vielen DNS-Zonen derselbe Eintrag auf: v=DMARC1; p=none. Google und Yahoo verlangten von Großversendern einen DMARC-Eintrag, Microsoft zog im Mai 2025 für Outlook.com nach, und allen dreien genügte die Richtlinie none. Der Prüfbericht wurde grün, das Thema galt als erledigt. Gedacht war der Eintrag als erster Schritt einer Einführung, die mit quarantine oder reject endet.

Im Herbst 2026 steht er bei einem großen Teil der Unternehmen unverändert da. Das liegt selten an der Technik. Der Schritt weg von none verlangt eine Entscheidung mit sichtbarem Risiko und unsichtbarem Nutzen, und die Grundlage dafür, die DMARC-Berichte, kommt entweder gar nicht an oder bleibt ungelesen. So wird der Beobachtungsmodus zu einem Zustand, in dem niemand beobachtet.

Was p=none leistet und was nicht

Eine DMARC-Richtlinie teilt empfangenden Mailservern mit, wie sie mit Nachrichten umgehen sollen, die im Namen einer Domain ankommen, aber weder per SPF noch per DKIM passend authentifiziert sind. Mit p=none äußert der Domaininhaber dazu keinen Wunsch. Eine Mail mit gefälschter Absenderdomain wird zugestellt wie ohne DMARC; gegen Absenderfälschung schützt der Eintrag nicht.

Sein Wert liegt in den Berichten. Die im Mai 2026 veröffentlichte Standardfassung RFC 9989 definiert den „Monitoring Mode“ als Zustand, in dem die Richtlinie none lautet, der Domaininhaber Aggregatberichte empfängt und deren Inhalt nutzt, um seine Mailströme nachzubessern. Ohne Berichtsadresse ist p=none nach dieser Definition kein Beobachtungsmodus, sondern ein Eintrag ohne Wirkung. Die Anti-Abuse-Organisation M3AAWG führt none in ihren Best Practices ausdrücklich als Übergangszustand, der so schnell wie möglich zu verlassen ist.

Warum die Absender-Regeln von 2024 den Stillstand fördern

Den Anstoß für die meisten Einträge gaben Zustellbarkeitsregeln, nicht Sicherheitsüberlegungen. Google verlangt seit dem 1. Februar 2024 von Absendern mit mehr als 5.000 Nachrichten pro Tag an Gmail-Konten einen DMARC-Eintrag und hält fest, die Richtlinie könne auf none stehen. Yahoo fordert von Großversendern „a valid DMARC policy with at least p=none“. Microsoft verlangt für Outlook.com seit dem 5. Mai 2025 ebenfalls mindestens p=none und weist nicht konforme Mails von Großversendern mit dem Code 550 5.7.515 ab.

Damit endete der äußere Druck genau dort, wo die eigentliche Arbeit begonnen hätte. Die Vorgabe war erfüllt, die Zustellung lief, kein Empfänger meldete Probleme. Ein Vorhaben, das mit einer erfüllten Anforderung abgeschlossen wird, bekommt keinen Folgetermin. Für viele mittelständische Domains, die weit unter der Schwelle von 5.000 Mails pro Tag liegen, gab es nicht einmal diesen Anlass; der Eintrag war eine Vorsichtsmaßnahme, die niemand weiterverfolgte.

Wie verbreitet der Dauerzustand ist

Wie oft der Übergang zur Endstation wird, lässt sich im DNS ablesen, denn jede Richtlinie ist öffentlich. Eine DNS-Messung bei knapp 10.000 deutschen Unternehmensdomains, die der Hamburger IT-Dienstleister kjello im Oktober 2026 veröffentlicht hat, zeigt das Ausmaß: Von 9.935 Unternehmensdomains mit E-Mail-Empfang, gemessen am 8. Oktober 2026, stehen 30,8 Prozent auf DMARC p=none. 42 Prozent der vorhandenen DMARC-Einträge schützen damit nicht, sie beobachten nur. Die volle Abweisung mit p=reject nutzen 20,7 Prozent. Der Schritt, p=none umzustellen, ist also bei einem großen Teil der Domains nie erfolgt.

Aufschlussreicher ist eine zweite Zahl derselben Messung: Eine Berichtsadresse (rua) tragen nur 46,4 Prozent aller gemessenen Domains. Ein erheblicher Teil der veröffentlichten DMARC-Einträge fordert also gar keine Berichte an. Die Stichprobe stammt aus Wikidata und bildet vor allem bekanntere Unternehmen ab; die Werte sind deshalb eher eine Obergrenze, und gemessen wurde nur, was im DNS steht, nicht, was Empfänger daraus machen.

Ein Eintrag, den niemand kennt

Wie weit die Werte auseinanderliegen, zeigt der Vergleich nach Mail-Anbieter. Je nachdem, bei welchem Anbieter die Postfächer einer Domain liegen, steht in der Messung zwischen rund 10 und knapp 86 Prozent der Domains auf p=none. Unter Firmen mit weniger als 50 Beschäftigten haben 37,5 Prozent gar keinen DMARC-Eintrag und weitere 36,8 Prozent nur p=none.

Woher ein einzelner Eintrag stammt, verrät das DNS nicht. Für die Praxis ist das zweitrangig: Wer die eigene Richtlinie nie gelesen hat, kann nicht sagen, ob sie eine Entscheidung abbildet. Ein Eintrag, den im Unternehmen niemand kennt, wird auch von niemandem überprüft. Am Anfang steht deshalb die Frage, ob überhaupt jemand im Unternehmen von dem Eintrag weiß und wohin seine Berichte gehen.

Die eigentliche Hürde: wer für die Rechnung im Spam geradesteht

Der Schritt von none auf quarantine ist technisch eine Zeile im DNS, organisatorisch eine Risikoentscheidung mit ungleicher Verteilung. Landet nach der Umstellung eine legitime Mail im Spam, etwa die Rechnung aus der Buchhaltungssoftware oder die Terminbestätigung aus dem Buchungssystem, ist der Schaden sichtbar und einer Person zuzuordnen. Der Nutzen bleibt unsichtbar: Eine gefälschte Zahlungsaufforderung, die nie bei einem Kunden ankommt, meldet niemand.

Hinzu kommt, dass die Zuständigkeit für den Versand selten an einer Stelle liegt. Die DNS-Zone verwaltet die Webagentur oder der Hoster, Microsoft 365 der IT-Dienstleister, den Newsletter das Marketing, die Rechnungsmails ein Fachverfahren mit eigenem Versanddienst. Jeder kennt seinen Teil, keiner das Ganze. Eine Entscheidung, die alle betrifft und niemandem gehört, wird vertagt.

Folgerichtig gehört sie auf die Ebene, die beide Risiken trägt: die Geschäftsführung oder eine von ihr benannte Person. Die BSI-Richtlinie TR-03182 lässt dabei wenig Spielraum. Sie erwartet quarantine oder reject, weil nur diese Richtlinien die Empfänger schützen, und nennt reject als langfristiges Ziel.

Berichte, die niemand liest

Die Grundlage für die Entscheidung wären die Aggregatberichte, die Empfänger an die rua-Adresse schicken. Sie zeigen je sendender IP-Adresse, wie viele Nachrichten im Namen der Domain ankamen und ob SPF und DKIM passend bestanden. Wer sie auswertet, findet jeden vergessenen Versender, bevor eine strengere Richtlinie ihn trifft. RFC 9989 nennt die Auswertung „essential“ für jede erfolgreiche Einführung und macht sie in Abschnitt 8 zur Pflicht für die volle Teilnahme an DMARC.

In der Praxis hakt es an drei Stellen. Die Berichte sind XML-Dateien, die laut RFC maschinell gelesen werden sollen; ein Postfach allein genügt nicht. Sie enthalten nach Auffassung des BSI personenbezogene Daten, die DSGVO-konform und innerhalb der EU zu verarbeiten sind, was die Wahl des Auswertungsdienstes einschränkt. Und wer die Adresse 2024 nur eingetragen hat, um eine Vorgabe zu erfüllen, hat selten festgelegt, wer das Postfach liest. Die TR-03182 verlangt dagegen, Berichte regelmäßig und zeitnah auszuwerten, und hält fest, dass DMARC allein für bessere Zustellraten ihre Anforderungen nicht erfüllt.

pct ist Geschichte: was RFC 9989 an der Stufung ändert

Für den schrittweisen Übergang war lange das pct-Tag vorgesehen. RFC 7489 begründete es 2015 damit, dass die Aussicht auf „alles oder nichts“ viele Organisationen davon abhalte, mit strenger Authentifizierung zu experimentieren. Google empfiehlt in seiner Anleitung zur DMARC-Einführung (Stand Oktober 2026) weiterhin genau das: quarantine zunächst für einen kleinen Prozentsatz, im Beispiel pct=5, dann schrittweise bis 100 Prozent.

RFC 9989, im Mai 2026 als Internet-Standard erschienen und Nachfolger von RFC 7489, hat pct gestrichen. Die Begründung in Anhang A.6: Werte zwischen 0 und 100 wurden in der Praxis meist nicht genau angewendet, und die Abweichungen schwankten stark zwischen den Implementierungen. Übrig bleibt der Testschalter t. Mit t=y wird eine Richtlinie eine Stufe milder angewendet, quarantine wie none, reject wie quarantine. Empfänger, die noch nach RFC 7489 arbeiten, kennen t allerdings nicht und übergehen es, wie beide Fassungen es für unbekannte Tags vorschreiben. Die Stufen eines Verfahrens sind deshalb Richtlinien und Zeiträume, keine Prozente.

Ein Verfahren mit Fristen statt einer Mutprobe

Der Ausweg aus dem Dauerzustand ist kein mutiger Entschluss, sondern ein Verfahren, das die große Entscheidung in kleine, überprüfbare zerlegt. Jede Stufe hat ein Kriterium, eine Mindestdauer und eine Person, die abzeichnet. Google rät, Berichte mindestens eine Woche zu beobachten, bevor quarantine kommt; RFC 9989 hält fest, dass es je nach Versandrhythmus viele Monate dauern kann, bis alle eigenen Mails sicher authentifiziert sind. Ein Beobachtungsfenster ohne Monatsabschluss sieht weder Rechnungs- noch Lohnläufe.

1. Zuständigkeit festlegen Eine Person beauftragt die DNS-Änderungen, verantwortet die Berichte und entscheidet über jede Stufe. Ohne diesen Namen beginnt keine Frist.
2. Versender inventarisieren Alle Systeme, die mit der Domain im Absender senden: Microsoft 365, Newsletter, Buchhaltung, Shop, Ticketsystem, Bewerberportal, Multifunktionsgeräte, Kontaktformulare. Für jedes gilt: SPF erfasst, DKIM-Signatur mit eigener Domain, Ansprechpartner bekannt.
3. Berichte auswerten rua auf ein Auswertungswerkzeug mit Verarbeitung in der EU richten, mindestens einen vollen Monatszyklus sammeln und jeden unbekannten Absender dem Inventar oder einem Missbrauch zuordnen.
4. p=quarantine setzen Erst wenn alle legitimen Ströme passend authentifiziert sind. Mindestens so lange halten wie die Beobachtungsphase, Berichte weiter wöchentlich prüfen.
5. p=reject setzen Wenn quarantine keine legitimen Fehlschläge mehr zeigt. Danach Berichte monatlich prüfen; jeder neue Versanddienst durchläuft vor dem Start die Schritte 2 und 3.

Der Rückweg gehört vor den ersten Schritt

Schwer macht die Entscheidung vor allem die Vorstellung, sie sei endgültig. Das ist sie nicht. Eine DMARC-Richtlinie ist ein TXT-Eintrag, ihr Rückweg eine weitere Zeile im DNS. Wie schnell er wirkt, bestimmt die Gültigkeitsdauer (TTL) des Eintrags, denn so lange dürfen Resolver den alten Wert zwischenspeichern. Wird die TTL des _dmarc-Eintrags einige Tage vor jeder Stufe auf wenige Minuten gesenkt, greift ein Rückweg entsprechend schnell.

Vorab festzulegen sind drei Dinge: welches Ereignis den Rückweg auslöst, etwa eine bestätigte legitime Mail im Spamordner eines Kunden; wer ihn ohne Rückfrage ausführen darf; und auf welche Stufe zurückgegangen wird, von reject auf quarantine, nicht gleich auf none. Die Folgen unterscheiden sich: Bei quarantine landen fehlschlagende Mails meist im Junk-Ordner und lassen sich dort wiederfinden, bei reject weist der Empfänger sie ab. Ein dokumentierter Rückweg macht aus einer Entscheidung, für die jemand geradestehen muss, eine Änderung mit bekanntem Ausgang.

Was die Umstellung nicht leistet

Eine durchgesetzte Richtlinie schützt genau die eigene Absenderdomain. Gegen ähnlich geschriebene Domains, übernommene Postfächer und gefälschte Anzeigenamen hilft sie nicht, und am Filter für eingehende Mails ändert sie nichts.

Auch ist reject nicht für jede Domain das richtige Ziel. RFC 9989 warnt, dass Domains, deren Nutzer an Mailinglisten im Internet schreiben, mit p=reject erhebliche Probleme verursachen können, weil Listen Nachrichten verändern und Signaturen brechen. Die M3AAWG empfiehlt reject, wo möglich, und quarantine in den übrigen Fällen. Für solche Domains ist quarantine ein vertretbarer Endzustand, none nicht.

Häufige Fragen

Wie lange sollte DMARC auf p=none bleiben?

So lange, bis die Aggregatberichte mindestens einen vollen Versandzyklus abdecken und alle legitimen Versender passend authentifiziert sind. Google nennt als Untergrenze eine Woche Berichtsbeobachtung, RFC 9989 bei Domains mit Mailinglisten-Nutzern mindestens einen Monat. Ein p=none ohne Berichtsadresse hat kein natürliches Ende, weil nichts beobachtet wird.

Kann eine Domain direkt von p=none auf p=reject umgestellt werden?

Technisch ja, ratsam ist der Zwischenschritt quarantine; RFC 9989 sieht ihn bei Domains mit Mailinglisten-Nutzern ebenso lange vor wie die Beobachtungsphase. Eine Ausnahme sind Domains, die gar keine Mails versenden: Für sie verlangt die BSI-Richtlinie TR-03182 sofort DMARC reject, dazu einen Null-MX und v=spf1 -all.

Funktioniert das pct-Tag noch?

RFC 9989 hat pct im Mai 2026 gestrichen und durch den Testschalter t ersetzt. Ältere Empfänger werten pct weiter aus, und Google empfiehlt es noch, doch Werte zwischen 0 und 100 wurden laut RFC 9989 schon bisher ungenau angewendet. Als verlässliche Bremse eignet es sich nicht.

Was passiert, wenn nach der Umstellung legitime Mails im Spam landen?

Dann greift der vorab festgelegte Rückweg um eine Stufe, etwa von quarantine auf none. Die Aggregatberichte zeigen die sendende IP-Adresse und ob SPF oder DKIM fehlschlug. Ist der Versender korrigiert, folgt der nächste Versuch. Mit gesenkter TTL wirkt der Rückweg schnell.

Reicht p=none für die Anforderungen von Google, Yahoo und Microsoft?

Ja. Google und Microsoft verlangen von Absendern mit mehr als 5.000 Mails pro Tag einen DMARC-Eintrag, Yahoo von Großversendern, und alle drei akzeptieren p=none. Die BSI-Richtlinie TR-03182 erwartet dagegen quarantine oder reject samt Berichtsadresse. Zustellbarkeit und Schutz vor Absenderfälschung sind zwei verschiedene Ziele.