DMARC von p=none auf p=quarantine umstellen, ohne legitime Mails zu verlieren

Ein DMARC-Eintrag mit p=none bittet die E-Mail-Provider, über Mails zu berichten, die die Authentifizierung nicht bestehen, sie aber wie gewohnt zuzustellen. Das ist der richtige Startpunkt und der falsche Dauerzustand: Jeder kann weiterhin Mails mit Ihrer Domain in der From-Zeile versenden, und die Empfänger haben von Ihnen keine Anweisung, solche Mails als verdächtig zu behandeln.

Mit p=quarantine teilen Sie den Empfängern mit, dass durchgefallene Mails als verdächtig gelten sollen, was in der Praxis meist den Spam-Ordner bedeutet. Das Risiko liegt nicht in der Änderung selbst. Das Risiko ist ein legitimer Dienst (Rechnungsstellung, Helpdesk, CRM, Newsletter), der am Tag der Umstellung DMARC noch nicht besteht, sodass Ihre eigenen Nachrichten im Spam landen.

Die kurze Antwort: Lesen Sie Ihre Aggregate-Reports, bis jeder legitime Absender mit ausgerichtetem (aligned) DKIM besteht, stellen Sie zuerst mit Testmodus auf p=quarantine um, vergleichen Sie die Reports und entfernen Sie dann den Testmodus. Die Details folgen. Wenn Sie die 3 Einträge kurz auffrischen möchten, lesen Sie SPF, DKIM und DMARC erklärt.

Was p=none wirklich bewirkt

DMARC ist heute in RFC 9989 definiert, veröffentlicht im Mai 2026, das RFC 7489 abgelöst hat. Es nennt p=none Monitoring Mode und erklärt, warum es diesen Modus gibt: Außer in den einfachsten Umgebungen kann ein Domaininhaber einen Server oder eine Versandvereinbarung mit einem Dienstleister übersehen, und die Reports decken das auf.

Der Wert quarantine bedeutet, dass der Domaininhaber durchgefallene Mails für verdächtig hält. Die endgültige Entscheidung bleibt beim Empfänger, bei den meisten E-Mail-Providern heißt das aber Spam-Ordner. Google beschreibt es in seiner empfohlenen DMARC-Einführung ganz direkt: Nachrichten, die DMARC nicht bestehen, landen im Spam-Ordner des Empfängers.

Schritt 1: Jeder legitime Absender muss bestehen

RFC 9989 ist bei der Reihenfolge eindeutig. Legitime Mailströme, die durchfallen, weil ihre Kennungen nicht ausgerichtet sind oder fehlen, MÜSSEN behoben werden, bevor Sie eine durchsetzende Policy veröffentlichen.

Gehen Sie Ihre Aggregate-Reports durch (unser Leitfaden DMARC-Aggregate-Report lesen erklärt das XML) und erfassen Sie jede Quelle:

• Ihr Haupt-Mailprovider: sollte mit ausgerichtetem DKIM und SPF bestehen.
• Jedes Drittanbieter-Tool, das unter Ihrer Domain sendet: Aktivieren Sie in dessen Einstellungen die DKIM-Signatur mit Ihrer eigenen Domain. Ein Tool, das SPF nur mit seiner eigenen Envelope-Domain besteht, ist nicht ausgerichtet und fällt bei DMARC durch.
• Weiterleitungen und Mailinglisten: Sie brechen häufig SPF. DKIM-Signaturen bleiben in der Regel gültig, wenn Mails weitergeleitet werden, ein weiterer Grund, sich auf DKIM zu stützen und nicht nur auf SPF.
• Unbekannte Quellen, die durchfallen: Genau diese soll die neue Policy stoppen.

Wie lange Sie beobachten, entscheiden Sie. Google empfiehlt mindestens 1 Woche mit p=none, da das in der Regel genügt, damit die Reports alle Ihre Mailströme abdecken. RFC 9989 weist darauf hin, dass es je nach Versandhäufigkeit viele Monate dauern kann. Denken Sie an Mails, die Sie einmal im Quartal oder einmal im Jahr versenden: Gehaltsmitteilungen, Jahresrechnungen, Verlängerungserinnerungen. Wenn diese noch nicht in Ihren Reports aufgetaucht sind, haben Sie sie noch nicht bestehen sehen.

Schritt 2: Zuerst mit Testmodus umstellen

Unter RFC 7489 war der übliche sanfte Einstieg das pct-Tag (die Policy nur auf einen Prozentsatz der durchgefallenen Mails anwenden). RFC 9989 hat pct entfernt, weil Empfänger andere Werte als 0 und 100 uneinheitlich umgesetzt haben. An seine Stelle tritt ein Testmodus-Tag, t:

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc-reports@example.com"

