DMARC von p=none zu p=reject, sicher.

Warum schützt p=none Sie nicht wirklich?

Ein DMARC-Eintrag bei p=none sagt den empfangenden Servern, bei Nachrichten, die die Authentifizierung nicht bestehen, keine Handlung vorzunehmen. Jede Nachricht wird normal zugestellt, ob sie besteht oder fehlschlägt; die einzige Aufgabe des Eintrags ist, die Aggregatberichte zu erzeugen, die zeigen, wer Mail als Ihre Domain sendet. Das macht p=none zu einem Entdeckungswerkzeug, keiner Verteidigung — und eine Domain, die dauerhaft dort sitzt, sieht dem Spoofing zu, ohne es zu stoppen.

Das ist nicht theoretisch. Prüfen Sie eine Domain bei p=none, und ihre Berichte zeigen regelmäßig Mail von IPs in Ländern, in denen die Organisation keine Präsenz hat, gesendet über Server, die sie nie genutzt hat. Diese gefälschten Nachrichten werden von Empfängern als Spam markiert und als Phishing gemeldet, und Mailbox-Anbieter rechnen dieses Verhalten in die Reputation Ihrer Domain ein — sie unterscheiden nicht zwischen Mail, die Sie gesendet haben, und Mail, die ein anderer in Ihrem Namen gesendet hat. Bei p=none zu bleiben lässt diesen Schaden anwachsen.

Das Ausmaß der Lücke ist auffällig. Unter den Domains, die engagiert genug sind, ein Überwachungswerkzeug zu betreiben, sitzen rund vierzig Prozent dauerhaft bei p=none, und von den zehn Millionen Domains mit dem meisten Verkehr setzt nur ein kleiner Prozentsatz quarantine oder reject durch. Die Durchsetzung zu erreichen tut also mehr, als Sie zu schützen — es stellt Sie vor die überwältigende Mehrheit des Internets, die DMARC veröffentlicht, es aber nie eingeschaltet hat.

Die Drittanbieter-Versender, die die Durchsetzung brechen

Schlägt eine Migration fehl, ist die Ursache fast immer ein Versender, den Sie vergessen hatten. Die Berichte bringen sie ans Licht, aber nur, wenn Sie sie lesen: eine letztes Jahr hinzugefügte Marketing-Plattform, ein Helpdesk, der in Ihrem Namen sendet, ein Abrechnungssystem auf einem Altserver, die alte Domain einer Übernahme, die noch Rechnungen sendet. Jeder muss DKIM oder SPF mit Ausrichtung auf Ihre sichtbare From-Domain bestehen, bevor Sie die Richtlinie anziehen, und jeder neigt dazu, auf seine eigene, leise spezifische Weise zu scheitern.

SPF ist auf zehn DNS-Lookups begrenzt, und diese Decke ist leicht zu durchbrechen, wenn Sie Werkzeuge anflanschen. Fügen Sie ein CRM, einen Helpdesk, eine Marketing-Plattform und einen transaktionalen Anbieter hinzu, und die verketteten Includes können über zehn steigen, woraufhin SPF einen permanenten Fehler zurückgibt und direkt in DMARC-Fehler für legitime Mail kippt. Die Lösung ist, den Eintrag zu prüfen und zu glätten, ihn innerhalb des Limits zu halten und Anbieter, die aus eigenen Subdomains senden, ganz aus dem Root-SPF zu nehmen, wo die Plattform es erlaubt.

DKIM hat seine eigenen Fehlerarten, die sich verbergen, bis die Durchsetzung sie erwischt. Korrekt eingerichtete Signaturen brechen während einer Migration — ein Website-Anbieter wechselt, ein CRM wird getauscht, das DNS zieht zu einem neuen Host —, und niemand prüft, ob die DKIM-Einträge mitkamen. Einträge werden auf einer www-Subdomain statt auf der Root angewandt, TTL-Werte verursachen Validierungsfehler bei strengen Empfängern, und Anbieter-CNAME-Anweisungen sind schlicht falsch, bis der Anbieter korrigierte Werte ausstellt. Nichts davon zeigt sich, während Sie bei p=none sind; alles blockiert echte Mail in dem Moment, in dem Sie quarantine erreichen, was genau der Grund ist, warum die Überwachungsphase existiert.

Was ist mit Subdomains und den Tags sp und np?

