DSGVO und E-Mail-Authentifizierung: zwei Blickwinkel, die man nicht verwechseln sollte

RUA versus RUF: die richtige Datenschutzeinstellung

Die praktische Folge ist klar und deckt sich mit der zunehmend verbreiteten Position im Ökosystem: aggregierte Berichte bevorzugen und forensische Berichte mit äußerster Vorsicht behandeln oder standardmäßig auf sie verzichten. Die Unterscheidung zwischen beiden, und warum RUF heute abgeraten wird, ist entwickelt in DMARC rua vs ruf Berichte und, aus dem spezifischen Datenschutzblickwinkel, in dem Datenschutz forensischer DMARC-Berichte.

Die DSGVO-Argumentation ist die der Minimierung: Erhoben wird nur, was für den Zweck erforderlich ist. Dieser Zweck — die Domain zu sichern und die Versandquellen zu kartieren — wird vollständig von aggregierten Berichten bedient. Forensik fügt wenig Sicherheitswert hinzu und vervielfacht zugleich die Exposition personenbezogener Daten. Die Rechnung neigt sich daher deutlich zugunsten von ausschließlich aggregiert.

Auch intern zählt der Unterschied

Ein oft übersehener Aspekt: Die Wahl des Berichtstyps entscheidet auch darüber, was über die eigenen Beschäftigten bekannt wird. Aggregierte Berichte beobachten Infrastruktur, keine Personen — sie zeigen, dass eine IP gesendet hat, nicht wer was an wen schrieb. Damit taugen sie nicht zur Verhaltenskontrolle, und genau das hält die Verarbeitung sauber. Forensische Berichte dagegen können einzelne Nachrichten realer Beschäftigter sichtbar machen, etwa wenn jemand über einen schlecht konfigurierten Weg sendet — und rücken die Verarbeitung damit in die Nähe einer Mitarbeiterüberwachung, mit allen Fragen, die das intern aufwirft. Wer bei aggregiert bleibt, erspart sich diese Diskussion von vornherein: ein weiteres Argument für die minimale Einstellung, diesmal aus der Innenperspektive.

Minimierung, Aufbewahrung, Auftragsverarbeiter

Beim Betrieb von DMARC-Berichten gelten einige DSGVO-Grundsätze direkt:

• Rechtsgrundlage und Zweck. Die Verarbeitung beruht auf dem berechtigten Interesse, die eigene Domain und Kommunikation zu sichern — eine solide Grundlage, sofern der Zweck Sicherheit bleibt und keine zweckentfremdete Nutzung.
• Minimierung. Aggregiert bevorzugen, forensisch vermeiden und nicht mehr Felder exfiltrieren als nötig.
• Aufbewahrung. Eine verhältnismäßige Dauer festlegen und durchsetzen: Jahre alte Berichte haben keinen Sicherheitswert mehr und werden zur Last. Eine ausdrückliche, automatisch bereinigte Aufbewahrungsstufe ist die gute Praxis.
• Auftragsverarbeiter. Übernimmt ein Dienstleister die Analyse der Berichte, wird er zum Auftragsverarbeiter im Sinne der DSGVO: Die Beziehung ist vertraglich einzurahmen, und der Hosting-Ort der Daten ist zu prüfen. Ein Hosting in der Union, nach europäischem Recht, vereinfacht die Compliance-Analyse erheblich.

Dieselben Anforderungen speisen das Verarbeitungsverzeichnis und dokumentieren sich ein für alle Mal — eine Arbeit, die direkt in die Nachweislogik eines ISO-27001-ISMS einfließt.

Ein konkretes Beispiel

Man nehme ein KMU, dessen Domain bei p=none blieb. Ein Angreifer mailt die Kundenbasis mit einer Nachricht an, die die authentische Support-Adresse anzeigt, ein „Sicherheitsupdate des Kontos" ankündigt und auf eine Zugangsdaten sammelnde Seite verweist. Mehrere Kunden geben ihre Daten ein. Aus DSGVO-Sicht steht das Unternehmen vor einer möglichen Verletzung, die die Daten seiner Kunden betrifft und seine eigene Domain als Vektor ausnutzt — eine unbequeme Lage, in der es zugleich Opfer und zu seinen Sicherheitsmaßnahmen befragter Verantwortlicher ist.

Dasselbe Szenario endet mit der Domain auf p=reject anders: Die gefälschte Nachricht wird bei der Zustellung abgewiesen, sie erreicht die Posteingänge nie, und es gibt kein Sammeln, keine Verletzung, keine Meldung. Es ist der greifbarste Beweis, dass die E-Mail-Authentifizierung eine Sicherheitsmaßnahme im Sinne von Artikel 32 ist und keine technische Abstraktion.

DMARC und die Meldung von Datenschutzverletzungen

Die DSGVO verlangt, bestimmte Datenschutzverletzungen binnen 72 Stunden an die Aufsichtsbehörde zu melden und mitunter die betroffenen Personen zu informieren. Eine erfolgreiche Fälschungskampagne gegen die eigene Domain kann eine Verletzung sein oder eine auslösen: bei Kunden abgegriffene Zugangsdaten, durch eine gefälschte Nachricht im Namen des Unternehmens gezogene personenbezogene Daten — genau die Art Ereignis, die die Meldepflicht auslöst, mit ihrem Gefolge aus Untersuchung, Kommunikation und regulatorischer Anspannung.

Die Argumentation trifft die der operationellen Resilienz: Jede Fälschung, die DMARC vorgelagert blockiert, ist eine Verletzung, die nicht stattfindet. Die Fähigkeit eines Angreifers, das Unternehmen zu imitieren, strukturell zu senken, heißt, die Häufigkeit meldepflichtiger Vorfälle zu senken — ein konkreter Compliance-Nutzen, messbar in vermiedenen Vorfällen, nicht nur im Prinzip.