Mit t=y bitten Sie die Empfänger, 1 Stufe unter der angegebenen Policy anzuwenden. p=quarantine; t=y wird also wie none behandelt, während Zwischenstationen wie Mailinglisten ihren Umgang mit Ihren Mails bereits anpassen können. Am Reporting ändert das Tag nichts. Vergleichen Sie Ihre Reports vorher und nachher: Sie zeigen, wie viel Ihrer Mails über Weiterleitungen läuft, die bei durchgesetzter Policy durchfallen würden.

Manche Provider dokumentieren noch den älteren Prozent-Ansatz; Googles Einführungsleitfaden etwa nennt pct=5 als Startwert. Empfänger, die t noch nicht unterstützen, ignorieren das Tag einfach. Betrachten Sie den Testmodus deshalb als sanften Start, nicht als Sicherheitsnetz.

Schritt 3: Durchsetzen und weiter beobachten

Wenn die Reports im Testmodus sauber aussehen, entfernen Sie das Tag:

_dmarc.example.com.  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com"

In den ersten Wochen nach der Umstellung:

• Lesen Sie die Reports täglich und achten Sie auf disposition-Werte quarantine bei Quellen, die Sie kennen.
• Bitten Sie die Teams mit Kundenkontakt (Buchhaltung, Vertrieb, Support), Bescheid zu geben, wenn Antworten ausbleiben oder Kunden melden, dass Mails im Spam gelandet sind.
• Behandeln Sie jedes neue Tool, das unter Ihrer Domain sendet, als Änderungsantrag: DKIM mit Ihrer Domain, bevor es live geht.
• Halten Sie den DNS-Zugang übersichtlich. Ein DMARC-Eintrag, den ein hilfsbereiter Dienstleister stillschweigend auf p=none zurücksetzt, macht die Arbeit zunichte.

Subdomains und Domains, die nichts versenden

Ohne sp-Tag gilt die p-Policy auch für Subdomains. Wenn eine Subdomain Marketing-Mails über eine eigene Plattform versendet, prüfen Sie sie vor der Umstellung in den Reports oder geben Sie ihr einen eigenen _dmarc-Eintrag. Das np-Tag legt eine Policy für Subdomains fest, die gar nicht existieren, eine gängige Wahl für Namen, unter denen nie jemand senden sollte.

Domains, die Ihnen gehören, aber nie für Mails genutzt werden (alte Markennamen, defensive Registrierungen), sind der einfache Fall: Ohne legitime Absender können sie direkt auf eine durchsetzende Policy gehen. Gerade solche Domains sind für Betrug mit gefälschten Rechnungen attraktiv, weil niemand sie beobachtet.

Bevor Sie weiter zu p=reject gehen

p=reject ist der nächste Schritt, doch RFC 9989 ist bei Domains, deren Nutzer an Mailinglisten schreiben, zurückhaltend. Es empfiehlt, p=none mindestens einen Monat und danach p=quarantine ebenso lange zu betreiben und zuerst die Ergebnisse zu vergleichen. Große E-Mail-Provider erwarten DMARC bereits von Massenversendern, wie in Gmail- und Yahoo-Anforderungen an Absender beschrieben. Ein stabiles p=quarantine ist deshalb schon für sich eine solide Position.

Eine kurze Checkliste

• Aggregate-Reports lange genug gesammelt, um auch seltene Mailströme zu erfassen.
• Jeder legitime Absender besteht DMARC mit ausgerichtetem DKIM.
• p=quarantine; t=y veröffentlicht und Reports vorher und nachher verglichen.
• Testmodus entfernt, Reports in den ersten Wochen täglich gelesen.
• Subdomains und ungenutzte Domains mit sp, np oder eigenen Einträgen abgedeckt.

Wo Guarding ansetzt

Sobald Ihre Policy durchgesetzt ist, besteht das Hauptrisiko darin, dass sie unbemerkt zurückgesetzt wird. Wir beobachten Ihre SPF-, DKIM- und DMARC-Einträge und alles Weitere, was wir überwachen, täglich von außen, ohne in Ihre Systeme einzudringen. Wird ein Eintrag abgeschwächt oder verschwindet ein DKIM-Selektor, prüft das ein Mensch, und Sie erhalten die genaue Änderung, die nötig ist, wie unter was passiert, wenn wir etwas finden beschrieben. Das Beispiel-Dashboard zeigt, wie das aussieht.