DMARC steht auf p=none: So kommen Sie sicher zu quarantine und reject

Die kurze Antwort: Stellen Sie nicht direkt auf reject um, sondern in drei Schritten. Fordern Sie zuerst Berichte an, werten Sie diese aus, bis alle echten Absender Ihrer Domain die Prüfung bestehen, und erhöhen Sie dann auf quarantine und zuletzt auf reject. Beginnen Sie mit einer Domain oder Subdomain, über die wenig verschickt wird. So beschreibt es auch Microsoft (Stand: Oktober 2026). Ein verbreiteter Fehler liegt schon vor dem ersten Schritt: In unserer Messung bei 3.380 Betrieben im Raum Karlsruhe fordern 874 von 1.096 Einträgen mit p=none keine Sammelberichte an, ihnen fehlt die Angabe rua. Jeder vierte gemessene Betrieb hat damit einen DMARC-Eintrag, der weder schützt noch berichtet. Dieser Beitrag behandelt nur den Weg von none zu reject. Was SPF, DKIM und DMARC grundsätzlich leisten, erklärt unser Grundlagenbeitrag zu SPF, DKIM und DMARC.

Was none, quarantine und reject bedeuten

Mit der Angabe p richtet der DMARC-Eintrag Ihrer Domain eine Bitte an die empfangenden Mailserver: Was soll mit Mails geschehen, die Ihre Domain als Absender tragen, die Prüfung aber nicht bestehen? RFC 7489 hat dafür in Abschnitt 6.3 drei Werte festgelegt. Die Nachfolgefassung RFC 9989 hat RFC 7489 abgelöst und die drei Werte beibehalten.

Alle drei Werte sind Bitten, keine Befehle. Die endgültige Entscheidung liegt laut RFC 9989 immer beim empfangenden Server. Er darf eine Mail trotz reject annehmen, etwa damit Verteilerlisten weiter funktionieren. Außerdem erfasst DMARC nur Fälschungen der exakten Domain. Ähnlich aussehende Domains und gefälschte Anzeigenamen deckt DMARC laut RFC 9989 ausdrücklich nicht ab. Die Richtlinie reject ist deshalb ein wirksamer Schutz für Ihre Domain, aber keine Garantie gegen jede gefälschte Mail.

Warum p=none ohne Berichtsadresse kaum etwas bewirkt

Ein Eintrag mit p=none darf an der bisherigen Behandlung der Mails nichts ändern, das schreibt RFC 9989 ausdrücklich vor. Was p=none Ihnen bringt, sind vor allem die Berichte. Die fordert der Eintrag aber nur an, wenn er die Angabe rua mit einer Empfangsadresse enthält. Fehlt rua, dürfen die empfangenden Server laut RFC 9989 keine Sammelberichte erzeugen. Folgerichtig spricht RFC 9989 nur dann vom Beobachtungsmodus („Monitoring Mode“), wenn p=none gesetzt ist und der Domaininhaber die Sammelberichte auch erhält. Die zweite Berichtsart, Einzelberichte über die Angabe ruf, verschicken laut Microsoft viele Empfänger nicht, Microsoft 365 selbst gar nicht.

Wie verbreitet das Problem ist, zeigt eine eigene Auswertung der Messdaten unserer Mail-Sicherheitsstudie. Wir haben die 3.380 Betriebe danach eingeteilt, was ihr DMARC-Eintrag tatsächlich leistet:

Von den 1.096 Einträgen mit p=none enthalten 874 kein rua, das sind 79,7 Prozent. Höchstens 222 Betriebe beobachten also wirklich. Ob ein solcher Eintrag bewusst so gesetzt wurde, lässt sich von außen nicht erkennen. Fest steht: Ohne Berichte fehlt die Grundlage, um sicher auf reject umzustellen. Von den 556 Betrieben mit Microsoft 365 haben 260 gar keinen DMARC-Eintrag, das sind 46,8 Prozent. Auf reject stehen dort laut Studie 16,2 Prozent.

Die Meldung „DMARC Quarantine/Reject policy not enabled“

Übersetzt heißt sie: „Richtlinie Quarantäne oder Ablehnen für DMARC nicht aktiviert“. Sie bezieht sich auf den öffentlichen DMARC-Eintrag Ihrer Domain und trifft zu, wenn er auf p=none steht, ebenso wenn es gar keinen gibt. In beiden Fällen bekommen empfangende Server keine Bitte, gefälschte Mails mit Ihrer Domain auszusortieren oder abzulehnen. Die Meldung ist berechtigt, sie verlangt aber keinen Schnellschuss: Wer ohne Auswertung von Berichten direkt auf reject stellt, riskiert, dass echte Mails abgelehnt werden. Prüfen Sie zuerst, ob Ihr Eintrag rua enthält, und gehen Sie dann die Schritte unten durch.

