DMARC-Policy: none, quarantine oder reject – wann umstellen

_dmarc  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@beispiel.at"
_dmarc  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@beispiel.at"
_dmarc  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@beispiel.at"

Drei Einträge für _dmarc.beispiel.at, die sich in einem Wort unterscheiden. Das Wort nach p= sagt dem empfangenden Server, was er mit einer Mail tun soll, die angeblich von deiner Domain kommt, aber DMARC nicht besteht: bei none nichts Besonderes, bei quarantine als verdächtig behandeln, bei reject abweisen. Umgestellt wird, wenn die Berichte belegen, dass jeder eigene Versandweg besteht, und keinen Tag früher.

Die Richtlinie ist eine Bitte an den Empfänger, kein Befehl. RFC 9989, der aktuelle DMARC-Standard, sagt ausdrücklich, dass die endgültige Behandlung jeder Mail Sache des Empfängers bleibt. Er darf eine Mail trotz p=reject annehmen, und ohne weitere Anhaltspunkte soll er sie sogar nur wie bei quarantine behandeln. Derselbe Standard hält aber auch fest, dass sich in der Praxis kaum ein Empfänger daran hält: Weitergeleitete Mails werden wegen p=reject „häufig abgewiesen“. Wer umstellt, muss also mit der strengen Auslegung rechnen.

Wofür sich die Mühe lohnt, zeigt CEO-Fraud: Gegen die gefälschte Chef-Mail mit der echten eigenen Adresse hilft nur eine wirksame Richtlinie. Wie man den Eintrag überhaupt anlegt, SPF und DKIM einrichtet und Berichte liest, steht in DMARC einrichten. Hier geht es nur um die Wahl der Stufe und den Zeitpunkt.

Was die drei Stufen beim Empfänger auslösen#

Bei Microsoft 365 hängt das an einer Einstellung in der Anti-Phishing-Richtlinie der empfangenden Organisation: Nur wenn dort „Honor DMARC record policy“ eingeschaltet ist, richtet sich Microsoft nach quarantine und reject. Ist sie aus, wendet Microsoft seine eigene Einstellung für gefälschte Absender an und übergeht, was im Eintrag steht. Die Spalte gilt also für die Empfänger, die mitspielen. Wie so ein abgewiesener Rückläufer aussieht und was die Codes bedeuten, steht in E-Mail abgelehnt: 550 5.7.1.

Für den Schutz deiner Domain zählt nur die untere Hälfte der Tabelle. Eine gefälschte Mail mit deiner Adresse landet bei p=none im Posteingang, sofern nicht ein anderer Filter anschlägt. Was das in der Praxis heißt, zeigt E-Mail-Spoofing.

Wann von none auf quarantine#

Die Frage ist nicht „wie lange“, sondern „was steht in den Berichten“. Google hält eine Woche Berichte meist für genug, damit alle Versandwege einmal vorkommen. RFC 9989 sagt, es könne je nach Versandrhythmus „viele Monate“ dauern. Beides stimmt, für verschiedene Domains: Wer nur aus dem Postfach schreibt, sieht nach einer Woche alles. Wer einmal im Quartal einen Newsletter verschickt und am Monatsende Rechnungen aus der Buchhaltung, muss mindestens einen Quartalsnewsletter und einen Monatsabschluss in den Berichten gesehen haben.

Umstellen kannst du, wenn diese vier Punkte erfüllt sind:

1. rua ist gesetzt, und die Berichte werden gelesen. Ohne Berichte gibt es nichts zu prüfen.
2. Jede Quelle, die du kennst, steht in den Berichten mit ausgerichtetem pass, bei SPF oder bei DKIM. Ein pass für die Domain eines Versanddienstes zählt nicht, die geprüfte Domain muss zu deiner passen.
3. Jeder Versandweg ist mindestens einmal vorgekommen, auch die seltenen: Jahresrechnung, Bewerbungsportal, Kontaktformular der Website.
4. Was noch scheitert, ist unbekannt oder weitergeleitet: fremde IP-Adressen, mit denen du nichts zu tun hast, oder Mailinglisten und Weiterleitungen. Das ist genau der Verkehr, den quarantine treffen soll.

RFC 9989 macht Punkt 2 zur Pflicht: Legitime Versandwege, die nicht bestehen, „MÜSSEN“ repariert sein, bevor eine strengere Richtlinie veröffentlicht wird.

Wann von quarantine auf reject, und wann nie#

Hier stellt RFC 9989 die schärfsten Bedingungen des ganzen Standards. Wer p=reject veröffentlicht, darf sich nicht allein auf SPF verlassen und muss jede Mail mit DKIM signieren. Der Grund sind Weiterleitungen: Eine Mail an eine Vereins- oder Absolventenadresse, die automatisch weitergeht, kommt beim Endempfänger von einer fremden IP-Adresse und besteht SPF nicht mehr. DKIM übersteht den Weg meist.

Die zweite Bedingung betrifft Menschen, nicht Technik. Domains, deren Nutzer auf Mailinglisten im Internet schreiben, sollen laut RFC 9989 p=reject nicht veröffentlichen. Wer es trotzdem will, soll vorher mindestens einen Monat p=none und ebenso lange p=quarantine laufen lassen und die Berichte beider Zeiträume vergleichen. Abgewiesene Listenmails haben eine hässliche Nebenwirkung: Die Listensoftware hält die Adressen der Empfänger für kaputt und trägt sie aus.

Für einen Betrieb mit Mitarbeitenden, die in Fachforen und Verbandsverteilern schreiben, ist quarantine deshalb oft die richtige Endstufe. Eine gefälschte Mail landet dann im Spam-Ordner, eine weitergeleitete echte auch, aber sie ist nicht verloren.

reject ist dagegen die richtige Wahl für jede Domain, die gar keine Mails verschickt. Microsoft empfiehlt für solche geparkten Domains genau v=DMARC1; p=reject;, ohne Berichtsadresse. Dazu gehört v=spf1 -all als SPF-Eintrag, beides steht in E-Mail-Spoofing.

Langsam hochfahren: pct, t und was davon übrig ist#

Wer die Hilfeseiten der großen Anbieter liest, bekommt drei verschiedene Ratschläge:

• Google empfiehlt, nach einer Woche none mit quarantine für einen kleinen Teil der Mails zu beginnen, etwa pct=10 bei kleinen und pct=1 bei großen Organisationen, und dann zu erhöhen.
• Microsoft schlägt die Stufen pct=10, 25, 50, 75 und 100 vor, erst bei quarantine, dann bei reject.
• RFC 9989 hat pct im Mai 2026 gestrichen. Begründung: Außer bei 0 und 100 sei der Wert in der Praxis „meist nicht genau angewendet“ worden, und die Abweichungen seien je nach Empfänger sehr unterschiedlich gewesen.

Was bleibt, ist der neue Tag t=y. Er bittet den Empfänger, die Richtlinie eine Stufe milder anzuwenden: p=reject; t=y wirkt wie quarantine, p=quarantine; t=y wie none. Berichte kommen trotzdem.

Ein Haken, den man kennen muss: RFC 9989 verlangt, dass ein Empfänger unbekannte Tags ignoriert. Ein Server, der nur den alten Standard kennt, überliest t=y also und wendet p=reject in voller Härte an. Wer sich auf t=y als Sicherheitsnetz verlässt, hat bei solchen Empfängern keines. Der verlässliche Weg nach oben sind deshalb die Stufen selbst, nicht Prozente und nicht Testschalter.

Subdomains: sp und np#

p gilt für die Domain und für alle Subdomains, solange nichts anderes dasteht. Zwei Tags ändern das:

• sp gilt für existierende Subdomains wie newsletter.beispiel.at.
• np gilt für Subdomains, die es gar nicht gibt. Neu in RFC 9989. Fehlt es, gilt sp, und fehlt auch das, gilt p.

Der gefährliche Eintrag sieht harmlos aus: p=reject; sp=none. Die Hauptdomain ist geschützt, aber rechnung.beispiel.at lässt sich weiter fälschen, und für Empfänger sieht so eine Adresse genauso vertrauenswürdig aus. Wer sp nicht bewusst braucht, lässt es weg.

Einen guten Grund gibt es: Ein Versanddienst, der noch nicht sauber eingerichtet ist, verschickt über eine eigene Subdomain. Microsoft rät ohnehin, Massenversand über eine Subdomain laufen zu lassen, damit Probleme dort nicht die Hauptdomain treffen. Diese Subdomain bekommt dann einen eigenen _dmarc-Eintrag und geht ihre Stufen getrennt.

Zurück ist erlaubt#

Ein Umstieg ist keine Einbahnstraße. Melden sich nach dem Umstellen Kunden, deren Mails im Spam-Ordner gelandet sind, oder fallen in den Berichten plötzlich eigene Server durch, geht der Eintrag eine Stufe zurück. Wie schnell das bei den Empfängern ankommt, bestimmt die TTL des Eintrags. Wer vor dem Umstellen die TTL auf eine Stunde senkt, kann im Notfall schnell zurück.

Messung: 146 Tiroler Domains#

In eigener Sache: In der Nacht auf den 04.10.2026 (23:28 UTC) habe ich die DMARC-Einträge von 149 Tiroler Domains abgefragt, 34 Tourismusverbände und 115 Betriebe aus meiner Akquise-Liste, passiv per DNS-over-HTTPS. Drei Domains gibt es nicht mehr, bleiben 146. Die Frage diesmal: Wer könnte überhaupt belegt umstellen?

• 67 haben keinen gültigen Eintrag, eine davon mit zwei Einträgen, was Empfänger wie keinen behandeln.
• 64 stehen auf p=none. 42 davon haben keine Berichtsadresse. Sie beobachten nicht, sie warten. Ohne Berichte gibt es nie den Beleg, dass alle Versandwege bestehen, also auch nie einen sicheren Zeitpunkt zum Umstellen.
• 22 stehen auf p=none mit rua. Das sind die Kandidaten für den nächsten Schritt, sofern jemand die Berichte liest.
• 15 haben eine wirksame Richtlinie, 5 quarantine und 10 reject. 7 der 15 haben keine Berichtsadresse und erfahren also nicht, ob eigene Mails abgewiesen werden. Bei 2 der 15 steht sp=none, ihre Subdomains sind offen.

Dazu zwei Kleinigkeiten. 4 Einträge tragen pct=50 oder pct=0, alle bei p=none, wo der Wert nichts bewirkt. t und np aus dem neuen Standard kommen in keinem einzigen Eintrag vor. Namen veröffentliche ich nicht. Wo die eigene Domain steht, zeigt der E-Mail-Check.

Was nicht hilft#

Mit reject anfangen, weil es am sichersten klingt. Jeder Versandweg, den niemand auf dem Zettel hatte, fällt ab dem ersten Tag durch, und ohne Berichte weiß niemand, welcher.

Auf none stehen bleiben, weil Gmail damit zufrieden ist. Google verlangt von Massenversendern einen DMARC-Eintrag und erlaubt ausdrücklich p=none, Schutz verlangt die Regel nicht. Gefälschte Mails mit deiner Adresse kommen weiter an.

Ein Kalenderdatum als Kriterium. „Nach vier Wochen auf quarantine“ passt für eine Domain, die täglich verschickt, und ist für eine mit Quartalsnewsletter zu früh.

sp=none, um die Hauptdomain „erst einmal“ zu schützen. Für Angreifer ist die Subdomain dann der bequemste Weg.

Häufige Fragen#

Welche DMARC-Policy ist die richtige?#

Am Anfang none mit rua, als Ziel quarantine oder reject. reject nur, wenn jede Mail mit DKIM signiert ist und niemand von der Domain auf Mailinglisten schreibt. Für Domains ohne Mailversand gleich reject.

Was passiert mit meinen Mails, wenn ich auf quarantine umstelle?#

Mit denen, die DMARC bestehen, nichts. Nur Mails, die weder ausgerichtetes SPF noch ausgerichtetes DKIM haben, landen bei Gmail im Spam-Ordner und bei Microsoft 365 im Junk-Ordner oder in der Quarantäne, je nach Einstellung des Empfängers.

Brauche ich pct noch?#

Nein. RFC 9989 hat pct gestrichen, weil Zwischenwerte unzuverlässig umgesetzt wurden. Google und Microsoft nennen es in ihren Anleitungen noch, verlassen sollte man sich darauf nicht. Schrittweise geht es über die Stufen.

Gilt die Policy auch für Subdomains?#

Ja, solange kein sp oder np etwas anderes sagt oder die Subdomain keinen eigenen _dmarc-Eintrag hat.

Wenn du es nicht selbst machen willst#

In eigener Sache: cyberscale bin ich, Stefan Haun aus Tirol. Das Paket E-Mail-Schutz wertet die DMARC-Berichte aus, ordnet jede Quelle einem Versandweg zu, repariert, was nicht besteht, und stellt die Richtlinie Stufe für Stufe um, mit Rückweg, falls etwas klemmt. Den Eintrag selbst erzeugt der DMARC-Generator, den Stand der Domain zeigt kostenlos der E-Mail-Check.

Stand 04.10.2026. Quellen an diesem Tag abgerufen, DNS-Messung in der Nacht auf den 04.10.2026.

Quellen#

• RFC 9989: DMARC (Mai 2026): Tags p, sp, np, t (Abschnitt 4.7), Pflicht zur Reparatur vor der Durchsetzung (5.1.6), Zeitbedarf (5.1.7), Ermessen des Empfängers (5.4), reject nur mit DKIM und nicht bei Mailinglisten (7.4), Streichung von pct (Anhang A.6), unbekannte Tags werden ignoriert (4.7, 4.8)
• RFC 7489: DMARC: Vorgänger mit pct
• Google: Recommended DMARC rollout: eine Woche none, Start mit pct=10 oder pct=1, Verhalten bei quarantine und reject
• Google: Email sender guidelines: DMARC-Eintrag für Massenversender, p=none genügt
• Microsoft: Set up DMARC to validate email in Microsoft 365: Stufen mit pct, Subdomains, geparkte Domains, Verhalten bei eingehenden Mails, action=oreject
• Microsoft: Anti-phishing policies, Spoof protection and sender DMARC policies: Einstellung „Honor DMARC record policy“
• Eigene Messung: DMARC-Einträge von 149 Tiroler Domains (34 Tourismusverbände, 115 Betriebe) am 03.10.2026 um 23:28 UTC per DNS-over-HTTPS (Cloudflare), passiv. Veröffentlicht werden nur Summen, keine Namen.