DMARC RUA: Berichte einrichten und Ergebnisse auswerten

DMARC RUA bezeichnet die Berichtsadresse im DMARC-Eintrag, an die teilnehmende Empfänger aggregierte Berichte senden können. Ohne sie fehlt eine wichtige Rückmeldung zu Authentifizierung und möglichen unbekannten Quellen. Auch mit Berichten bleibt der Einblick unvollständig. Für die Grundlagen beginnen Sie mit geschäftlicher E-Mail für kleine Unternehmen.

Ein falsch eingerichtetes CRM, ein vergessenes WordPress-Plugin oder SPF-Probleme bei Weiterleitungen können die Diagnose erschweren. RUA macht einen Teil dieses Verkehrs sichtbar, damit Sie die Ursachen anhand von Daten statt bloßen Vermutungen untersuchen können.

Dieser Leitfaden erläutert das RUA-Tag, die Veröffentlichung im DNS, die Bedeutung der XML-Daten und eine sinnvolle Reihenfolge für Korrekturen.

Was ist DMARC RUA?

Das RUA-Tag nennt Ziele für aggregierte Authentifizierungsberichte. Diese fassen SPF, DKIM, Ausrichtung, Versand-IP-Adressen und DMARC-Behandlung über einen Zeitraum zusammen, häufig täglich und nur für den beobachteten Verkehr berichtender Empfänger.

Im DMARC-Eintrag fordert rua=mailto:... aggregierte Berichte an diese Adresse an. Nach RFC 7489 legt rua die Rückmeldeziele fest. Die Berichte enthalten unter anderem Authentifizierung, Ausrichtung, Domains, Nachrichtenzahlen und angewendete Behandlung.

Für die Durchsetzung brauchen Sie belastbare Daten. Ob p=none, p=quarantine oder p=reject passt, sollten Sie anhand von Berichten, einer Senderbestandsaufnahme und realen Tests beurteilen. RUA allein beweist keine vollständige Bereitschaft.

Was RUA-Berichte tatsächlich zeigen

RUA liefert aggregierte Zusammenfassungen, keine Kopien einzelner E-Mails. Sie zeigen beobachtete Quellen, rohe SPF- und DKIM-Ergebnisse sowie die für DMARC relevante Domainausrichtung. Rohe Prüfungen stehen im Bereich auth_results; policy_evaluated bewertet sie mit Ausrichtung für DMARC.

Die Berichte eignen sich für regelmäßige Betriebsprüfungen. Sie enthalten keine Nachrichtentexte, können aber Hinweise auf Anbieterfehler, mögliche Fälschungen und Ausrichtungsprobleme liefern.

Beginnen Sie üblicherweise mit RUA. ruf ist nur bei begründetem Bedarf sinnvoll: Die Unterstützung ist begrenzt, und detaillierte Berichte werfen zusätzliche Datenschutzfragen auf.

Beispiel: Eine Domain nutzt Google Workspace, eine Abrechnungsanwendung und einen Helpdesk. Berichte können diese Quellen sichtbar machen, sofern berichtende Empfänger sie beobachten. Fehlende Ausrichtung beim Helpdesk ist ein Prüfpunkt. Eine unbekannte Quelle oder ein anderer Standort beweist für sich allein jedoch kein Spoofing.

Eine RUA-Adresse im DNS veröffentlichen

Legen Sie TXT unter _dmarc.yourdomain.com an und fügen Sie eine gültige rua=mailto:-Adresse hinzu. Bei noch ungeprüften Sendern bietet sich zunächst Beobachtung statt sofortiger Durchsetzung an.

Das folgende Beispiel verwendet optionale strikte Ausrichtung; sie ist nicht der passende Standard für jede Domain:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s"

Eine alternative einfachere Variante ohne strikte Ausrichtung sieht so aus. Veröffentlichen Sie nicht beide Varianten gleichzeitig:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Nutzen Sie ein eigenes Berichtspostfach oder einen geeigneten Auswertungsdienst, damit komprimierte XML-Anhänge nicht die normalen Supportabläufe belasten.

TrekMails erforderliche DNS-Einträge erläutern die Einrichtung. Integrierte Prüfungen von SPF, DKIM und DMARC können DNS-Fehler aufdecken, ersetzen aber nicht die Kontrolle echter Nachrichten sämtlicher Sender.

