DMARC Enforcement — Allgemeine Anleitung

Provider-unabhängige Roadmap: E-Mail-Quellen inventarisieren, Drittanbieter onboarden, Legacy-Systeme absichern und Policy schrittweise von p=none über p=quarantine zu p=reject verschärfen.

Alle Provider · Enforcement-Roadmap

DMARC Enforcement — Provider-unabhängig

DMARC-Enforcement ist eine reine DNS-Konfiguration: Unabhängig davon, welchen E-Mail-Provider oder DNS-Anbieter Sie nutzen, brauchen Sie nur DNS-Zugriff auf Ihren _dmarc-TXT-Record und ein externes Monitoring-Tool. Das E-Mail-Sender-Inventar ist die wichtigste Vorbereitung — ohne vollständige Liste aller sendenden Quellen ist p=reject zu riskant.

Diese Anleitung gilt für alle E-Mail-Provider, die nicht separat dokumentiert sind — und ebenso als universelle Referenz, wenn Sie mehrere Systeme parallel betreiben. Vier universelle Regeln gelten immer: DNS-Zugriff ist Voraussetzung für Änderungen am _dmarc.ihre-domain.de-Record. Die TTL sollte während der Migration auf 300 Sekunden gesenkt werden, damit Rollbacks schnell wirksam werden. Ein externes Monitoring-Tool für DMARC-Aggregate-Reports ist unverzichtbar, da kein Provider eine vollständige Report-Analyse integriert. Alle E-Mail-Quellen müssen dokumentiert sein, bevor die Policy verschärft wird. Der Wolf-Agents Email Security Scanner prüft Ihre aktuelle DMARC-Policy als Teil von 165 Prüfpunkten. Falls Sie DMARC noch nicht eingerichtet haben, starten Sie mit der allgemeinen DMARC-Anleitung. Nach Erreichen von p=reject ist der nächste Hardening-Schritt MTA-STS Generic-Anleitung — Transport-Verschlüsselung erzwingen.

Unabhängig von Ihrem E-Mail-Provider oder DNS-Anbieter: NIS2 Art. 21 fordert Maßnahmen nach dem Stand der Technik für die Kommunikationssicherheit. Das BSI empfiehlt p=reject in TR-03182. Die Verantwortung liegt beim Domaininhaber — nicht beim Provider. §38 BSIG macht die Geschäftsleitung persönlich haftbar. DMARC-Enforcement ist eine reine DNS-Konfiguration: Sie brauchen nur Zugriff auf Ihre DNS-Verwaltung und ein Monitoring-Tool. Wolf-Agents begleitet Sie mit kontinuierlichem Monitoring auf dem gesamten Weg zu p=reject.

1 Phase 1 von 4

Beobachtungsphase — Sender-Inventar anlegen

Legen Sie den DMARC-Record als TXT-Record für _dmarc.ihre-domain.de mit p=none in Ihrer DNS-Verwaltung an. Setzen Sie die TTL sofort auf 300 Sekunden — so können Sie spätere Anpassungen schnell ausrollen. Richten Sie parallel ein externes Monitoring-Tool (dmarcian, Postmark DMARC oder EasyDMARC) ein, da kein Provider eine vollständige Report-Analyse bietet. Sammeln Sie die Aggregate Reports 2–4 Wochen, bevor Sie die erste Policy-Verschärfung vornehmen — und nutzen Sie diese Zeit, um Ihr E-Mail-Sender-Inventar systematisch aufzubauen.

Das E-Mail-Sender-Inventar: Die wichtigste Vorbereitung

  1. Hauptmailserver: Eigener Server oder Hosting-Provider-Mailserver — SPF und DKIM müssen pass liefern, bevor Enforcement beginnt
  2. Newsletter- und Marketing-Tools: Externe Dienste wie Mailchimp, CleverReach oder Brevo senden unter Ihrer Domain — nur pass, wenn Custom-DKIM aktiviert und im SPF-Record erfasst ist
  3. CRM- und Ticketsysteme: Drittanbieter-Software (HubSpot, Salesforce, Zendesk) versendet häufig transaktionale E-Mails unter Ihrer Domain — vollständig inventarisieren und korrekt onboarden
  4. Legacy-Systeme und IoT: Alte ERP-Systeme, Drucker oder Monitoring-Tools versenden E-Mails oft über rudimentäres SMTP — SMTP-Relay oder Cloud-Relay-Integration als Lösung planen
2–3 Phase 2 + 3

Quarantäne und Reject — Schrittweise Verschärfung