Subdomains sind, wo viele Durchsetzungsprojekte still lecken. Lassen Sie den sp-Tag weg, erben Subdomains automatisch Ihre p-Richtlinie — eine Root bei p=reject lehnt also auch für jede Subdomain ab, was meist das ist, was Sie wollen. Die zu jagende Fehlkonfiguration ist das Gegenteil: p=reject gepaart mit sp=none, was Ihre Root-Domain sperrt, während jede Subdomain fälschbar bleibt. sp governs existing subdomains; np governs non-existent ones. Omit sp and subdomains inherit p. The p=reject with sp=none mismatch is the misconfiguration to watch.

DMARCbis fügt np für Subdomains hinzu, die gar nicht existieren. Ein Angreifer kann Mail von einer Subdomain fälschen, die Sie nie angelegt haben, und ohne np greift ein Empfänger für diese Namen auf Ihre sp- oder p-Richtlinie zurück. np=reject schließt diese Lücke, aber testen Sie es zuerst — manche Dienste erzeugen dynamische Subdomains, und ein pauschales np=reject kann legitime Mail erwischen, die Sie vergessen hatten. Unter dem neuen DNS Tree Walk finden Empfänger Ihre Organisations-Domain, indem sie den DNS-Baum hinaufgehen, statt die Public Suffix List zu konsultieren, was im Alltag nichts ändert, aber in tiefen Domain-Hierarchien zählen kann.

Ein Hinweis aus DMARCbis verdient direkte Erwähnung: The spec explicitly advises against p=reject for domains with active mailing-list traffic, to avoid breaking subscribers. Wenn Ihre Leute aus Ihrer Hauptdomain in Open-Source-Projektlisten, Branchenforen oder Verbands-Newsletter posten, kann ein volles reject diese Nachrichten für Abonnenten brechen. Die übliche Lösung ist, Listen-Verkehr aus einer dedizierten Subdomain mit eigener, sanfterer Richtlinie zu senden und die Root-Domain streng zu halten.

Eine DMARCbis-Falle verdient eine eigene Warnung, weil sie sorgfältige Administratoren überrascht. Der neue Test-Tag t=y soll Ihnen erlauben, „ich teste die Durchsetzung noch“ zu signalisieren, ohne die volle Richtlinie anzuwenden — aber er wirkt nur auf Empfängern, die DMARCbis bereits verstehen. Für die große Population von Empfängern, die 2026 noch die ältere Spezifikation fahren, ist t ein unbekannter Tag, also ignorieren sie ihn und wenden Ihr p=reject direkt an, ohne Senkung. Das Ergebnis sind zwei Empfänger-Populationen, die sich beim selben Eintrag unterschiedlich verhalten: manche behandeln Ihre Mail als Test, andere lehnen die Fehler rundheraus ab. Greifen Sie zu t=y in der Erwartung eines universellen sanften Starts, bekommen Sie keinen, und der sicherere Weg bleibt die operative Rampe — weisen Sie nach, dass Ihre Versender bestehen, und legen Sie sich dann auf die Richtlinie fest, statt auf einen Test-Tag zu vertrauen, dessen Wirkung davon abhängt, wer ihn liest.

Wo wir stehen

Wir hosten Versand-Infrastruktur, also zählt das Erreichen der Durchsetzung für uns: Mail, gesendet von sauberer, gut authentifizierter Infrastruktur, ist es, was eine reject-Richtlinie überhaupt erst sicher macht. Aber die Migration selbst ist Ihre, aus Ihren Berichten gesteuert, und der ehrliche Rat ist von der unglamourösen Art — gehen Sie langsam, korrigieren Sie Versender, bevor Sie anziehen, und rücken Sie nie eine Stufe vor, um eine Frist zu treffen. Eine zu p=reject getriebene Domain, die ihre eigenen Rechnungen blockiert, hat ihre Sicherheit nicht verbessert; sie hat einen Ausfall geschaffen.

Führen Sie Ihren Versand mit uns, sorgen wir dafür, dass Ihre Ströme SPF und DKIM mit Ausrichtung bestehen, und halten Ihre Reputation sauber genug, dass die Durchsetzung ein Nicht-Ereignis ist. Hosten Sie selbst oder senden über einen ESP, gilt dieselbe Abfolge, egal, wer die Server betreibt: veröffentlichen Sie p=none, lesen Sie die Berichte, korrigieren Sie jeden legitimen Versender, und ziehen Sie die Richtlinie nur an, wie die Daten es zulassen. Der Lohn am Ende ist echt — Spoofing gestoppt, Reputation geschützt und BIMI in Reichweite.