Digitale Plattformen stehen mehr denn je unter Druck, nachzuweisen, dass ihre Dienste sicher, verantwortlich und widerstandsfähig gegen Missbrauch sind.

Das Digital Services Act (Gesetz über digitale Dienste) der Europäischen Union hat diese Entwicklung beschleunigt, indem es die Erwartungen an Plattform-Governance, Nutzerschutz, Transparenz, Risikomanagement und Rechenschaftspflicht im gesamten digitalen Ökosystem erhöht hat. Die Europäische Kommission beschreibt das DSA als einen Rahmen, der das Online-Umfeld sicherer und vertrauenswürdiger machen soll. (Digital Strategy)

Der Großteil der Diskussion um das DSA konzentriert sich auf Content-Moderation, illegale Inhalte, Händler-Rückverfolgbarkeit, Werbetransparenz, systemische Risiken und Plattform-Verantwortlichkeit.

Aber es gibt eine weitere Ebene, die oft weniger Aufmerksamkeit erhält:

Wie Plattformen mit Nutzern, Kunden, Händlern, Partnern und internen Teams kommunizieren.

E-Mail ist nach wie vor einer der wichtigsten Vertrauenskanäle in der digitalen Wirtschaft. Plattformen nutzen sie zur Verifizierung von Konten, zum Zurücksetzen von Passwörtern, zur Benachrichtigung von Nutzern, zur Unterstützung von Verkäufern, zur Kommunikation von Richtlinienentscheidungen, zum Versenden von Sicherheitswarnungen und zur Verwaltung operativer Arbeitsabläufe.

Wenn diese E-Mails gefälscht, nachgeahmt oder missbraucht werden können, wird das Plattformvertrauen geschwächt.

Hier wird die E-Mail-Authentifizierung strategisch wichtig.

DMARC, SPF, DKIM, MTA-STS und TLS-RPT machen eine Organisation nicht automatisch „DSA-konform“. Das DSA schreibt diese Protokolle nicht namentlich vor.

Aber für in Europa tätige Plattformen unterstützt die E-Mail-Authentifizierung die übergeordneten Vertrauens-, Sicherheits-, Anti-Missbrauchs- und Governance-Ziele, die moderne digitale Regulierung von Organisationen erwartet.

Es geht nicht mehr nur um Zustellbarkeit.

Es geht darum, ob die Organisation nachweisen kann, dass ihre Kommunikationsebene kontrolliert, überwacht und vor Domain-Missbrauch geschützt ist.

I. Das DSA hebt den Standard für digitales Vertrauen an

Das DSA ist Teil einer breiteren Regulierungsbewegung in Europa: Von digitalen Diensten wird erwartet, dass sie mit stärkerer Verantwortlichkeit arbeiten.

Diese Verantwortlichkeit endet nicht an der Plattform-Schnittstelle.

Sie erstreckt sich auf die Systeme, die Plattformen zur Kommunikation mit Nutzern und Stakeholdern verwenden.

Eine Plattform kann starke Moderationsrichtlinien, klare Nutzungsbedingungen und dokumentierte Eskalationsverfahren haben. Aber wenn Angreifer gefälschte Kontobenachrichtigungen, gefälschte Durchsetzungshinweise, gefälschte Verkäuferkommunikation oder gefälschte Support-E-Mails unter Verwendung der Domain der Plattform versenden können, ist das Vertrauensmodell unvollständig.

Für Nutzer fühlt sich die E-Mail oft wie die Plattform an.

Eine E-Mail zum Zurücksetzen des Passworts, eine Anfrage zur Verkäuferverifizierung, eine Mitteilung über einen Richtlinienverstoß oder eine Sicherheitswarnung können sofortiges Handeln auslösen. Wenn diese Nachricht betrügerisch ist, unterscheidet der Nutzer möglicherweise nicht zwischen Plattformmissbrauch und Plattformversagen.

Deshalb gehört die E-Mail-Authentifizierung in die Vertrauensdiskussion der DSA-Ära.

Nicht als enges rechtliches Kontrollkästchen.

Als praktische Kontrolle zum Schutz der Glaubwürdigkeit der Plattformkommunikation.

II. Was E-Mail-Authentifizierung tatsächlich schützt