Erst wenn Ihr Sender-Inventar vollständig ist und alle Quellen in den Reports SPF- oder DKIM-pass zeigen, wechseln Sie zu p=quarantine; pct=10. Durch die kurze TTL von 300 Sekunden ist ein Rollback innerhalb von Minuten wirksam — nutzen Sie diesen Sicherheitspuffer aktiv. Die pct-Erhöhung erfolgt ausschließlich über Änderungen am TXT-Record in Ihrer DNS-Verwaltung, ohne weitere Systemkonfigurationen. Wolf-Agents überwacht Ihre DMARC-Policy kontinuierlich und schlägt bei unerwarteten Rückschritten oder neuen fail-Quellen sofort Alarm.

Universelle Regeln für sicheres Enforcement

  1. DNS-Zugriff sicherstellen: Vergewissern Sie sich vor Phase 2, dass Sie selbstständig und schnell TXT-Records in Ihrer DNS-Zone ändern können — ohne Abhängigkeit von externen Support-Tickets
  2. TTL auf 300s halten: Während der gesamten Enforcement-Phase TTL niedrig halten — erst nach stabilem p=reject auf höhere Werte (z. B. 3600s) zurücksetzen
  3. Schrittweise pct-Erhöhung: pct=10 → pct=25 → pct=50 → pct=100, je Stufe mindestens 1–2 Wochen warten und Reports analysieren, bevor weiter erhöht wird
  4. Prozess für neue Dienste dokumentieren: Jeder neue E-Mail-Service muss zuerst SPF/DKIM-konform konfiguriert und in den Reports verifiziert werden, bevor er produktiv geht
Terminal / PowerShell Verifikation
# Linux / macOS
dig _dmarc.ihre-domain.de TXT +short

# Windows (PowerShell)
Resolve-DnsName -Name _dmarc.ihre-domain.de -Type TXT | Select-Object -ExpandProperty Strings

# Erwartete Ausgabe nach Phase 3:
# "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-reports@ihre-domain.de; fo=1"

Häufige Probleme beim DMARC-Enforcement

Die folgenden drei Probleme treten unabhängig vom Provider bei nahezu jedem DMARC-Enforcement-Projekt auf. Sie entstehen typischerweise durch unvollständige Sender-Inventare, fehlende Drittanbieter-Konfiguration oder Legacy-Systeme ohne DKIM-Fähigkeit.

Shadow IT: Unbekannte E-Mail-Quellen entdeckt

Symptom: DMARC-Reports zeigen unbekannte IP-Adressen mit SPF/DKIM fail, die nicht im Sender-Inventar stehen.

Ursache: Abteilungen haben eigenständig Tools eingerichtet (Umfrage-Tools, Ticketsysteme, CRM-Testaccounts) ohne die IT zu informieren — diese versenden E-Mails unter der Unternehmens-Domain, ohne korrekte SPF/DKIM-Konfiguration.

Lösung: Alle Abteilungen befragen und unbekannte IPs über WHOIS/Reverse DNS zuordnen. Services entweder korrekt onboarden (SPF-include: hinzufügen, Custom-DKIM aktivieren) oder den E-Mail-Versand auf autorisierte Kanäle migrieren. Erst nach vollständiger Klärung die Policy verschärfen.

Drittanbieter ohne Custom-DKIM-Signierung

Symptom: Newsletter-Tool oder CRM zeigt DKIM fail — die DKIM-Signatur nutzt die Domain des Anbieters statt Ihrer eigenen Domain.

Ursache: Custom-Domain-Authentifizierung beim Drittanbieter nicht aktiviert. Der Anbieter signiert mit seiner eigenen DKIM-Domain, was für DMARC-Alignment nicht ausreicht.

Lösung: Bei jedem Drittanbieter Custom-DKIM-Signierung mit d=ihre-domain.de aktivieren. CNAME-Records gemäß Anbieter-Dokumentation im DNS veröffentlichen und mit dem Wolf-Agents Email Security Scanner verifizieren, dass DKIM-Alignment korrekt ist.

Legacy-System ohne DKIM-Support

Symptom: Altes ERP, Ticketsystem oder IoT-Gerät sendet E-Mails, die DKIM fail zeigen — eine direkte DKIM-Konfiguration am System ist nicht möglich.

Ursache: Legacy-System spricht nur rudimentäres SMTP ohne DKIM-Fähigkeit — die Software-Version unterstützt keine Signierung, und ein Update ist nicht möglich oder zu aufwendig.

Lösung: SMTP-Relay einrichten — das Legacy-System sendet an einen internen Relay-Server, der mit DKIM signiert. Alternativ: E-Mail-Versand über einen Cloud-Provider-Relay leiten (M365 Connector, Google SMTP-Relay), der DKIM-Signierung für eingehende SMTP-Verbindungen übernimmt.

Wie steht Ihre Domain bei DMARC Enforcement?

Prüfen Sie es jetzt — kostenlos, ohne Registrierung, mit 165 Prüfpunkte.