Steht in Ihrem TXT-Eintrag _dmarc noch ein pct=50-Tag? Er ist seit dem 20. Mai 2026 wirkungslos. An diesem Tag veröffentlichte die IETF DMARCbis in Form von drei RFCs: RFC 9989 für das Grundgerüst des Protokolls, ergänzt durch RFC 9990 und RFC 9991 für das Reporting, die offiziell die RFC 7489 aus dem Jahr 2015 ablösen (dmarc.org, Mai 2026). Das pct-Tag verschwindet, zwei neue Tags kommen hinzu, und die Methode zur Ermittlung der Organisationsdomain ändert sich grundlegend. Ein Rückgang der Delivery um 30 % in drei Monaten ohne inhaltliche Änderungen, während ein Emailing-SaaS weiterhin grünes Licht anzeigt, lässt sich manchmal auf eine nie überprüfte DNS-Konfiguration zurückführen statt auf den Kampagneninhalt. Für die Grundlagen des Protokolls, insbesondere das, was es nicht abdeckt, bleibt DMARC: 5 Dinge, die es nicht kann die Referenz. Hier geht es um die Umstellung selbst und darum, was korrigiert werden muss, bevor die großen Mailbox Provider (Google, Microsoft, Yahoo) ihre Parser darauf ausrichten.
Was ändert DMARCbis konkret gegenüber RFC 7489?
RFC 7489 trug seit ihrer Veröffentlichung 2015 den Status „Informational“: DMARC war im strengen IETF-Sinn nie ein Internet-Standard geworden. RFC 9989 korrigiert diesen Punkt. Das Protokoll wechselt in den Status Proposed Standard, die erste normative Stufe der IETF, und macht damit RFC 7489 sowie RFC 9091 – die experimentell gebliebene PSD-DMARC-Erweiterung – hinfällig. RFC 9990 regelt nun die aggregierten XML-Berichte; RFC 9991 deckt die Failure-Reports auf Nachrichtenebene ab. Alles basiert auf dem Entwurf draft-ietf-dmarc-dmarcbis-41, veröffentlicht am 4. April 2025, nach einer 2019 begonnenen Arbeit im Anschluss an die Fertigstellung des ARC-Protokolls.
Ein Punkt beruhigt eilige Administratoren: Der Wert v=DMARC1 ändert sich nicht. Ein 2019 veröffentlichter Eintrag funktioniert 2026 weiterhin, ohne Unterbrechung am Tag der Umstellung.
Die Tags, die DMARCbis streicht
Drei Tags verschwinden aus der Spezifikation, allen voran pct. Es sollte die Policy auf einen Prozentsatz des Traffics anwenden, litt aber unter einem seit Jahren dokumentierten Mangel: In der Praxis wurden nur die Werte 0 und 100 zuverlässig angewendet, während Zwischenwerte je nach Empfänger inkonsistentes Verhalten erzeugten (dmarcian, 2025). Ersetzt wird es durch ein binäres Tag, t, mit nur zwei Werten: t=y für den Testmodus, entsprechend dem früheren pct=0, und t=n für die vollständige Anwendung, entsprechend pct=100. Daneben entfallen rf, das Format der aggregierten Berichte, und ri, das Intervall zwischen den Berichten – beide wandern in die Reporting-Dokumente RFC 9990 und RFC 9991. Ein Eintrag, der noch eines dieser drei Tags enthält, funktioniert weiterhin, gilt aber als veraltet.
Die Tags, die DMARCbis hinzufügt
Das Tag np zielt auf einen realen blinden Fleck von RFC 7489: Subdomains, die im DNS gar nicht existieren. Ein Angreifer konnte bisher von fake.paiement.exemple.com aus versenden, ohne dass eine DMARC-Policy griff, da die Subdomain schlicht keinen abfragbaren Eintrag besaß (dmarcian, 2025). Mit np=reject oder np=quarantine schließt der Domain-Inhaber diese Lücke, ohne den Rest seines legitimen Traffics verschärfen zu müssen. Ergänzend übernimmt das Tag psd den Inhalt der früheren RFC 9091: Es markiert eine Domain als Public Suffix (psd=y) – eine Information, die den weiter unten beschriebenen Discovery-Mechanismus speist. Eine Domain, die auf BIMI-Anzeige in Gmail zielt, muss ohnehin über p=quarantine oder p=reject laufen: Die von np gebrachte Klarstellung ändert nichts an dieser bereits bestehenden Voraussetzung.
Die DNS-Baum-Suche ersetzt die Public Suffix List
Nehmen Sie mail.marketing.exemple.com. Unter RFC 7489 hing die Ermittlung der Organisationsdomain dieser Adresse von der Public Suffix List ab, einer manuell von Mozilla gepflegten, außerhalb des Standards aktualisierten und nie formell standardisierten Liste. Eine vergessene Registry oder eine neue, nicht gelistete TLD führte zu einem stillen falsch-negativen Ergebnis. RFC 9989 ersetzt diesen Mechanismus durch einen DNS Tree Walk: Der Empfänger fragt nacheinander mail.marketing.exemple.com, dann marketing.exemple.com, dann exemple.com, dann die TLD ab und stoppt, sobald er einen Eintrag mit psd=n (Organisationsdomain) oder psd=y (Public Suffix) findet. Der Algorithmus ist auf 8 DNS-Abfragen begrenzt, ein Wert, der in Abschnitt 4.10 der RFC selbst festgelegt ist. Die aggregierten Berichte von RFC 9990 fügen zwei bisher fehlende Felder hinzu: discovery_method und testing, die angeben, wie die Policy gefunden wurde und ob die Domain im Modus t=y läuft. Ein Administrator, der seine XML-Berichte liest, ohne diese beiden Felder je zu prüfen, muss sie in sein Dashboard integrieren.
Die Auswirkung auf das SPF- und DKIM-Alignment
Das Alignment funktioniert nach derselben Mechanik wie bisher: Vergleich der durch SPF oder DKIM authentifizierten Domain mit der Organisationsdomain der From-Domain. Was sich ändert, ist die Berechnung dieser Organisationsdomain, die nicht mehr aus einer externen Liste, sondern aus einer deterministischen DNS-Auflösung stammt. Bei einer Domain mit klassischem Schema, etwa exemple.com ohne exotische Unterebene, ändert sich nichts. Bei einer tiefen DNS-Struktur mit mehreren, von unterschiedlichen Einheiten verwalteten Subdomain-Ebenen kann das Ergebnis des Tree Walk von dem der PSL abweichen, besonders wenn eine Zwischenebene nun einen psd-Eintrag veröffentlicht. RFC 9989 stellt zudem einen Punkt klar, der faktisch schon galt, aber selten schriftlich festgehalten wurde: Das SPF-Alignment bezieht sich ausschließlich auf die MAIL FROM-Identität des SMTP-Kommandos, niemals auf die HELO-Identität. Eine Domain, die auf ein HELO-Alignment setzte, war in Wirklichkeit nie abgedeckt; die Klarstellung macht das nur explizit. Für die strukturellen Reibungspunkte des SPF-Protokolls selbst bleiben das Limit von 10 DNS-Lookups und die Folgen eines fehlenden SPF weiterhin relevant, DMARCbis hebt sie nicht auf.
Eine Grenze bleibt bestehen. Nach acht DNS-Abfragen liefert der Tree Walk kein Ergebnis mehr. Die RFC setzt dieses Limit, um Schleifen und Amplification-Angriffe zu verhindern, doch eine Architektur mit tiefer Delegation – ein DNS-Dienstleister, der auf einem weiteren aufsetzt – kann daran scheitern, noch bevor die eigentliche Organisationsdomain erreicht ist.
Welche DNS-TXT-_dmarc-Tags sind vor der Umstellung zu korrigieren?
Die IETF-Dokumentation gibt keine Frist vor, bis wann die großen Mailbox Provider (Google, Microsoft, Yahoo) ihre Empfangs-Parser auf DMARCbis umstellen. Die drei RFCs sind veröffentlicht; die Adoption auf Empfängerseite bleibt derzeit schrittweise und ohne festen Zeitplan. Den Eintrag jetzt zu korrigieren verhindert, ins Hintertreffen zu geraten, sobald einer der drei sein Standard-Parsing umstellt.
- Jedes pct=-Tag aus dem TXT-Eintrag _dmarc entfernen, unabhängig vom aktuellen Wert.
- rf= und ri= löschen, sofern vorhanden – zwei Parameter, die ein RFC-9989-konformer Empfänger nicht mehr liest.
- np=quarantine oder np=reject ergänzen, sobald die Hauptpolicy p= bereits angewendet wird, um die Lücke nicht existierender Subdomains zu schließen.
- Die Struktur der von externen Dienstleistern verwalteten Subdomains prüfen – Registry, Tochtergesellschaft, Zweitmarke – und bewerten, ob ein psd=y- oder psd=n-Tag auf einer Zwischenebene veröffentlicht werden muss.
- Den gewählten Modus t= dokumentieren, t=y im Test oder t=n in der vollständigen Anwendung, statt einen ererbten pct-Wert maßgeblich sein zu lassen.
Keine dieser Korrekturen erfordert das Kündigen oder Neukonfigurieren eines bestehenden SPF- oder DKIM-Eintrags. Die Arbeit bleibt auf das DMARC-Feld beschränkt, auch wenn sie dieselbe DNS-Zone betrifft wie die CNAME-Einträge, die bereits für andere Zwecke bestehen.
„Die als DMARCbis bekannten Änderungen und Verbesserungen sind nun offiziell: Das Protokoll wechselt auf den normativen Pfad der IETF“ (dmarc.org, Mai 2026).
Was die Umstellung für die Sender Reputation bedeutet
Das Bereinigen des DMARC-Eintrags löst nur einen Teil des Problems. Eine perfekt ausgerichtete Domain, die an eine verschlechterte Liste sendet, erzeugt weiterhin Rejects, aus einem anderen Grund: Die Hard-Bounce-Rate steigt, die Sender Reputation verschlechtert sich beim Gmail-Postmaster, und ein DMARC-Reject auf einer ansonsten sauberen Domain wird irgendwann als Spam-Signal gelesen statt als punktuelle Anomalie. Das ist der übliche Einwand: Eine Liste vor dem Versand zu prüfen kostet, da kann man ebenso gut hinterher filtern. Nur lässt sich ein DMARC-Reject nach der Authentifizierung nicht wie ein gewöhnlicher Soft Bounce im Sortierprozess auffangen – er schädigt die Reputation der IP, noch bevor diese Sortierung überhaupt stattfindet. Feedback Loops der Mailbox Provider und die Complaint Rate schlagen in der Regel aus, bevor Microsofts SNDS irgendetwas Auffälliges meldet. Eine schlecht vorbereitete DMARCbis-Umstellung, kombiniert mit einer nie bereinigten Liste, summiert beide Ursachen für Rejects, statt eine davon zu isolieren. Warum SMTP-Ablehnungen zunehmen und wie man sie senkt, hängt eng mit dem hier behandelten DNS-Eintrag zusammen. Der einzige Weg, herauszufinden, welche der beiden Ursachen stärker wiegt, ist, die Liste vor der nächsten Kampagne separat vom DNS-Eintrag gründlich zu prüfen.
Protokolle aktualisieren sich von selbst. DNS-Einträge nie.