Den RUA-Eintrag überprüfen

Fragen Sie DNS direkt ab und prüfen Sie anschließend, ob Berichte eintreffen. Ein falscher Eintrag kann Berichtsziele unbrauchbar machen. Fehlende Berichte können aber auch andere Ursachen haben, etwa nicht berichtende Empfänger oder eine fehlende Autorisierung.

Verwenden Sie dig oder nslookup:

dig +short TXT _dmarc.example.com
nslookup -type=TXT _dmarc.example.com

Die Antwort sollte den veröffentlichten DMARC-Eintrag enthalten. RFC 7489 beschreibt beispielsweise diesen gültigen Aufbau:

"v=DMARC1; p=none; rua=mailto:dmarc-feedback@example.com"

Berichte treffen häufig täglich ein, aber Zeitplan und Beteiligung unterscheiden sich. Eine Wartezeit ohne Berichte beweist weder fehlerfreies DNS noch fehlenden Verkehr.

RUA-Berichte strukturiert lesen

In XML suchen Sie zunächst die Quelle, prüfen SPF und DKIM und betrachten anschließend Ausrichtung sowie gemeldete Behandlung. Mindestens ein Verfahren muss erfolgreich und ausgerichtet sein, damit DMARC besteht.

Eine sinnvolle Reihenfolge:

1. Quell-IP und Reverse-DNS untersuchen und mit Ihren Systemen abgleichen. Ein PTR-Name allein belegt keine Identität.
2. Nachrichtenzahlen vergleichen: 2 Nachrichten und 20,000 Nachrichten haben unterschiedliche Größenordnungen, aber auch eine kleine Quelle kann geschäftskritisch sein.
3. SPF, DKIM und Ausrichtung prüfen. Ein erfolgreiches Verfahren ohne Ausrichtung genügt nicht, sofern kein anderer ausgerichteter Pfad erfolgreich ist.
4. Behandlung lesen: none belegt keine bestimmte Zustellung oder reine Beobachtungsrichtlinie; quarantine keine feste Ordnerablage; reject keine ausnahmslose Sperrung.
5. Die Quelle als legitim, fehlerhaft, verdächtig oder noch ungeklärt einordnen.

Google verlangt für gewöhnliche direkte Sender an persönliche Gmail-Konten SPF oder DKIM. Massenversender benötigen zusätzlich beide Verfahren und DMARC mit Ausrichtung mindestens eines erfolgreichen Pfads zur Domain im From:-Header. RUA kann tatsächliche Ausrichtungsprobleme sichtbar machen, garantiert aber keine bestimmte Inbox-Einstufung.

Drei wichtige Fehlerbilder in RUA-Berichten

Häufige Prüfbereiche sind legitime Sender mit fehlender Authentifizierung, SPF-Probleme durch Weiterleitung und mögliche Fälschungen. Ordnen Sie sie anhand weiterer Informationen zu, bevor Sie Maßnahmen ergreifen.

1. Legitimer Sender mit fehlerhafter Einrichtung

Ein bekannter Dienst sendet für Ihre Domain, aber passende SPF-Freigaben oder ausgerichtete DKIM-Signaturen fehlen. Erfolgreiches ausgerichtetes SPF oder DKIM genügt für DMARC; fehlendes DKIM kann dennoch bei Weiterleitung problematisch sein. Korrigieren Sie zuerst den Sender.

Bei eigenem Versanddienst richten Sie DNS nach dem tatsächlichen Versandweg ein. Siehe eigener SMTP. Beim entsprechenden kostenpflichtigen verwalteten Versand erläutert Managed TrekMail SMTP die Einrichtung und Signierung.

2. SPF scheitert bei Weiterleitung

Eine neue Versand-IP kann SPF scheitern lassen, ohne dass die Nachricht gefälscht ist. DKIM kann bestehen bleiben, wenn signierte Daten unter den Kanonisierungsregeln erhalten bleiben. Bei erfolgreicher ausgerichteter DKIM-Prüfung besteht DMARC. Bestätigen Sie den konkreten Pfad statt jeden SPF-Fehler pauschal zu ignorieren.

Für diese Fälle helfen E-Mail-Weiterleitung und Domain-E-Mails an Gmail weiterleiten. SPF-Fehler und DMARC-Fehler sind unterschiedliche Ergebnisse.