Nutzen Sie Microsoft 365, beheben Sie die Meldung nicht im Admin Center. Für eigene Domains bietet Microsoft 365 laut Microsoft weder ein Verwaltungsportal noch einen PowerShell-Befehl für den DMARC-Eintrag. Sie legen ihn bei Ihrem Domainanbieter oder DNS-Dienst an (Stand: Oktober 2026). Nur für die Domain auf onmicrosoft.com setzen Sie ihn im Microsoft 365 Admin Center.

So stellen Sie in drei Schritten um

Voraussetzung für alles Weitere: Für jede Domain und Subdomain, über die Sie Mails versenden, sind SPF und DKIM eingerichtet. Das setzt Microsoft vor dem DMARC-Eintrag voraus.

Schritt 1: Berichte anfordern

Legen Sie für die Berichte ein eigenes Postfach an. Microsoft rät zu einem gemeinsamen Postfach oder einer Gruppe in Microsoft 365, nicht zum Postfach einer einzelnen Person, und zu festen Zuständigen für die Auswertung. Dann ergänzen Sie den Eintrag um rua, die Richtlinie bleibt vorerst auf none:

Name:  _dmarc.beispiel.de
Typ:   TXT
Wert:  v=DMARC1; p=none; rua=mailto:dmarc@beispiel.de

Die Berichte kommen in der Regel einmal täglich von jedem meldenden Empfänger, als XML-Datei im Anhang, meist komprimiert. Sie zeigen, welche Server mit Ihrer Domain als Absender verschickt haben und ob diese Mails die Prüfung bestanden. Vollständig sind sie nicht: Nicht jeder Empfänger schickt Berichte, laut Microsoft decken sie typischerweise 70 bis 90 Prozent des Mailvolumens ab. Die Dateien sind zum Auslesen per Programm gedacht. RFC 9989 empfiehlt eine maschinelle Auswertung, Microsoft nennt eigene Auswertungen mit PowerShell oder Power BI und externe Dienste.

Ein Stolperstein: Liegt die Berichtsadresse unter einer anderen Domain, etwa bei einem Dienstleister für die Auswertung, muss diese Domain die Annahme mit einem eigenen TXT-Eintrag erlauben. Fehlt er, stellen die Empfänger die Berichte nicht zu.

Schritt 2: Berichte lesen und Lücken schließen

Gesucht sind echte Absender, die die Prüfung nicht bestehen. Kandidaten sind alle Dienste, die in Ihrem Namen senden, etwa ein Newsletter-Werkzeug, die Rechnungssoftware, der Webshop oder das Kontaktformular der Website. Genau dafür ist der Start mit p=none laut RFC 9989 gedacht: Schnell wird ein Server oder ein externer Versanddienst übersehen. Typische Muster beschreibt Microsoft so:

Lesen Sie die Berichte anfangs wöchentlich, später genügt laut Microsoft ein monatlicher Blick. Eine feste Mindestdauer für p=none nennt Microsoft nicht. RFC 9989 rät Domains, deren Nutzer an Mailinglisten schreiben könnten, von reject ab. Wer dort dennoch umstellt, soll vorher mindestens einen Monat p=none und ebenso lange quarantine auswerten. Achten Sie darauf, dass jeder wiederkehrende Versandanlass einmal in den Berichten aufgetaucht ist, etwa der monatliche Rechnungslauf oder ein Newsletter. Landen Mails eines Dienstes schon heute beim Empfänger im Spam, hilft unser Beitrag Mails landen im Spam: Ursache finden bei der Fehlersuche.

Schritt 3: erst quarantine, dann reject

Zeigen die Berichte keine echten Absender mit Fehlschlag mehr, erhöhen Sie auf quarantine. Microsoft empfiehlt, mit einer Domain oder Subdomain mit wenig Mailaufkommen oder wenigen Versandquellen zu beginnen und die Hauptdomain zuletzt umzustellen. Nach einer weiteren Beobachtungszeit folgt reject. Die Angabe rua bleibt stehen, damit Sie auch danach sehen, was passiert:

v=DMARC1; p=quarantine; rua=mailto:dmarc@beispiel.de
v=DMARC1; p=reject; rua=mailto:dmarc@beispiel.de

Zusätzlich nennt Microsoft die Möglichkeit, die strengere Richtlinie mit der Angabe pct schrittweise auf einen Teil der Mails anzuwenden, die die Prüfung nicht bestehen, etwa in den Stufen 10, 25, 50, 75 und 100 Prozent (Stand: Oktober 2026). Verlassen Sie sich auf diese Zwischenstufen nicht: RFC 9989 hat pct gestrichen, weil Empfänger andere Werte als 0 und 100 in der Praxis meist nicht genau umsetzten. Als teilweisen Ersatz führt RFC 9989 die Angabe t=y für einen Testbetrieb ein, bei dem der Empfänger eine Stufe milder verfährt. In Microsofts Anleitung taucht sie noch nicht auf. Planen Sie jede Stufe deshalb so, als gelte sie sofort für alle Mails.

Denken Sie an Subdomains: Ein DMARC-Eintrag gilt automatisch für alle Subdomains ohne eigenen Eintrag. Verschickt etwa ein Newsletter-Dienst über news.beispiel.de und ist dort noch nicht sauber eingerichtet, trifft ihn das reject der Hauptdomain mit. Mit einem eigenen Eintrag unter _dmarc.news.beispiel.de bekommt die Subdomain eine eigene Richtlinie.

Domains ohne Mailversand: direkt auf reject

Für Domains, von denen niemand Mails erwarten sollte, etwa Tippfehlervarianten oder alte Firmennamen, empfiehlt Microsoft direkt reject. Der DMARC-Eintrag liegt wie gewohnt unter _dmarc, der SPF-Eintrag direkt auf der Domain:

DMARC:  v=DMARC1; p=reject;
SPF:    v=spf1 -all

pct fehlt darin bewusst, der Standardwert ist 100. Berichtsadressen hält Microsoft hier für verzichtbar, weil von der Domain ohnehin keine echte Mail kommen soll. Der SPF-Eintrag berechtigt keinen einzigen Server zum Versand. Nutzen Sie Microsoft 365 und verschicken keine Mails über Ihre Domain auf onmicrosoft.com, gehört auch dort ein solcher DMARC-Eintrag hin.

In unserer Messung haben 369 der 3.380 Domains keinen MX-Eintrag. 350 davon, das sind 94,9 Prozent, haben weder SPF noch DMARC. Aber Vorsicht: Ein fehlender MX-Eintrag beweist nicht, dass über die Domain nichts verschickt wird, etwa vom Kontaktformular der Website. Setzen Sie p=reject ohne Beobachtung deshalb nur bei Domains, über die nachweislich gar keine Mail versendet wird.

Selbsttest: Wo steht Ihre Domain?

Mit unseren kostenlosen Werkzeugen sehen Sie in wenigen Minuten, in welcher Gruppe Ihre Domain liegt:

1. Im Domain-Check die Domain eingeben. Die Karte DMARC zeigt den Eintrag im Klartext und stuft ihn ein: „fehlt“, „Monitoring (p=none)“, „mittel (p=quarantine)“ oder „streng (p=reject)“. „Monitoring“ steht bei p=none auch ohne rua da. Ob Berichte angefordert werden, lesen Sie im angezeigten Eintrag: Fehlt dort rua=mailto:, kommen keine Sammelberichte.
2. Mit dem DMARC-Generator den nächsten Eintrag bauen: Domain eintragen, Schutzstufe wählen (Beobachten, Isolieren oder Ablehnen), Berichtsadresse eintragen, und Sie erhalten den TXT-Eintrag mit dem Namen _dmarc und Ihrer Domain zum Kopieren. Den Regler für den Anteil (pct) lassen Sie auf 100 Prozent, dann fehlt pct im Eintrag. Der Generator läuft im Browser und sendet oder speichert nichts.
3. Mit dem DKIM-Check prüfen, ob DKIM veröffentlicht ist, bei Microsoft 365 unter den Selektoren selector1 und selector2. Kennen Sie den Selektor eines Dienstes nicht, testet der Check auf Knopfdruck gängige Namen.
4. Das Ergebnis mit der Region vergleichen: Die Mail-Sicherheitsstudie nennt die Werte je Kreis.

Je nach Kreis haben zwischen 21 Prozent (Pforzheim und Enzkreis) und 27 Prozent (Stadt Karlsruhe) der gemessenen Betriebe eine wirksame Richtlinie.