Die E-Mail-Authentifizierung hilft empfangenden Mailservern zu bestimmen, ob eine Nachricht, die vorgibt, von einer Domain zu stammen, autorisiert ist.

Die Kernprotokolle arbeiten zusammen:

• SPF identifiziert, welche Server zum Versenden von E-Mails für eine Domain berechtigt sind.
• DKIM fügt eine kryptografische Signatur hinzu, um zu überprüfen, dass eine Nachricht von der signierenden Domain autorisiert wurde und während der Übertragung nicht verändert wurde.
• DMARC verbindet die Authentifizierung zurück zur sichtbaren Von-Domain, die Nutzer sehen.
• MTA-STS hilft, verschlüsselte E-Mail-Übertragung zwischen unterstützenden Mailservern durchzusetzen.
• TLS-RPT bietet Berichte über TLS-Zustellungsprobleme.

Für Plattformbetreiber ist die wichtigste Kontrolle die DMARC-Ausrichtung.

Eine Nachricht besteht DMARC nur, wenn mindestens eine der folgenden Bedingungen zutrifft:

• SPF besteht und die SPF-authentifizierte Domain stimmt mit der sichtbaren Von-Domain überein.
• DKIM besteht und die DKIM-signierende Domain stimmt mit der sichtbaren Von-Domain überein.

Dies ist wichtig, weil Nutzer keine Authentifizierungs-Header sehen. Sie sehen die sichtbare Von-Domain.

DMARC hilft, diese sichtbare Identität zu schützen.

Wenn DMARC auf Quarantäne oder Ablehnung durchgesetzt wird, teilt der Domain-Inhaber empfangenden Systemen mit, wie mit Nachrichten umzugehen ist, die Authentifizierung und Ausrichtung nicht bestehen. Dies hilft, exakte Domain-Spoofing zu reduzieren, bei dem Angreifer versuchen, E-Mails zu versenden, die scheinbar direkt von der echten Domain der Plattform stammen.

III. Was E-Mail-Authentifizierung nicht löst

E-Mail-Authentifizierung ist leistungsstark, aber kein vollständiges Anti-Missbrauchs-Programm.

DMARC stoppt nicht jeden Phishing-Angriff. Es verhindert nicht, dass ähnlich aussehende Domains registriert werden. Es stoppt nicht die Nachahmung von Anzeigenamen. Es garantiert keine Inbox-Platzierung. Es ersetzt nicht Betrugserkennung, Nutzerschulung, Content-Moderation, Zugangskontrollen oder Incident Response.

Diese Unterscheidung ist wichtig.

E-Mail-Authentifizierung schützt die Domain-Identität der Plattform selbst.

Sie eliminiert nicht jede Form der Nachahmung.

Ein ausgereiftes Vertrauensprogramm benötigt beides:

• DMARC, SPF und DKIM zum Schutz der echten Domain.
• Markenüberwachung, Missbrauchserkennung und Takedown-Workflows zur Bekämpfung ähnlich aussehender Domains und Nachahmungs-Infrastruktur.

Für DSA-relevante Plattformen macht diese Unterscheidung das Programm glaubwürdiger. Sie zeigt, dass E-Mail-Authentifizierung als Teil einer breiteren Vertrauens- und Sicherheitsarchitektur verstanden wird.

IV. Warum Plattformen sich kümmern sollten

Plattformen versenden E-Mails, auf die Nutzer sich verlassen.

Beispiele umfassen:

• Kontoverifizierungs-E-Mails
• Passwort-Zurücksetzungs-E-Mails
• Login-Warnungen
• Onboarding-Nachrichten für Verkäufer oder Händler
• Mitteilungen über Richtlinienverstöße
• Sicherheitswarnungen
• Support-Case-Updates
• Zahlungs- und Abrechnungsbenachrichtigungen
• Marktplatz-Betriebs-E-Mails
• Regulatorische oder rechtliche Hinweise

Wenn Angreifer diese Kommunikationen nachahmen können, kann die Auswirkung schwerwiegend sein.

Eine gefälschte Richtlinienmitteilung kann einen Verkäufer dazu verleiten, Anmeldedaten einzureichen. Eine gefälschte Sicherheitswarnung kann einen Nutzer in ein Phishing-Portal drängen. Eine gefälschte Support-Nachricht kann einen Kunden in Betrug umleiten. Eine gefälschte Zahlungsbenachrichtigung kann das Vertrauen in die Plattform beschädigen.

