Zusammenfassung

  • DMARC ergibt pass, wenn mindestens eine durch SPF oder DKIM authentifizierte Domain zur RFC5322.From-Domain ausgerichtet ist. Belegt wird die autorisierte Nutzung der Author Domain, nicht Local-Part, Anzeigename, Person oder Inhalt.
  • fail beweist nicht spiegelbildlich Betrug. Legitime Weiterleitungen und Mailinglisten können SPF-Ausrichtung oder DKIM-Signatur auf dem Weg zerstören.
  • p, sp und np sind angeforderte Behandlungspräferenzen. Der Empfänger behält seine lokale Entscheidung und darf eine bestandene Nachricht ablehnen oder eine fehlgeschlagene annehmen.

Das Entscheidende geschieht nach der Authentifizierung

Eine Organisation empfängt eine Nachricht, ordnet Reputation zu, untersucht Inhalt, berücksichtigt den Nutzer und entscheidet über Annahme, Quarantäne, Ablehnung oder Verzögerung. DMARC liefert wichtige Eingangsdaten für diese Entscheidung. Es trifft die Entscheidung nicht.

RFC 9989 erschien im Mai 2026 als Standards-Track-Dokument, löste RFC 7489 und 9091 ab und wurde von Todd M. Herr und John Levine gemeinsam redigiert. Schon die Einleitung definiert die Grenze: Ein DMARC-Pass zeigt ausschließlich, dass die Nutzung der Author Domain durch deren Domain Owner autorisiert war. Daraus folgt keine ausdrückliche oder stillschweigende Wertung der Nachricht oder des Eigentümers. Sichere oder wünschenswerte Inbox-Zustellung ist nicht garantiert.

Wer daraus ein allgemeines Vertrauenssiegel macht, verbessert nicht die Benutzeroberfläche. Er fügt dem Ergebnis eine unbelegte Behauptung hinzu.

Warum Authentifizierung noch Ausrichtung braucht

SPF prüft während der SMTP-Transaktion, ob der Client eine Domain in MAIL FROM oder HELO benutzen darf; DMARC verwendet die MAIL FROM-Domain. DKIM validiert eine Signatur und die zugehörige Signing Domain. Beide Mechanismen können erfolgreich sein, obwohl ihre Domain nicht der sichtbaren RFC5322.From-Domain entspricht.

DMARC extrahiert diese Author Domain und vergleicht sie mit authentifizierten Kennungen. Bei strikter Ausrichtung müssen die Domains identisch sein. Bei gelockerter Ausrichtung teilen sie dieselbe Organizational Domain. Der Domain Owner wählt dies mit aspf und adkim; RFC 9989 merkt an, dass fast alle Domain Owner gelockerte Ausrichtung ausreichend finden.

Eine authentifizierte, passende Kennung genügt. Von mehreren DKIM-Signaturen kann eine gültige und ausgerichtete den Pass liefern, obwohl andere scheitern. Ein SPF-Pass für eine Weiterleitungsdomain hilft dagegen nicht, wenn die From-Domain nicht dazu passt.

Das belastbare Protokoll lautet daher: Dieser Empfänger sah zu diesem Zeitpunkt diese authentifizierte Domain und stellte diese Ausrichtungsbeziehung zur Author Domain fest. Person und Absicht kommen darin nicht vor.

Was links vom @ und vor der Adresse steht

Bei einer Adresse, die den Local-Part vorstand mit der Domain example.com verbindet, prüft DMARC example.com. Es bestätigt weder vorstand noch das Postfach, dessen Betreiber oder die Person, die schrieb. RFC 9989 schließt die Validierung des Local-Part ausdrücklich aus.

Auch der menschenlesbare Anzeigename kann beliebig gewählt werden. Ein echter Managername kann vor einer fremden Adresse stehen. Eine ähnlich aussehende Domain kann eigene korrekt konfigurierte SPF-, DKIM- und DMARC-Daten besitzen. Die Spezifikation löst weder Anzeigenamenangriffe noch visuell ähnliche Domains.

Inhaltsanalyse liegt ebenfalls außerhalb. Ein kompromittierter legitimer Dienst kann schädliche Links über eine autorisierte Domain versenden. Ein Angreifer kann seine eigene Domain ordnungsgemäß authentifizieren. Rechnung, Anweisung, Anhang, Empfängerbezug und Wahrheitsgehalt benötigen Reputation, Kontokontrolle, Inhaltsprüfung und Geschäftsfreigabe.

Ein bestandener bösartiger Brief zeigt daher nicht zwingend einen Authentifizierungsfehler. Er kann zeigen, dass die Domainbeziehung richtig erkannt wurde und eine andere Kontrollschicht versagte.

Wenn der legitime Weg den Nachweis beschädigt

RFC 7960 untersucht indirekte Mailflüsse. Behält ein Forwarder das ursprüngliche MAIL FROM, sendet er möglicherweise von einer IP, die das ursprüngliche SPF nicht autorisiert. Ersetzt er es durch seine eigene Domain, kann SPF bestehen, aber die Ausrichtung zum ursprünglichen From geht verloren.

Mailinglisten ergänzen Betreffzeilen, Fußtexte oder verändern MIME-Teile. Das ist funktional legitim, kann aber die ursprüngliche DKIM-Signatur ungültig machen. Am Endpunkt fehlt dann eine ausgerichtete, noch gültige Kennung, obwohl die Nachricht am Anfang legitim war.

