Implementierung · November 2025

So führst du DMARC ohne Chaos ein

DMARC ist kein DNS-Schnipsel, den du einmal einträgst und vergisst. Es ist ein Governance-Projekt, das Inventur, Koordination zwischen IT, Marketing und Legal sowie kontinuierliches Monitoring erfordert. Wer diese Schritte überspringt, landet schnell mit einer p=reject-Policy, die legitime E-Mails blockiert – ein Produktionsfehler, der sich vermeiden lässt.

Schritt 1: Domain-Inventur und Verantwortlichkeiten klären

Bevor du einen einzigen DNS-Record änderst, brauchst du eine vollständige Liste aller Domains und Subdomains, die dein Unternehmen besitzt oder betreibt. Dazu gehören nicht nur die offensichtlichen primären Domains, sondern auch:

  • Legacy-Domains aus früheren Firmennamen oder Übernahmen
  • Subdomains für Marketing-Tools, Helpdesk-Systeme, E-Commerce-Shops
  • Domains, die als Weiterleitungen registriert sind, aber potenziell für Spoofing missbraucht werden können

Für jede Domain benennst du einen technischen Verantwortlichen (meist IT) und einen Business-Owner (der Bereich, der von dieser Domain E-Mails versendet). Diese Zuordnung ist entscheidend, wenn du später Policy-Änderungen freigeben musst und sicherstellen willst, dass kein Mailstream vergessen wurde.

Definiere außerdem dein Ziel: Willst du primär Phishing-Angriffe auf Kundendaten stoppen, die Zustellrate transaktionaler E-Mails verbessern, eine Compliance-Anforderung erfüllen, oder alle drei? Die Zielperspektive bestimmt, in welcher Reihenfolge du Domains priorisierst und wie schnell du die Policy hochfahren kannst.

Schritt 2: Bestehende SPF- und DKIM-Records prüfen und bereinigen

Vor dem DMARC-Record müssen SPF und DKIM funktionieren – sonst scheitert die Authentifizierung und dein legitimes Mail landet im Spam. Typische Probleme, die du in dieser Phase findest:

  • SPF: Mehr als 10 DNS-Lookups. Jeder include:-Mechanismus kostet einen Lookup. Viele gewachsene Konfigurationen überschreiten das RFC-Limit, was zu einem permerror führt – die E-Mail gilt als nicht authentifiziert. Lösung: Mechanismen konsolidieren, IPAddressbereiche direkt eintragen oder einen SPF-Flattening-Service nutzen.
  • SPF: Veraltete Includes. Wenn dein Marketing-Tool gewechselt hat, der alte Include-Verweis aber noch im Record steht, vergrößert das die Angriffsfläche unnötig. Bereinige alle Includes, die keinem aktiven Sendesystem mehr entsprechen.
  • DKIM: Fehlende Selektoren. Transaktionale Mailsysteme, CRM und Marketing-Automation müssen DKIM-signiert sein. Überprüfe für jede sendende Plattform, ob ein gültiger DKIM-Record im DNS hinterlegt ist und ob die Signatur tatsächlich in ausgehenden Mails landet.
  • Alignment: Signing-Domain muss mit der Header-From-Domain übereinstimmen. Wenn dein ESP mit einer eigenen Domain signiert (d=esp.example.com), aber die Header-From-Adresse @deinunternehmen.de zeigt, scheitert das DKIM-Alignment. Konfiguriere den ESP so, dass er unter deiner eigenen Domain signiert oder nutze eine CNAME-Delegation.

Schritt 3: DMARC p=none mit Reporting einrichten

Sobald SPF und DKIM für die wichtigsten Mailstreams funktionieren, veröffentlichst du den DMARC-Record im Monitoring-Modus:

v=DMARC1; p=none; rua=mailto:dmarc@deinedomain.de; ruf=mailto:forensics@deinedomain.de; fo=1; ri=86400

Die wichtigsten Parameter:

  • rua: E-Mail-Adresse für aggregierte Berichte (täglich von jedem Mailprovider, der Mail von deiner Domain empfangen hat). Diese Berichte zeigen dir, welche Systeme in deinem Namen senden und wie hoch der Anteil authentifizierter Nachrichten ist.
  • ruf: Adresse für forensische Einzel-Reports (bei Authentifizierungsfehlern). Nicht alle Provider senden diese, aber die, die es tun, liefern wertvolle Hinweise auf konkrete Spoofing-Versuche.
  • fo=1: Forensische Reports auch bei SPF- oder DKIM-Einzelfehlern senden (nicht nur wenn beide fehlschlagen).