Aus Vertrauensperspektive hat die Plattform die Verantwortung, die Wahrscheinlichkeit zu verringern, dass ihre eigene Domain auf diese Weise missbraucht werden kann.

DMARC unterstützt diese Verantwortung, indem es Plattformen hilft, wichtige Fragen zu beantworten:

• Welche Systeme sind zum Versenden von E-Mails für unsere Domains berechtigt?
• Welche Drittanbieter-Plattformen senden in unserem Namen?
• Sind nutzerorientierte E-Mails ordnungsgemäß authentifiziert?
• Sind Sicherheits- und Support-Nachrichten ausgerichtet?
• Versuchen unbekannte Quellen, unsere Domain zu verwenden?
• Sind regionale, Kampagnen- oder Legacy-Domains exponiert?
• Überwachen wir Authentifizierungsfehler im Zeitverlauf?

Dies sind operative Fragen, aber sie haben Governance-Wert.

Sie zeigen, ob die Organisation die Integrität ihrer Kommunikationsebene aktiv verwaltet.

V. Das versteckte Risiko: Teilweiser Schutz

Viele Organisationen schützen zuerst ihre Haupt-Domain.

Das ist ein guter Anfang, aber nicht ausreichend.

Plattformen betreiben oft viele Domains und Subdomains:

• Haupt-Unternehmens-Domains
• Produkt-Domains
• Support-Domains
• Marktplatz-Domains
• Verkäufer-Onboarding-Domains
• Regionale Domains
• Kampagnen-Domains
• Entwickler- oder API-Domains
• Legacy-Domains

Angreifer müssen nicht die am besten geschützte Domain fälschen. Sie suchen nach der schwächsten glaubwürdigen Domain.

Eine Plattform kann DMARC auf ihrer Haupt-Domain durchsetzen, aber eine regionale oder Kampagnen-Domain im Überwachungsmodus belassen. Diese Domain kann immer noch in Phishing-Kampagnen missbraucht werden, die für Nutzer glaubwürdig aussehen.

Dies schafft ein Governance-Problem.

Wenn die Organisation Domain-Nachahmung als Risiko identifiziert hat, wird teilweise Implementierung im Laufe der Zeit schwerer zu verteidigen.

Ein ausgereiftes Programm sollte das gesamte Domain-Portfolio abdecken, nicht nur die sichtbarste Domain.

VI. Drittanbieter-Absender schaffen die größte Komplexität

Moderne Plattformen versenden selten alle E-Mails von einem Ort aus.

Sie verlassen sich auf mehrere Dienste:

• CRM-Plattformen
• Marketing-Automatisierungssysteme
• Kundensupport-Tools
• Identitätsanbieter
• Abrechnungsplattformen
• Marktplatz-Benachrichtigungssysteme
• Transaktions-E-Mail-Anbieter
• HR- und interne Kommunikationstools

Jeder Absender muss autorisiert, authentifiziert und ausgerichtet sein.

Hier scheitern viele E-Mail-Authentifizierungsprogramme.

Ein Anbieter kann in SPF enthalten sein, aber die DMARC-Ausrichtung nicht bestehen. Eine andere Plattform kann mit DKIM signieren, aber unter ihrer eigenen Domain statt der Domain der Plattform. Ein Geschäftsteam kann eine Kampagne von einem nicht genehmigten Absender starten. Ein Legacy-System sendet möglicherweise weiterhin E-Mails ohne ordnungsgemäße Authentifizierung.

Diese Lücken schaffen sowohl Sicherheits- als auch Governance-Probleme.

Für Plattformen, die unter strengeren regulatorischen Erwartungen arbeiten, sollte das Management von Drittanbieter-Absendern nicht informell sein. Es sollte Teil des Vendor-Onboardings, des Änderungsmanagements und der Sicherheitsprüfung sein.

VII. Ein praktisches DSA-ausgerichtetes E-Mail-Authentifizierungsprogramm

Der richtige Ansatz besteht nicht darin, DMARC als schnelles DNS-Projekt zu behandeln.