Die Verarbeitung im Verzeichnis dokumentieren

Werden DMARC-Berichte betrieben, ist die Analyse eine im Verzeichnis nach Artikel 30 einzutragende Verarbeitung. Die gute Nachricht: Sie ist einfach zu beschreiben. Zweck — Sicherung der Domain und Kartierung der legitimen Versandquellen. Datenkategorien — im Wesentlichen Quell-IP-Adressen und Authentifizierungs-Metadaten für das Aggregat, und das ist alles, solange es dabei bleibt. Rechtsgrundlage — berechtigtes Interesse an der Sicherung der eigenen Kommunikation. Dauer — eine begrenzte, automatisch bereinigte Stufe. Empfänger — der etwaige Analyse-Dienstleister, als Auftragsverarbeiter eingerahmt.

Einmal ausgefüllt, lässt sich dieses Verzeichnis unverändert als Nachweisbaustein in einer ISO-27001-Vorkehrung wiederverwenden, die dieselbe Dokumentationsanforderung teilt. Der Aufwand verdoppelt sich nicht: Eine saubere Verarbeitung wird einmal beschrieben und unter beiden Rahmen präsentiert.

Braucht es eine Datenschutz-Folgenabschätzung?

Die Frage kommt oft auf. Für ausschließlich aggregierte Berichte ist die Exposition personenbezogener Daten gering und der Sicherheitszweck gut umrissen: Eine Datenschutz-Folgenabschätzung ist in der Regel nicht erforderlich, auch wenn eine rasche Risikobewertung gute Hygiene bleibt. Die Rechnung ändert sich, sobald forensische Berichte aktiviert werden, die personenbezogene Daten Dritter in Menge und mit weit intrusiverer Granularität transportieren können. Das ist ein weiterer Grund, diesmal auf dem Datenschutzfeld, standardmäßig bei aggregiert zu bleiben — genau das Minimierungsprinzip, das diese ganze Argumentation strukturiert.

Der doppelte Nutzen: Compliance und Schutz der Menschen

Diese Überschneidung hat eine gewisse Eleganz. Eine Domain auf p=reject zu bringen erfüllt die Sicherheitspflicht und schützt zugleich direkt die betroffenen Personen — Kunden, Nutzer, Beschäftigte — vor Betrügereien, die die Identität des Unternehmens ausnutzen würden, um ihnen Daten zu entlocken. Compliance und realer Schutz weisen hier in dieselbe Richtung, was in regulatorischen Dingen alles andere als immer der Fall ist.

Es ist auch der Grund, warum NIS2- oder anderen Sektorregimen unterliegende Einrichtungen davon profitieren, DMARC als gemeinsame Kontrolle zu behandeln: Derselbe Aufwand erfüllt die Sicherheitspflicht der DSGVO, die regulatorische Resilienzanforderung und den konkreten Schutz der Menschen. In der Praxis erleichtert das auch das Budgetgespräch: ein Posten, mehrere Häkchen und eine messbare Senkung der Vorfälle, deren Bereinigung sonst weit teurer wäre als ihre Verhinderung.

Datenschutz durch Technikgestaltung, in der Praxis

Hier steckt eine leise Lektion über Datenschutz durch Technikgestaltung. Die richtige DMARC-Einrichtung ist zugleich die datenschutzminimale: aggregierte Berichte für den Sicherheitswert, forensische abgeschaltet, um keine personenbezogenen Daten Dritter aufzusaugen. Es wird nicht Sicherheit gegen Datenschutz getauscht — dieselbe Konfiguration optimiert beides. Dieses Zusammenfallen ist im regulatorischen Leben selten genug, um es zu benennen, und es macht die Entscheidung leicht: die Richtlinie durchsetzen, die Berichterstattung aggregiert halten, die Aufbewahrung begrenzen — und damit sind Artikel 32 erfüllt, die Verarbeitung minimiert und die schwersten Datenschutzfragen in einem Zug erspart. Wenn die sicherste Einstellung einer Kontrolle zugleich die datenschutzfreundlichste ist, bleibt kein Dilemma zu lösen — nur die Arbeit zu tun. Und weil diese Arbeit ohnehin für die Sicherheit zu leisten ist, kostet der Datenschutzgewinn praktisch nichts extra — ein seltener Fall, in dem Compliance-Aufwand und Datenschutzgewinn dieselbe Handlung sind. Das macht die Entscheidung auch intern leicht vertretbar: Niemand muss zwischen Sicherheits- und Datenschutzzielen abwägen.

Die eigene Exposition prüfen

Am Anfang steht die kostenlose Diagnose. Die Domain in unseren kostenlosen DMARC-Analyzer eingegeben zeigt, ob sie derzeit fälschbar ist; unsere Datenschutzerklärung zeigt, wie wir eben diese Grundsätze selbst auf die Domain-Analyse anwenden. Auch die Haltung des eigenen Sektors lässt sich im DMARC-Observatorium vergleichen.

Die Authentifizierung sauber einzurahmen — Durchsetzung der Richtlinie auf der Sicherheitsseite, vorsichtige Berichtseinstellungen auf der Datenschutzseite — ist genau das, wobei Thomas, der virtuelle CISO, hilft: Er identifiziert die Versandquellen aus aggregierten Berichten, ohne je von der Forensik abzuhängen, und führt die Domain bis p=reject. Eine Domain kostenlos analysieren · das Observatorium erkunden · mit Thomas beginnen.