Die rua-Adresse von DMARC konfigurieren (ohne in die Falle zu tappen)

v=DMARC1; p=none; rua=mailto:dmarc@beispiel.de

v=DMARC1; p=none; rua=mailto:dmarc@beispiel.de,mailto:berichte@analyse-dienstleister.com

Die Falle: die Autorisierung eines externen Ziels

Hier die Regel, die viele ignorieren: DMARC-Berichte an eine Adresse einer fremden Domain zu schicken, erfordert eine ausdrückliche Autorisierung, veröffentlicht auf Seiten der empfangenden Domain.

Warum? Um Missbrauch zu verhindern. Ohne diese Regel könnte jeder rua=mailto:opfer@andere-domain.de veröffentlichen und (potenziell umfangreiche) Berichte auf einen nicht einwilligenden Dritten kippen lassen. DMARC verlangt daher von der empfangenden Domain, zu erklären, dass sie zustimmt, die Berichte einer anderen Domain zu empfangen.

Konkret: Wenn beispiel.de ihre Berichte an dmarc@dienstleister.com schickt, dann muss die Domain dienstleister.com einen TXT-Eintrag unter diesem genauen Namen veröffentlichen:

beispiel.de._report._dmarc.dienstleister.com  IN TXT  "v=DMARC1"

Ohne diesen Autorisierungseintrag auf Seiten von dienstleister.com weigern sich die Empfänger, die Berichte an diese externe Adresse zu schicken — und der Betreiber rätselt, warum nichts ankommt. Seriöse DMARC-Analysedienste verwalten diese Autorisierung automatisch (sie liefern den zu veröffentlichenden Eintrag oder hosten ihn auf ihrer Seite). Aber bei einer selbstgebauten Weiterleitung an eine weitere eigene Domain bleibt das Setzen Aufgabe des Betreibers.

Umgekehrt ist, solange das rua auf eine Adresse der eigenen Domain zeigt, keine Autorisierung nötig — deshalb ist der Start mit dmarc@beispiel.de der einfachste Weg.

Dediziertes Postfach oder Analysedienst?

Sobald die Berichte einströmen, lautet die nächste Frage: Was tun damit? Zwei Optionen.

• Ein dediziertes Postfach. Das rua zeigt auf dmarc@beispiel.de, und die XML-Dateien werden von Hand gelesen. Machbar für eine kleine Domain mit geringem Volumen, aber schnell unhandlich: Die Berichte sind zahlreich, komprimiert und mühsam von Hand zu aggregieren. Ein guter Ausgangspunkt zum Verstehen, nicht für den dauerhaften Betrieb.
• Ein Analysedienst. Das rua zeigt (oder kopiert) auf eine Plattform, die das XML einliest und Dashboards präsentiert — Versandquellen, Alignment-Rate, Entwicklung. Das ist die realistische Wahl, sobald das Volumen steigt. Die Marktwerkzeuge werden verglichen in wie man einen DMARC-Bericht liest: Werkzeuge & Methode.

Bei beiden Wegen gilt: Die aggregierten Berichte enthalten keinerlei Nachrichteninhalt — nur statistische Metadaten — was sie ohne Datenschutzbedenken nutzbar macht, anders als die forensischen Berichte (ruf, siehe RUA vs RUF).

Womit beim Volumen zu rechnen ist

Der Andrang überrascht oft. Jeder große Empfänger (Gmail, Yahoo, Outlook und Dutzende weitere) schickt einen Bericht pro Tag, sobald er Post empfängt, die vorgibt, von der Domain zu kommen. Für eine aktive Domain sind das leicht mehrere Dutzend Dateien täglich. Genau deshalb sind eine dedizierte Adresse und langfristig ein Aggregationswerkzeug besser als ein überflutetes persönliches Postfach. Und dieses Volumen ist eine verkleidete gute Nachricht: Je mehr Berichte ankommen, desto vollständiger wird das Bild davon, wer im Namen der Domain versendet — jede Datei ist ein Mailanbieter, der meldet, was er hat durchlaufen sehen.