Der richtige Ansatz besteht darin, E-Mail-Authentifizierung als kontrolliertes Vertrauensprogramm zu behandeln.

VIII. 1. Vollständiges Domain-Inventar erstellen

Beginnen Sie damit, jede Domain und Subdomain zu identifizieren, die für die Plattformkommunikation verwendet wird.

Einschließlich:

• Nutzerorientierte Domains
• Support-Domains
• Marktplatz- oder Händler-Domains
• Regionale Domains
• Kampagnen-Domains
• Transaktions-E-Mail-Domains
• Legacy-Domains
• Interne Kommunikations-Domains

Dokumentieren Sie für jede Domain, ob sie E-Mails versendet, wem sie gehört, welche Systeme sie verwenden und welche Authentifizierungsrichtlinie derzeit vorhanden ist.

IX. 2. Jeden legitimen Absender identifizieren

Erstellen Sie ein Absender-Inventar.

Dokumentieren Sie für jede Absenderquelle:

• Plattform- oder Anbietername
• Geschäftsinhaber
• Nachrichtentyp
• Versendende Domain
• SPF-Autorisierung
• DKIM-Signierungsstatus
• DMARC-Ausrichtungsstatus
• Volumen
• Kritikalität
• Genehmigungsstatus
• Überprüfungsdatum

Dieses Inventar wird zur Grundlage für Sicherheitsoperationen, Vendor-Management und Compliance-Nachweise.

X. 3. SPF und DKIM ausrichten

DMARC hängt von SPF und DKIM ab.

Vor der Durchsetzung müssen legitime Absender ausgerichtetes SPF oder ausgerichtetes DKIM bestehen.

SPF-Einträge sollten nur autorisierte Absender enthalten und innerhalb der DNS-Lookup-Grenzen bleiben. DKIM sollte für alle wichtigen nutzerorientierten und sicherheitssensiblen Kommunikationen aktiviert sein.

Wo möglich, sollten Drittanbieter-Absender mit DKIM signieren, das auf die Domain der Plattform ausgerichtet ist. Dies ist oft zuverlässiger als SPF in komplexen Routing- und Weiterleitungsszenarien.

XI. 4. DMARC-Überwachung starten

Bevor Plattformen zur Durchsetzung übergehen, benötigen sie Transparenz.

Diese Transparenz beginnt mit DMARC-Überwachung.

Der empfohlene Weg besteht darin, einen kostenlosen DMARC-Überwachungs-Eintrag über Skysnag zu generieren. Dies gibt der Organisation ein verwaltetes Berichtsziel und ermöglicht es Sicherheitsteams, Authentifizierungsdaten zu sammeln, ohne manuell einen statischen Eintrag zu erstellen, der möglicherweise nie überprüft wird.

Starten Sie hier:

„`text id=“skysnag-signup“
https://app.skysnag.com/en/register/

Sobald die Domain hinzugefügt wurde, stellt Skysnag den DMARC-Eintrag zur Veröffentlichung im DNS bereit.

Ein traditioneller statischer DMARC-Überwachungseintrag kann so aussehen:

dns id=“dmarc-static-example“
v=DMARC1; p=none; rua=mailto:[email protected]

Dieser Ansatz kann funktionieren, aber nur, wenn jemand die Berichte aktiv empfängt, analysiert, auswertet und darauf reagiert.

Ein statischer Eintrag ohne Überwachung erzeugt ein falsches Gefühl von Fortschritt.

In dieser Phase ist das Ziel nicht Durchsetzung. Das Ziel ist Transparenz.

Überwachen Sie:

- Legitime Absender, die DMARC bestehen

- Legitime Absender, die DMARC nicht bestehen

- Unbekannte Quellen

- Hohe E-Mail-Volumen-Ströme

- Subdomain-Verhalten

- Regionale Unterschiede

- Spoofing-Versuche

- Ausrichtungsprobleme von Drittanbietern

Vermeiden Sie die standardmäßige Aktivierung forensischer Fehlerberichte. Sie können sensible Informationen enthalten und sollten nur nach Datenschutz-, Rechts- und Sicherheitsprüfung verwendet werden.

## 5. Zur Durchsetzung übergehen

Sobald legitime Absender ausgerichtet sind, gehen Sie zur Durchsetzung über.

Ein praktischer Weg ist:

1. Verwenden Sie den Überwachungsmodus zur Erkennung.

2. Verschieben Sie ausgewählte Domains oder Subdomains in Quarantäne.

3. Beheben Sie Fehler legitimer Absender.

4. Verschieben Sie ausgereifte Domains zur Ablehnung.

5. Setzen Sie die Überwachung nach der Durchsetzung fort.

Bestätigen Sie vor dem Wechsel zur Ablehnung:

- Kritische Absender bestehen DMARC.

- Drittanbieter-Plattformen sind ausgerichtet.

- Geschäftsinhaber haben Auswirkungen überprüft.

- Support-Teams sind vorbereitet.

- Rollback-Verfahren existieren.

- Ausnahmen sind dokumentiert.

DMARC-Durchsetzung sollte auf Evidenz basieren, nicht auf Annahmen.

## 6. MTA-STS und TLS-RPT wo angemessen hinzufügen

DMARC schützt Absender-Authentifizierung. Es erzwingt keine verschlüsselte Übertragung zwischen Mailservern.

MTA-STS und TLS-RPT unterstützen die Transportschicht.

MTA-STS ermöglicht es einer Domain, eine Richtlinie zu veröffentlichen, die unterstützende Mailserver dazu verpflichtet, TLS zu verwenden, wenn E-Mails an diese Domain zugestellt werden. TLS-RPT bietet Berichte über TLS-Zustellungsprobleme.

Für Plattformen, die Konto-, Support-, Marktplatz- oder Sicherheitskommunikationen versenden, können diese Kontrollen die gesamte E-Mail-Vertrauenskette stärken.

Beispiel MTA-STS-Richtlinie:

text id=“mta-sts-example“
version: STSv1
mode: enforce
mx: mail.example.com
max_age: 86400

Beispiel TLS-RPT-Eintrag:

dns id=“tls-rpt-example“
_smtp._tls.example.com. IN TXT „v=TLSRPTv1; rua=mailto:[email protected]“
„`

XII. Governance ist wichtiger als der DNS-Eintrag

Ein starkes E-Mail-Authentifizierungsprogramm benötigt Eigenverantwortung.

Ohne Governance driftet die Authentifizierungsposition ab.

Neue Anbieter werden hinzugefügt. Kampagnen werden gestartet. Regionale Teams erstellen Domains. DNS-Einträge ändern sich. DKIM-Schlüssel rotieren. Legacy-Systeme bleiben aktiv.

Empfohlene Governance-Elemente umfassen:

• Führungssponsor
• Sicherheitsverantwortlicher
• DNS-Verantwortlicher
• Compliance-Stakeholder
• Geschäftsinhaber für jeden Absender
• Vendor-Onboarding-Prozess
• Änderungsmanagement-Workflow
• Ausnahmeverfahren
• Regelmäßiger Überprüfungsrhythmus
• Incident-Response-Verfahren

Hier wird das Programm vertretbar.

Nicht weil ein DMARC-Eintrag existiert, sondern weil die Organisation zeigen kann, dass E-Mail-Authentifizierung im Besitz ist, überwacht und gepflegt wird.

XIII. Nachweise, die Plattformen pflegen sollten

Für DSA-relevante Organisationen sind Nachweise wichtig.

Pflegen Sie Dokumentation für:

• Domain-Inventar
• Absender-Inventar
• SPF-, DKIM-, DMARC-, MTA-STS- und TLS-RPT-Einträge
• DMARC-Richtlinienverlauf
• Authentifizierungsbericht-Analyse
• Absender-Sanierung
• Drittanbieter-Genehmigungen
• Ausnahmeentscheidungen
• Rollback-Verfahren
• Überwachungsrhythmus
• Incident-Response-Maßnahmen
• Transport-Sicherheitskontrollen

Diese Nachweise helfen nachzuweisen, dass Plattformkommunikation aktiv als Teil des umfassenderen Vertrauens- und Anti-Missbrauchs-Programms der Organisation verwaltet wird.

XIV. Implementierungs-Checkliste

Verwenden Sie diese Checkliste als praktischen Ausgangspunkt.