Lass die Reports mindestens 30 Tage akkumulieren, bevor du die Policy änderst. In dieser Phase entdeckst du regelmäßig vergessene Sendesysteme: alte Newsletter-Tools, Partner-Integrationen oder interne Monitoring-Systeme, die E-Mails über deine Domain verschicken.

Schritt 4: Reports auswerten und Sendesysteme bereinigen

DMARC-Aggregatberichte kommen im XML-Format und sind ohne Tool kaum lesbar. DMARCFlow parst diese Berichte automatisch und zeigt dir eine Übersicht pro Quelle: IP-Adresse, Sendevolumen, SPF-Ergebnis, DKIM-Ergebnis, Alignment-Status.

Für jede Quelle, die nicht besteht, triffst du eine von vier Entscheidungen:

  1. Konfigurieren: SPF-Eintrag oder DKIM-Signatur für dieses System ergänzen.
  2. Migrieren: System auf einen anderen Mailstream umstellen, der bereits korrekt authentifiziert ist.
  3. Abschalten: Legacy-System, das ohnehin nicht mehr genutzt wird – Record entfernen, System abschalten.
  4. Akzeptieren mit Ausnahme: In seltenen Fällen kann ein System technisch nicht auf DKIM umgestellt werden. Dokumentiere die Ausnahme und plane die Migration.

Schritt 5: Policy auf p=quarantine hochfahren

Sobald 95–98 % des legitimen Volumens SPF- oder DKIM-Alignment besteht, ist der Zeitpunkt für p=quarantine gekommen. Gehe dabei schrittweise vor:

  1. Ändere die Policy zunächst mit pct=10: Nur 10 % der Mails, die DMARC nicht bestehen, werden in den Spam-Ordner verschoben, 90 % werden weiterhin zugestellt. Das gibt dir die Möglichkeit, unbekannte Probleme zu erkennen, bevor alle Mails betroffen sind.
  2. Beobachte eine Woche lang Bounce-Raten und Kundenfeedback. Steigt nichts ungewöhnlich an, erhöhe auf pct=50, dann pct=100.
  3. Nach zwei bis drei Wochen stabiler Betrieb unter p=quarantine pct=100 bist du bereit für den letzten Schritt.

Schritt 6: Policy auf p=reject finalisieren

p=reject ist der Zielzustand: Jede E-Mail, die das DMARC-Alignment nicht besteht, wird vom empfangenden Mailserver abgewiesen – sie kommt nicht in den Spam-Ordner, sie kommt gar nicht an. Das ist der einzige Status, der Spoofing technisch unterbindet.

Vor der Umstellung auf p=reject:

  • Stelle sicher, dass alle bekannten Sendesysteme korrekt konfiguriert sind.
  • Informiere interne Teams (Marketing, Vertrieb, IT), damit niemand eine neue E-Mail-Integration startet, ohne SPF/DKIM zu konfigurieren.
  • Beobachte die Aggregatberichte nach der Umstellung täglich für die ersten zwei Wochen – neu auftauchende Quellen müssen schnell bewertet werden.

Schritt 7: Betriebsphase und kontinuierliches Monitoring

DMARC ist kein einmaliges Projekt. Neue SaaS-Tools werden integriert, DNS-Konfigurationen werden ohne Koordination geändert, und Angreifer testen regelmäßig neue Spoofing-Varianten. Die Betriebsphase erfordert:

  • Monatliche Überprüfung der Aggregatberichte auf neue oder unbekannte Quellen
  • Automatisierte Alerts, wenn eine neue IP-Adresse im Namen deiner Domain sendet (DMARCFlow sendet diese Alerts per E-Mail, Slack oder Webhook)
  • Halbjährliche Audits aller DNS-Records: SPF auf Lookup-Zahl, DKIM auf Schlüssellänge und Gültigkeit, DMARC auf Policy-Konsistenz über alle Domains
  • Prozess für das Onboarding neuer Mailsysteme: Bevor ein neues Tool E-Mails über deine Domain senden darf, muss SPF/DKIM konfiguriert und getestet sein

Du brauchst Unterstützung? Buche Onboarding mit DMARCFlow – wir begleiten dich von der Analyse bis zur Policy p=reject, einschließlich aller Dokumentation für Compliance- und Versicherungsaudits.