Deshalb formuliert RFC 9989 bewusst, eine fehlgeschlagene Nachricht sei nicht notwendigerweise ohne Beziehung zur Author Domain. fail beschreibt die verbliebene Evidenz am prüfenden Empfänger. Es rekonstruiert nicht den gesamten Transportweg und urteilt nicht über Betrug.

Pass und Fail sind somit keine moralischen Gegenpole. Der erste Befund ist kein Inhaltsfreispruch, der zweite keine Täterschaftsfeststellung.

Eine veröffentlichte Präferenz besitzt keine fremde Queue

Die Policy Discovery fragt zunächst die Author Domain, danach ihre Organizational Domain und schließlich die Public Suffix Domain ab. Fundort und Existenz der Subdomain bestimmen, ob p, sp oder np gilt. Das IANA-Register bezeichnet sie als angeforderte Assessment Policy; ältere Tags wie pct, rf und ri sind dort historisch.

Anforderung und Ausführung bleiben getrennt. RFC 9989 überlässt die endgültige Behandlung immer der lokalen Policy des Mail Receiver. Er darf einen Pass wegen anderer Erkenntnisse zurückweisen. Er darf trotz p=reject einen Fail annehmen, wenn er etwa einen legitimen indirekten Weg kennt. Die Spezifikation empfiehlt ausdrücklich, nicht allein wegen des veröffentlichten Reject-Werts abzulehnen.

DNS-Fehler zeigen dieselbe Zuständigkeit. Können erforderliche Abfragen nicht abgeschlossen werden, ist das Ergebnis weder Pass noch Fail; die Domain-Policy kann nicht angewandt werden. Ob zugestellt, temporär abgelehnt oder anders behandelt wird, entscheidet der Empfänger.

Heng Lus The Policy Mirror prüft gemeinsame Regeln danach, ob sie einen notwendigen technischen Datensatz schützen oder eine Entscheidung an sich ziehen, deren Risiko ein anderer trägt. RFC 9989 bezieht ihre normative Kraft nicht aus diesem Essay, doch die Methode erhellt ihre Trennung: Die ferne Domain veröffentlicht einen lesbaren Wunsch. Sie verwaltet nicht den Filter des Empfängers.

Angeforderte Berichte sind keine vollständige Beobachtung

Mit rua lassen sich Aggregatberichte, mit ruf einzelne Fehlerberichte anfordern. Aggregatdaten können Missbrauch und eigene Konfigurationslücken sichtbar machen. Der Empfänger muss jedoch nicht jeden gewünschten Bericht liefern. Aggregatberichte werden empfohlen; Einzelberichte sind optional und werden aus Datenschutzgründen oft gekürzt oder ganz unterlassen.

Eine URI im DNS belegt somit eine Bitte. Ein eingegangener Bericht belegt Beobachtungen eines bestimmten Reporters in einem Zeitraum. Beides belegt weder weltweite Abdeckung noch tatsächliche Ablehnung oder den Ausgang jeder Nachricht.

Vor dem Wechsel von Monitoring zu Quarantäne oder Reject müssen legitime Quellen, Subdomains, Weiterleitungen und Listen getestet, Berichtslücken verstanden und Rücknahmebedingungen festgelegt werden. Ein Policy-String ersetzt keinen Änderungsnachweis.

Todd Herr würdigen, ohne Kollektivarbeit zu privatisieren

Das am 1. September 2026 erfasste IETF-Profil führt RFC 9989 unter Todd Herrs öffentlicher Identität und nennt ihn als Reviewer im ART Area Review Team. Das öffentliche Bild dient der Identitätszuordnung. Die RFC nennt Herr bei Valimail und den Mitredakteur John Levine bei Standcore LLC; die Danksagung hält viele Beiträge der DMARC Working Group und der Vorgängerarbeit fest.

Herr lässt sich für eine konkrete redaktionelle Leistung profilieren: Der gemeinsam betreute Text bewahrt die enge Semantik des Ergebnisses und die lokale Entscheidung. Er ist weder alleiniger Erfinder noch weltweiter Prüfer oder Betreiber fremder Mailfilter. Eine korrekte Personengeschichte respektiert diese verteilten Rollen.

Der Nachweis mit getrennten Eigentümern

Für eine Prüfung gehören die empfangenen Bytes und das From, sämtliche SPF- und DKIM-Ergebnisse samt Domains, Selektoren, Gründen und Zeiten, die Ausrichtung, der DNS-Pfad und das wirksame Tag, Fehler, indirekte Änderungen, lokale Reputations- und Inhaltssignale, Disposition, Nutzerfolge und tatsächlich übermittelte Berichte in getrennte Felder.

Dann kann keine Zeile die nächste unbemerkt beerben. Domainautorisierung ist keine Personenidentität. Ausrichtung ist keine Inhaltswahrheit. Pass ist keine Sicherheit. Ferne Präferenz ist keine lokale Ausführung. SMTP-Annahme ist kein Inbox-Platz, und die Inbox ist kein schadloser Ausgang.

Innerhalb dieser Grenze bleibt DMARC stark. Es erschwert exaktes Domain-Spoofing, stabilisiert Domainreputation und liefert Rückmeldungen. Der kleine, reproduzierbare Beleg ist wertvoller als ein umfassendes Urteil, für das keine Eingaben existieren.

Quellen