Zusammenfassung

  • Ein DMARC-Pass bestätigt nur die autorisierte Nutzung der Author Domain; er bescheinigt weder Wahrheit noch Sicherheit oder Wert der Nachricht.
  • p=reject ist die Behandlungspräferenz des Domain Owner. RFC 9989 lässt die endgültige Disposition und ihre Begründung beim Mail Receiver.

Zwei Nachrichten zeigen die Grenze. Eine besteht die Prüfung, löst aber lokale Missbrauchssignale aus. Eine andere scheitert nach legitimer Weiterleitung oder Listenbearbeitung. Wer Pass mit „sicher“ und Fail mit „Betrug“ gleichsetzt, trifft in beiden Fällen die falsche Entscheidung.

RFC 9989 erschien im Mai 2026 auf dem IETF Standards Track und ersetzt RFC 7489 sowie 9091. Veröffentlichungseintrag, Datatracker und Errata belegen das Dokument, nicht eine Implementierung.

SPF ordnet einer SMTP-Quelle eine autorisierte Identität zu; DKIM prüft eine Domain-Signatur. DMARC verlangt zusätzlich Alignment eines authentifizierten Identifiers mit der sichtbaren Author Domain. Mindestens ein ausgerichteter Erfolg ergibt Pass, sonst Fail.

Der Standard begrenzt beide Aussagen. Pass validiert ausschließlich die autorisierte Domainnutzung und enthält keine Wertung des Inhalts. Ein Empfänger darf die Nachricht trotzdem abweisen. Fail beweist umgekehrt keine Fälschung: RFC 7960 beschreibt Weiterleitung, Aliase und Mailinglisten, die legitime Nachrichten aus dem Alignment bringen.

Das IANA-DMARC-Register führt none, quarantine und reject. Diese Werte tragen Wissen des Domain Owner bei. Sie enthalten aber weder Empfängerhistorie noch lokale Reputation oder die Folgen einer Fehlentscheidung.

Abschnitte 5.3.6 und 5.4 halten deshalb die Behandlung in der lokalen Policy. Der Receiver kann p=reject berücksichtigen, soll aber nicht allein deshalb ablehnen. Sonst leiden legitime indirekte Flüsse. Eine Ausnahme kann wiederum Missbrauch zulassen. Die verantwortliche Stelle braucht also einen dokumentierten Grund.

Auch ein DNS-Fehler ist kein Fail. Ohne erforderliche Antwort entsteht weder Pass noch Fail; die Domain-Policy kann nicht angewandt werden. Aufschub oder sonstige Behandlung sind eine neue lokale Entscheidung.

Abweichungen erhalten eigene Belege. RFC 9990 stellt PolicyOverride für Tatsache und Grund bereit; RFC 8601 bewahrt Authentication-Results. Detaillierte Berichte nach RFC 9991 sind eine separate, optionale Offenlegung.

Heng Lus minimale Anfangsspezifikation koordiniert, ohne lokale Entscheidungsmacht einzuziehen. Seine Realitätsebenen trennen Symbol und Ausführung; der Vorrang von laufendem Code verlangt den Nachweis, welche Regel wirklich griff.

Der ehrliche Befund lautet: Diese Evidenz ergab dieses Alignment, die Domain äußerte diese Präferenz, und der Empfänger traf aus diesen Gründen diese Entscheidung.