• [ ] Inventarisieren Sie alle Domains und Subdomains, die für die Plattformkommunikation verwendet werden.
• [ ] Identifizieren Sie alle internen und Drittanbieter-Absenderquellen.
• [ ] Ordnen Sie jeden Absender einem Geschäftsinhaber zu.
• [ ] Bestätigen Sie, dass SPF-Einträge nur autorisierte Absender enthalten.
• [ ] Überprüfen Sie SPF-Lookup-Grenzen.
• [ ] Aktivieren Sie DKIM für kritische Versandplattformen.
• [ ] Bestätigen Sie SPF- oder DKIM-Ausrichtung mit der sichtbaren Von-Domain.
• [ ] Starten Sie DMARC-Überwachung über Skysnag und veröffentlichen Sie den generierten Überwachungseintrag.
• [ ] Wenn Sie einen traditionellen statischen DMARC-Eintrag verwenden, bestätigen Sie, dass Berichte aktiv gesammelt und überprüft werden.
• [ ] Analysieren Sie DMARC-Berichte vor der Durchsetzung.
• [ ] Sanieren Sie legitime Absender, die bei der Authentifizierung scheitern.
• [ ] Verschieben Sie ausgereifte Domains in Richtung Quarantäne oder Ablehnung.
• [ ] Vermeiden Sie Standard-Forensik-Berichterstattung, es sei denn, sie wurde von Datenschutz- und Rechtsteams genehmigt.
• [ ] Überprüfen Sie Support-, Marktplatz-, Verkäufer-, Sicherheits- und Nutzerbenachrichtigungs-Domains.
• [ ] Etablieren Sie Anforderungen für das Onboarding von Drittanbieter-Absendern.
• [ ] Implementieren Sie MTA-STS und TLS-RPT wo angemessen.
• [ ] Definieren Sie Verantwortlichkeiten und Eskalationspfade.
• [ ] Pflegen Sie Dokumentation für Governance und Audit-Bereitschaft.
• [ ] Überprüfen Sie die Authentifizierungsposition regelmäßig.

XV. Wie Skysnag Comply hilft

Skysnag Comply hilft Organisationen, die Nachweis- und Überwachungsebene hinter der E-Mail-Authentifizierung zu verwalten.

Für EU-orientierte Plattformen unterstützt Skysnag Comply:

• Transparenz des Domain-Inventars
• DMARC-Überwachung
• SPF- und DKIM-Ausrichtungstransparenz
• Erkennung nicht autorisierter Absender
• Überprüfung von Drittanbieter-Absendern
• Tracking der Durchsetzungsbereitschaft
• Compliance-orientierte Berichterstattung
• Evidenzsammlung für Governance-Reviews
• Kontinuierliche Transparenz bei Authentifizierungsfehlern

Skysnag Comply macht das DSA nicht zu einem DMARC-Mandat.

Es hilft Organisationen zu zeigen, dass E-Mail-Authentifizierung überwacht, gesteuert und als Teil eines umfassenderen Vertrauens- und Anti-Missbrauchs-Programms gepflegt wird.

XVI. Wichtige Erkenntnisse

Der Digital Services Act schreibt DMARC, SPF, DKIM, MTA-STS oder TLS-RPT nicht namentlich vor.

Aber Plattformen, die in Europa tätig sind, sollten die Rolle vertrauenswürdiger E-Mail-Kommunikation für Nutzersicherheit, Plattformintegrität, Marktplatzbetrieb, Support-Workflows und Incident Response nicht ignorieren.

DMARC hilft, Exact-Domain-Spoofing zu reduzieren. SPF und DKIM liefern Authentifizierungssignale. MTA-STS und TLS-RPT unterstützen die Sichtbarkeit der Transportsicherheit.

Zusammen helfen diese Kontrollen Organisationen, eine besser vertretbare E-Mail-Vertrauensposition aufrechtzuerhalten.

Für DSA-relevante Plattformen lautet die Frage nicht nur:

„Verlangt der DSA explizit DMARC?“

Die wichtigere Frage lautet:

„Können wir nachweisen, dass Plattform-Kommunikation authentifiziert, überwacht, verwaltet und vor Domain-Missbrauch geschützt ist?“

Hier wird E-Mail-Authentifizierung strategisch wichtig.

Starten Sie DMARC-Monitoring mit Skysnag und erhalten Sie Ihren kostenlosen DMARC-Eintrag: