DMARC auf quarantine und reject umstellen: sicher weg von p=none, ohne echte Mails zu verlieren

1. Worum p=none, quarantine und reject die Empfänger bitten

Das Tag p im DMARC-Eintrag unter _dmarc.example.com sagt, wie Empfänger mit Mail umgehen sollen, deren From-Domain an DMARC scheitert, bei der also weder SPF noch DKIM für eine dazu ausgerichtete Domain bestanden hat. Das ist eine Bitte, keine Anweisung. RFC 9989, der im Mai 2026 veröffentlichte DMARC-Standard, der RFC 7489 ablöst, überlässt die endgültige Entscheidung der lokalen Richtlinie des jeweiligen Empfängers.

Zwei Punkte prägen die Umstellung. Erstens schützt p=none für sich genommen nichts; es erzeugt Berichte, und das nur, wenn der Eintrag eine rua-Adresse enthält. Zweitens setzen nicht alle Empfänger die Richtlinie gleich um. RFC 9989 fordert sie auf, nicht allein deshalb abzuweisen, weil die Richtlinie reject lautet, und manche stellen solche Mail stattdessen unter Quarantäne. Dieselbe Änderung kann also bei jedem Postfachanbieter anders aussehen. Planen Sie die Umstellung als Folge kleiner, umkehrbarer Schritte statt als einen einzigen Schalter.

Die großen Postfachanbieter verlangen von Massenversendern bereits einen DMARC-Eintrag, akzeptieren aber p=none. Der Leitfaden zum SPF- und DMARC-Check fasst deren Vorgaben zusammen und erklärt jedes Tag des Eintrags.

2. DMARC-Sammelberichte (rua) richtig lesen

Erst die Sammelberichte machen eine sichere Umstellung möglich. Ergänzen Sie den Eintrag um eine Berichtsadresse, etwa rua=mailto:dmarc-reports@example.com. Empfänger, die Berichte versenden, schicken Ihnen dann eine komprimierte XML-Datei, meist für einen UTC-Tag, mit jeder IP-Adresse, die Mail mit Ihrer Domain im From verschickt hat, und dem jeweiligen Ergebnis. Das Format regelt RFC 9990. Ein Dateiname wie receiver.example!example.com!1791590400!1791676800.xml.gz nennt den berichtenden Empfänger, Ihre Domain sowie Beginn und Ende des Zeitraums als Unix-Zeitstempel.

Jeder <record> in der Datei fasst Nachrichten nach Quelle und Ergebnis zusammen. Auf diese Felder kommt es an:

Der Unterschied zwischen der letzten Zeile und policy_evaluated ist das Wichtigste, was Sie hier lernen können. Eine Newsletter-Plattform kann in auth_results ein DKIM-pass für mailer.example.net zeigen und trotzdem an DMARC scheitern, weil diese Domain nicht zu example.com ausgerichtet ist. Nur policy_evaluated zeigt, wie DMARC entschieden hat.

Werten Sie die Berichte über mehrere Wochen aus, nicht über einen Tag: Monatsrechnungen, Quartals-Newsletter und jährliche Verlängerungshinweise kommen in ihrem eigenen Rhythmus. Schon bei mäßigem Volumen ist rohes XML mühsam; ein Parser oder Berichtswerkzeug, das die Zeilen pro Tag nach Quelle, Alignment und Disposition gruppiert, macht die Auswertung praktikabel. Nicht jeder Empfänger verschickt Sammelberichte, eine ruhige Woche bedeutet also keine ruhige Domain. Liegt die rua-Adresse in einer anderen Organisationsdomain, muss diese einen Autorisierungseintrag wie example.com._report._dmarc.reports.example.net mit v=DMARC1 am Anfang veröffentlichen, sonst ignorieren die Empfänger die Adresse (RFC 9990, Abschnitt 4).

3. Alle legitimen Absender finden, bevor Sie durchsetzen

Durchsetzen ist nur dann sicher, wenn Sie jedes System kennen, das Ihre Domain in den From-Header schreibt. Bauen Sie die Liste von zwei Seiten auf: was die Organisation nutzt und was die Berichte zeigen. Typische Quellen:

• Die Mailplattform, mit der die Belegschaft täglich arbeitet.
• Marketing und Newsletter, einschließlich des alten Kampagnentools, in das sich noch jemand einloggt.
• Transaktionsmails aus Ihrer Anwendung: Registrierungsbestätigungen, Passwort-Resets, Belege.
• Geschäftsanwendungen: CRM, Rechnungsstellung und Zahlungen, Helpdesk, Personal und Recruiting, Kalender und elektronische Signatur.
• Formulare und Plugins der Website, die als noreply@example.com senden.
• Geräte und Skripte: Scanner, Monitoring-Alarme, geplante Jobs und eigene Relays.

Ordnen Sie dann jede Quelle aus den Berichten einem Listeneintrag zu. Eine Rückwärtsauflösung der IP-Adresse (dig +short -x 192.0.2.10) verrät oft den Anbieter, und dessen Dokumentation beschreibt den passenden SPF-include und die DKIM-Einrichtung. Halten Sie das Ergebnis in einer Tabelle wie dieser fest:

Um die letzte Zeile geht es bei der ganzen Übung. Sobald alle bekannten Quellen bestehen, ist das, was weiterhin scheitert, überwiegend gefälschte oder fehlkonfigurierte Mail, und genau die soll die Durchsetzung stoppen. Selten sendende Quellen werden am häufigsten übersehen. Fragen Sie deshalb Buchhaltung, Personalabteilung und Support nach ihren Werkzeugen, bevor Sie einem ruhigen Monat vertrauen.

4. SPF- und DKIM-Alignment: relaxed oder strict

DMARC ist bestanden, wenn SPF oder DKIM besteht und die geprüfte Domain zur From-Domain ausgerichtet ist. Ein ausgerichtetes Ergebnis genügt. Bei SPF wird der Umschlagabsender geprüft (RFC 7208), bei DKIM der Wert d= einer gültigen Signatur (RFC 6376). Die Tags aspf und adkim legen fest, wie genau beide übereinstimmen müssen:

• Relaxed (r, Standardwert): Beide Domains haben dieselbe Organisationsdomain, also sind bounce.example.com und news.example.com zu example.com ausgerichtet.
• Strict (s): Die Domains müssen identisch sein.

RFC 9989 ermittelt die Organisationsdomain per DNS Tree Walk: Es fragt _dmarc-Einträge vom vollständigen Namen aufwärts ab, statt wie RFC 7489 die Public Suffix List zu verwenden.

Laut RFC 9989 kommen nahezu alle Domaininhaber mit relaxtem Alignment aus. Striktes Alignment zerstört das verbreitete Muster einer eigenen Bounce-Subdomain je Anbieter. Behalten Sie daher den Standardwert, sofern Sie keinen konkreten Grund haben, etwa an Dienstleister delegierte Subdomains: Dort ließe relaxtes Alignment Mail, die für vendor.example.com authentifiziert ist, auch für example.com bestehen. Wie auch immer Sie sich entscheiden, machen Sie DKIM zum ausgerichteten Verfahren jeder Quelle. SPF bricht bei Weiterleitungen, weil der weiterleitende Server nicht in Ihrem Eintrag steht; eine DKIM-Signatur übersteht Weiterleitungen in der Regel, solange die Nachricht unverändert bleibt.

5. Stufenweise Einführung: pct ist gestrichen, nutzen Sie t=y

Ältere Anleitungen staffeln mit pct: p=quarantine; pct=10, dann 25, 50 und 100, damit die Richtlinie einen wachsenden Anteil der scheiternden Mail erfasst. Nach RFC 7489 erhielt Mail außerhalb der Stichprobe die nächstschwächere Richtlinie. RFC 9989 hat das Tag gestrichen; Anhang A.6 begründet das damit, dass andere Werte als 0 und 100 meist ungenau angewendet wurden und die Abweichung je nach Implementierung stark schwankte.

Die Streichung hat einen Haken. RFC 9989 weist Empfänger an, unbekannte Tags zu ignorieren. Ein Empfänger nach dem neuen Standard liest p=quarantine; pct=25 daher als schlichtes p=quarantine und wendet es auf alle scheiternde Mail an. Auf ein teilweises pct als Begrenzung können Sie sich nicht mehr verlassen.

Der Nachfolger ist das Test-Flag t. Mit t=y werden Empfänger gebeten, eine Stufe unter der veröffentlichten Richtlinie zu bleiben: p=quarantine; t=y wird wie none behandelt, p=reject; t=y wie quarantine. Die Berichte laufen wie gewohnt weiter, und ein Empfänger kann die Abweichung mit dem Grund policy_test_mode vermerken. RFC 9989 beschreibt t=y und t=n als Gegenstücke zu pct=0 und pct=100.

In der Übergangszeit implementieren manche Empfänger nur RFC 7489 und ignorieren t, neuere ignorieren dagegen pct. Weil pct=0 nach den alten Regeln und t=y nach den neuen dieselbe Behandlung verlangen, können Sie während des Tests beide veröffentlichen:

v=DMARC1; p=quarantine; t=y; pct=0; rua=mailto:dmarc-reports@example.com

Beobachten Sie die Berichte einige Wochen lang und entfernen Sie dann beide Tags, damit p=quarantine vollständig greift. Vor reject wiederholen Sie das Muster: p=reject; t=y; pct=0 bittet um Quarantäne, und mit dem Entfernen der beiden Tags wird die Abweisung aktiv.

Statt nach Prozentsatz können Sie auch nach Mailstrom staffeln. Eine Subdomain wie news.example.com kann einen eigenen DMARC-Eintrag tragen und früher oder später als die Hauptdomain in die Durchsetzung gehen; das Einführungsbeispiel in RFC 9989 selbst testet p=quarantine mit t=y zunächst auf einer Subdomain, bevor es verschärft.

6. Richtlinie für Subdomains: sp und np

Ein DMARC-Eintrag auf example.com deckt auch Subdomains ab, die keinen eigenen _dmarc-Eintrag haben. Zwei Tags erlauben eine von p abweichende Subdomain-Richtlinie:

Einige Regeln machen das Verhalten berechenbar. sp wirkt nur im Eintrag der Organisationsdomain; eine Subdomain mit eigenem Eintrag folgt dem p dieses Eintrags. np=reject zu setzen, während p noch auf none steht, ist ein risikoarmer erster Schritt: Gefälschte Mail von erfundenen Namen wie billing-support.example.com wird abgewiesen, und Empfänger ohne np-Unterstützung greifen einfach auf sp oder p zurück. Bevor Sie sich darauf verlassen, stellen Sie sicher, dass jede Subdomain, von der Sie tatsächlich senden, mindestens einen DNS-Eintrag hat und damit als existierend gilt. Und denken Sie daran, dass SPF nicht vererbt wird: Jeder Name, der als Umschlagabsender dient, braucht einen eigenen SPF-Eintrag, ganz gleich, was die DMARC-Richtlinie sagt.

7. Ein realistischer Zeitplan von p=none bis p=reject

Kein Zeitplan passt für jede Domain, und RFC 9989 warnt, dass es viele Monate an Berichten dauern kann, bis ein Domaininhaber bereit für die Durchsetzung ist. Für Domains, deren Nutzer an Mailinglisten schreiben, empfiehlt sie mindestens einen Monat mit p=none und ebenso lange mit p=quarantine, jeweils mit Vergleich der Ergebnisse, und rät solchen Domains selbst dann von reject ab. Eine Organisation mit einer Handvoll sendender Dienste könnte so planen:

Senken Sie vor jeder Änderung die TTL des TXT-Eintrags _dmarc, etwa auf 300 Sekunden, und zwar mindestens eine alte TTL-Periode im Voraus, damit ein Rückschritt die Resolver schnell erreicht. Ändern Sie den Eintrag am Wochenanfang, sagen Sie dem Support, worauf er achten soll, und führen Sie ein datiertes Protokoll aller veröffentlichten Werte. RFC 9989 verlangt von jeder Domain mit p=reject, ihre Mail mit gültigen DKIM-Signaturen zu versehen, statt sich allein auf SPF zu stützen. reject ist nicht das einzige gute Ziel: Für eine Domain, die Ihre Belegschaft auf Mailinglisten nutzt, kann eine gut überwachte Quarantäne die bessere Wahl sein, während eine Domain nur für Rechnungen und Benachrichtigungen ein klarer Kandidat für reject ist.

8. Wenn legitime Mail scheitert: analysieren, beheben, zurückrudern

Früher oder später zeigt ein Bericht oder eine Kollegin legitime Mail, die scheitert. Suchen Sie die passenden Zeilen in den Sammelberichten, oder lassen Sie sich die vollständigen Header einer betroffenen Nachricht geben und lesen Sie den Header Authentication-Results. Vergleichen Sie dann das Muster:

Ist der Fehler groß oder trifft er umsatzrelevante Mail wie Belege und Passwort-Resets, rudern Sie zuerst zurück und analysieren danach: Ergänzen Sie t=y und pct=0 oder kehren Sie zur vorherigen Richtlinie zurück. Mit kurzer TTL erreicht die Änderung die meisten Resolver binnen Minuten. Eine 5xx-Abweisung ist endgültig; bereits abgewiesene Mail wird also nicht nachträglich zugestellt. Sagen Sie dem betroffenen Team, welche Nachrichten erneut verschickt werden müssen. Beheben Sie dann die Quelle, prüfen Sie über einige Tage an Berichten, dass sie besteht, und gehen Sie wieder einen Schritt vor. Weiterleiter und Listen, die Authentifizierungsergebnisse per ARC (RFC 8617) bewahren, helfen, doch RFC 9989 stellt fest, dass bislang keiner dieser Mechanismen weit verbreitet ist. DKIM auf jeder Quelle bleibt deshalb die verlässliche Lösung.

9. Den veröffentlichten DMARC-Eintrag prüfen

Prüfen Sie, was tatsächlich veröffentlicht ist, nicht was die DNS-Oberfläche anzeigt:

dig +short TXT _dmarc.example.com
nslookup -type=TXT _dmarc.example.com
dig +short NS example.com
dig +short TXT _dmarc.example.com @ns1.example.net

Die ersten beiden Zeilen zeigen, was Resolver zurückgeben; die letzte fragt direkt einen autoritativen Server ab und zeigt eine Änderung, bevor zwischengespeicherte Antworten ablaufen. Stellen Sie sicher, dass

• genau ein TXT-Eintrag unter _dmarc mit v=DMARC1 beginnt; bei zweien verwerfen die Empfänger beide, und die Domain verhält sich, als hätte sie keinen DMARC-Eintrag;
• v=DMARC1 das erste Tag ist und p den Wert none, quarantine oder reject hat;
• das rua-Postfach existiert und, falls es in einer anderen Domain liegt, mit einem _report._dmarc-Eintrag autorisiert ist;
• die Tags durch Semikolons getrennt sind, ohne typografische Anführungszeichen oder verirrte Zeichen aus einem Dokument.

Senden Sie anschließend von jedem Dienst eine Nachricht an ein Postfach, das Sie kontrollieren, und lesen Sie den Header Authentication-Results: dmarc=pass zusammen mit Ihrer From-Domain ist das Urteil des Empfängers, und darauf kommt es an.

Für einen schnellen Blick von außen liest der kostenlose SPF- und DMARC-Checker für Ihre DNS-Einträge den _dmarc-Eintrag des exakt eingegebenen Hostnamens, ohne auf die übergeordnete Domain zurückzugreifen. Er meldet einen fehlenden Eintrag (mittel, wenn der Host MX-Einträge hat) und p=none (niedrig, als Beobachtungsmodus); quarantine und reject lösen kein Signal aus. Ihre Berichte liest er nicht, und sp, np, t, pct, rua und Alignment bewertet er nicht. Dieselbe Mail-DNS-Prüfung liest auch SPF, MTA-STS und CAA und ist eine der acht passiven Prüfungen im kostenlosen Launch-Readiness-Snapshot, der ohne Anmeldung auskommt und einen Score mit einem Ergebnis je Prüfung liefert. Für die laufende Kontrolle lesen Sie den Leitfaden zur E-Mail-Authentifizierung im DNS.