Die Reihenfolge zum Abhaken

1. Alle Domains und Subdomains auflisten, auch ungenutzte und die Domain auf onmicrosoft.com.
2. Für Domains ganz ohne Versand v=DMARC1; p=reject; und v=spf1 -all setzen.
3. Für jede aktive Domain alle Versanddienste erfassen und SPF und DKIM einrichten.
4. Berichtspostfach anlegen, rua eintragen, p=none setzen.
5. Berichte anfangs wöchentlich lesen und Lücken schließen, bis alle echten Absender bestehen.
6. Auf p=quarantine erhöhen, zuerst bei einer Domain oder Subdomain mit wenig Versand.
7. Auf p=reject erhöhen, die Hauptdomain zuletzt.
8. Berichte weiter lesen und neue Versanddienste vor dem ersten Versand einrichten.

Häufige Fragen

Gehen mit p=reject echte Mails verloren?

Das kann passieren, wenn ein echter Absender die Prüfung nicht besteht, etwa ein Dienst ohne passendes SPF oder DKIM. Deshalb kommen die Berichte vor der Umstellung. Auch weitergeleitete Mails und Verteilerlisten können an DMARC scheitern, einzelne Fehlschläge lassen sich laut Microsoft kaum ganz vermeiden.

Stoppt p=reject jede gefälschte Mail mit unserer Domain?

Nein. Die Entscheidung trifft immer der empfangende Server, und er darf eine Mail laut RFC 9989 trotz reject annehmen. DMARC erfasst außerdem nur die exakte Domain, ähnlich aussehende Domains und gefälschte Anzeigenamen deckt es nicht ab. Für diese Maschen braucht es weitere Schutzmaßnahmen.

Wie lange dauert der Weg von p=none zu reject?

Eine Mindestdauer nennt Microsoft nicht, RFC 9989 nur für Domains, deren Nutzer an Mailinglisten schreiben könnten: vor reject mindestens einen Monat p=none und ebenso lange quarantine. Laut RFC 9989 kann es je nach Versandrhythmus viele Monate dauern, bis ein Domaininhaber sicher ist, dass alle seine Mails die Prüfung bestehen. Den Takt geben die Berichte vor: Umgestellt wird erst, wenn alle wiederkehrenden Versandanlässe darin sauber erscheinen.

So unterstützt Sie die High5Manufaktur GmbH

Die High5Manufaktur GmbH richtet SPF, DKIM und DMARC für Ihre Domains ein, erfasst mit Ihnen alle Dienste, die in Ihrem Namen senden, wertet die Berichte aus und begleitet die Umstellung Schritt für Schritt bis reject. Ungenutzte Domains sichern wir auf Wunsch gleich mit ab. Mehr dazu finden Sie bei unserer Leistung E-Mail-Sicherheit. Wo Ihre Domain heute steht, zeigen Domain-Check und DKIM-Check in wenigen Minuten. Im kostenlosen Erstgespräch klären wir, welche Ihrer Domains zuerst an der Reihe sind.

Quellen

• High5Manufaktur GmbH, Mail-Sicherheitsstudie Raum Karlsruhe 2026, Erhebung 24.09.2026, dazu eigene Auswertung der Messdaten, abgerufen am 22.10.2026, https://h5m.de/mail-sicherheit-studie
• IETF, RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC), Mai 2026, abgerufen am 22.10.2026, https://www.rfc-editor.org/rfc/rfc9989
• IETF, RFC 9990: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) Aggregate Reporting, Mai 2026, abgerufen am 22.10.2026, https://www.rfc-editor.org/rfc/rfc9990
• RFC Editor, RFC 7489: Domain-based Message Authentication, Reporting, and Conformance (DMARC), März 2015, abgelöst durch RFC 9989, 9990 und 9991, abgerufen am 22.10.2026, https://www.rfc-editor.org/rfc/rfc7489
• Microsoft Learn, Set up DMARC to validate email in Microsoft 365, Stand 03.07.2026, abgerufen am 22.10.2026, https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dmarc-configure
• Microsoft Learn, Set up SPF to identify valid email sources for your Microsoft 365 domain, Stand 03.07.2026, abgerufen am 22.10.2026, https://learn.microsoft.com/en-us/defender-office-365/email-authentication-spf-configure
• Microsoft Learn, How to use DKIM for email in your custom domain, Stand 03.07.2026, abgerufen am 22.10.2026, https://learn.microsoft.com/en-us/defender-office-365/email-authentication-dkim-configure