3. Unbekannte Quelle mit möglichem Spoofing

Eine unbekannte IP kann ein nicht erfasster Dienst, ein gemeinsames Relay, eine Weiterleitung oder Missbrauch sein. Fügen Sie sie nicht ohne Prüfung zu SPF hinzu und setzen Sie sie nicht pauschal auf eine Freigabeliste. Verschärfen Sie die Richtlinie erst nach bestätigter Einrichtung legitimer Quellen.

RUA an einen externen Auswertungsdienst senden?

Ein externer Dienst kann XML leichter aufbereiten. Prüfen Sie aber die DNS-Voraussetzungen und den Umgang mit Berichtsdaten. Externe Ziele benötigen eine Autorisierung, die manche Empfänger vor dem Versand kontrollieren.

RFC 7489 beschreibt bei einem rua-Ziel außerhalb der Organisationsdomain einen Bestätigungseintrag im DNS der Zieldomain, etwa:

example.com._report._dmarc.thirdparty.example.net. IN TXT "v=DMARC1"

Fehlt die Bestätigung, können Berichtsersteller das externe Ziel ignorieren. Folgen Sie deshalb den genauen Vorgaben des Auswertungsdienstes und prüfen Sie die Autorisierung auf der Zielseite.

Wann von p=none zu Quarantine oder Reject wechseln?

Nutzen Sie Berichte, Bestandsaufnahme und Tests vor einer Richtlinienänderung. Ungeklärte Fehler sind nicht automatisch Spoofing. Erst nach ausreichend geprüften legitimen Abläufen sollten Sie eine strengere Behandlung anfordern.

Ein möglicher Ablauf:

1. RUA mit p=none veröffentlichen.
2. Berichte beispielsweise 1 bis 2 Wochen beobachten und seltene Versandzyklen zusätzlich prüfen.
3. Für jeden legitimen Sender einen erfolgreichen ausgerichteten SPF- oder DKIM-Pfad sicherstellen.
4. Nach belastbarer Prüfung p=quarantine erwägen.
5. p=reject erst nach Prüfung kritischer Nachrichten und verbleibender Fehler erwägen.

Ohne Beobachtung und Tests können erst Kunden eine übersehene Konfiguration melden. Planen Sie daher Kontrollen und eine Reaktion auf legitime Fehler.

RUA-Betrieb mit einem gemeinsamen Verwaltungsablauf

Manuelle XML-Auswertung bleibt auch bei gemeinsamen Werkzeugen notwendig oder wird einem Auswertungsdienst überlassen. Einheitliche DNS-Abläufe und eine gemeinsame Verwaltung können die Arbeit an Domains, Postfächern, Migration und Versand erleichtern.

TrekMail ist kein DMARC-Auswertungsdienst. Es bietet je nach Tarif eigene Domains, IMAP-Postfächer, Catch-all, Weiterleitung, IMAP-Migration und eigenen oder verwalteten SMTP. Das kann die Infrastrukturverwaltung vereinfachen, ersetzt aber keine Berichtsinterpretation.

Kostenpflichtige Tarife werden ab $3.50/Monat angeboten. Nano wird kostenlos ohne Karte angeboten. Kostenpflichtige Tarife können eine 14-tägige Testphase mit erforderlicher Kreditkarte bieten. Prüfen Sie aktuelle Preise, Funktionen und Bedingungen.

Fazit: RUA schafft eine Rückmeldung für den Betrieb

RUA kann fehlerhafte Sender, Weiterleitungseffekte und mögliche Fälschungen sichtbar machen. Die Rückmeldungen sind eine wertvolle Ergänzung, aber kein vollständiger Nachweis, dass eine Domain für jede Durchsetzungsstufe bereit ist.

Bei einer Domain wie bei fünfzig oder fünfhundert helfen regelmäßige Auswertung und ein gepflegter Senderbestand. Richten Sie RUA ein, prüfen Sie die Daten und testen Sie legitime Quellen, bevor Sie die Richtlinie verschärfen.

TrekMail kann mit einem Pauschalpreismodell für Mehrdomain-Hosting, gemeinsamem Speicher, einladungsbasierter Postfachbereitstellung und IMAP-Migration unterstützen, soweit der gewählte Tarif diese Funktionen umfasst. Einstieg und aktuelle Bedingungen finden Sie auf trekmail.net.