Optionale Einstellungen: ri und Größe

Zwei fortgeschrittene Optionen existieren, am Anfang selten nötig:

• ri= legt das gewünschte Intervall zwischen zwei aggregierten Berichten fest, in Sekunden (Standard 86400, also 24 h). Die Empfänger sind nicht verpflichtet, es exakt einzuhalten; in der Praxis dominiert der Tagesrhythmus. Das Thema wird behandelt in das DMARC-Reporting-Intervall.
• Die maximale Größe. Eine URI lässt sich mit einem ! gefolgt von einer Größe versehen (z. B. mailto:dmarc@beispiel.de!10m), um zu verlangen, dass 10 MB pro Bericht nicht überschritten werden. Nützlich für sehr große Domains; überflüssig für die meisten.

Der Eintrag bleibt am Anfang besser einfach: p, rua und die Subdomain-Tags reichen. Die feinen Optionen kommen erst hinzu, wenn ein konkreter Bedarf auftritt. In der Praxis leben nahezu alle Domains sehr gut, ohne je an ri oder die maximale Größe zu rühren: Die Empfänger wenden ihre eigenen Standardeinstellungen an, weitgehend vernünftig, und diese Tags bringen meist nur einen längeren Eintrag zum Wiederlesen und Pflegen.

Den Eintrag der externen Autorisierung entschlüsseln

Da dieser _report._dmarc-Eintrag die Quelle der meisten „Ich empfange nichts" ist, zerlegen wir ihn, denn seine Struktur verwirrt auf den ersten Blick. Der vollständige, zu veröffentlichende Name liest sich von links nach rechts wie ein Satz: „die sendende Domain ._report._dmarc. die empfangende Domain". In unserem Beispiel bedeutet beispiel.de._report._dmarc.dienstleister.com wörtlich: „dienstleister.com erklärt, zuzustimmen, die für beispiel.de bestimmten DMARC-Berichte zu empfangen."

Der Wert wiederum ist minimal: "v=DMARC1" reicht in den meisten Fällen. Es ist eine einfache Zustimmungsflagge, keine vollständige Policy. Zwei Feinheiten sind es wert, bekannt zu sein:

• Die Autorisierung lebt beim Empfänger, nicht beim Absender. Das ist eine große Quelle der Verwirrung: Die eigene DNS-Zone mag noch so perfekt beherrscht sein — wenn die Zieldomain ihren Autorisierungseintrag nicht veröffentlicht, kommt nichts an. Deshalb hebt das Delegieren des Reportings an einen Dienstleister, der „alles verwaltet", die Zweideutigkeit auf — die Autorisierung liegt auf seiner Seite, und er weiß sie zu setzen.
• Ein Platzhalter existiert. Ein Empfänger kann eine generische Autorisierung veröffentlichen (*._report._dmarc.dienstleister.com), um Berichte von jeder beliebigen sendenden Domain anzunehmen. Die großen Analyseplattformen nutzen das, um nicht pro Kunde einen Eintrag anlegen zu müssen. Selbst anzulegen ist das nicht nötig; nützlich ist es beim Audit einer bestehenden Konfiguration.

Warum eine dedizierte Adresse, vom ersten Tag an

Viele leiten rua zunächst auf ihre gewohnte Adresse „um zu sehen" und bereuen es dann. Drei Gründe, gleich von Anfang an eine dedizierte Adresse vom Typ dmarc@beispiel.de anzulegen:

• Das Volumen. Wie oben gesehen empfängt eine aktive Domain Dutzende Berichte pro Tag. In einem persönlichen Postfach ertränken sie die nützliche Post; in einem dedizierten Postfach sammeln sie sich ohne Störung, bereit, bearbeitet zu werden, wann es passt.
• Die Nachvollziehbarkeit. Eine dedizierte Adresse macht den Reporting-Fluss identifizierbar und auditierbar — kostbar in einem Compliance-Kontext, in dem zu zeigen ist, wo und wie die Authentifizierungsnachweise gesammelt werden.
• Der sanfte Übergang. Am Tag des Wechsels von manuellem Lesen zu einem Analysedienst ändert sich einfach die Weiterleitung der dedizierten Adresse, ohne dass der DMARC-Eintrag angerührt oder irgendetwas im DNS neu veröffentlicht wird.

Es ist eine Investition von fünf Minuten, die später eine mühsame Migration erspart.

Häufige Fehler

• Die externe Autorisierung vergessen. Die Falle Nummer eins: rua zeigt auf eine andere Domain ohne den entsprechenden _report._dmarc-Eintrag, und kein Bericht kommt an.
• rua auf ein persönliches Postfach leiten. Das Volumen überschwemmt es und die Berichte werden am Ende ignoriert. Eine dedizierte Adresse gehört angelegt.
• rua und ruf verwechseln. rua = aggregierte Berichte (statistisch, nützlich, ohne personenbezogene Daten); ruf = forensisch (sensibel, selten verschickt). Es ist rua, das vorrangig zu konfigurieren ist.
• rua veröffentlichen, aber p vergessen. Der umgekehrte Fall ist häufiger, aber ein wackliger Eintrag verhindert manchmal das gesamte Auslesen. Die vollständige Syntax gehört geprüft.

Was die ersten Berichte hergeben

Sobald die ersten aggregierten Berichte eintreffen, stellt sich eine praktische Frage: Was liest man zuerst heraus? Der erste nützliche Blick gilt der Liste der Versandquellen, die vorgeben, im Namen der Domain zu senden. Fast immer tauchen dort Quellen auf, an die niemand gedacht hatte — ein altes Marketing-Tool, ein Rechnungsdienst, ein Ticketsystem, ein regionales Büro mit eigenem Mailserver. Genau diese Entdeckung ist der eigentliche Wert des Reportings: Noch vor jedem Gedanken an das Verschärfen der Policy braucht es eine vollständige Karte davon, wer legitim für die Domain versendet. Ein rua, das mehrere Wochen läuft, baut diese Karte auf, Bericht für Bericht.

Der zweite Blick gilt der Alignment-Rate: Für jede identifizierte Quelle melden die Berichte, ob SPF und DKIM sich mit der Domain alignen oder nicht. Eine legitime Quelle, die nicht aligned ist, gehört korrigiert, bevor auf p=quarantine oder p=reject gewechselt wird — sonst bricht ihre Post. So verwandelt sich ein passiver Berichtsfluss in einen konkreten Aktionsplan: Quellen auflisten, jede alignen, dann verschärfen. Ohne rua fliegt der Betreiber blind; mit ihm folgt er einer Checkliste, die sich von selbst aus dem echten Verkehr ergibt.

Prüfen, dass es funktioniert

Sobald rua steht, ist die nächste Frage berechtigt: „Empfange ich meine Berichte auch wirklich?" Wenn nach ein paar Tagen nichts ankommt, hat die Diagnose ihre eigene Methode — siehe ich empfange keine DMARC-Berichte, das alle möglichen Ursachen durchgeht, von der Syntax bis zur externen Autorisierung.

Am schnellsten validiert eine Eingabe der Domain in den kostenlosen DMARC-Analyzer die Konfiguration: Er bestätigt, dass das rua syntaktisch korrekt und für die Empfänger lesbar ist, noch bevor der erste Bericht im Postfach landet. Das ist die Prüfung, die drei Tage Warten auf die Entdeckung eines Tippfehlers erspart. Ein einmal konfiguriertes und von außen validiertes rua verwandelt eine stumme Policy in einen Beweisfluss, auf den sich wirklich reagieren lässt.