DNS-Gesundheit · November 2025

Glaubst du, deine E-Mail-Records sind korrekt? Prüfe lieber doppelt.

Viele Teams verlassen sich auf einmalige Audits. In der Praxis ändern SaaS-Anbieter ihre Anforderungen monatlich, neue Tools werden ohne Koordination mit dem IT-Team integriert, und DNS-Records veralten still und heimlich. Diese vollständige Checkliste hilft dir, typische Stolperfallen rechtzeitig zu erkennen und zu beheben.

Warum E-Mail-Records häufiger veralten als erwartet

DNS-Records für E-Mail-Authentifizierung gelten in vielen Unternehmen als "einmalig eingerichtet, dann fertig". Die Realität ist eine andere: Laut einer DMARCFlow-Auswertung aus dem Jahr 2024 haben 41 % der Unternehmen mindestens einen SPF-Include-Verweis, der auf einen inzwischen nicht mehr genutzten E-Mail-Provider zeigt. Jeder dieser veralteten Einträge verschlechtert deine Authentifizierungsquote und vergrößert die Angriffsfläche.

Typische Auslöser für stille Record-Probleme:

Das Marketing-Team wechselt den E-Mail-Dienstleister, vergisst aber den alten SPF-Include-Verweis zu entfernen.
Ein neues CRM oder eine neue E-Commerce-Plattform wird integriert, ohne DKIM-Signierung zu konfigurieren.
Ein DKIM-Selektor läuft ab oder der DNS-CNAME auf die Plattform des Anbieters wird ungültig, weil der Anbieter sein System migriert hat.
Ein neuer Mitarbeiter im IT-Team macht eine "kleine Anpassung" an der DNS-Zone, die unbeabsichtigt einen SPF-Mechanismus entfernt.

SPF: Die vollständige Prüfliste

SPF ist das am häufigsten fehlkonfigurierte Element der E-Mail-Authentifizierungs-Triade. Gehe diese Punkte systematisch durch:

Lookup-Limit: Zähle alle DNS-Abfragen, die dein SPF-Record auslöst (jedes include:, a:, mx: kostet einen Lookup). RFC 7208 erlaubt maximal 10. Ein Überschreiten führt zu einem permerror, der sich wie ein Authentifizierungsfehler verhält. Tools wie der DMARCFlow SPF-Prüfer zeigen die aktuelle Lookup-Zahl sofort an.
Mechanismen-Reihenfolge: Platziere spezifische Allowlist-Mechanismen (ip4:, ip6:) vor generischen Includes. Das verhindert, dass legitime IP-Adressen durch einen früh greifenden Treffer falsch bewertet werden.
Abschluss-Mechanismus: Endet dein Record mit -all (hardfail) oder ~all (softfail)? Für Domains mit DMARC p=reject ist ~all ausreichend und sicherer, da einige Weiterleitungsszenarien mit -all Probleme verursachen.
Veraltete Includes: Überprüfe jeden include:-Verweis. Existiert der referenzierte Domain-Record noch? Liefert er einen gültigen SPF zurück? Handles auf eingestellte Provider wie alte ESP-Infrastruktur sind ein häufiger Fehler.
Marketing-Tool-Monitoring: Viele E-Mail-Marketing-Plattformen fügen automatisch neue Versand-IPs zu ihren SPF-Records hinzu. Diese Änderungen landen dann in deinem Lookup-Budget, ohne dass du es merkst. Abonniere die Changelog-Benachrichtigungen deiner Provider.

DKIM: Selektoren überwachen und versionieren

DKIM-Probleme sind heimtückischer als SPF-Fehler, weil sie nicht sofort zu Bounces führen, sondern die DKIM-Signatur einfach fehlt oder ungültig ist – was erst in den DMARC-Aggregatberichten sichtbar wird.

Selektoren-Inventar: Liste alle aktiven DKIM-Selektoren auf. Für jeden Selektor: Welcher Provider oder welches System nutzt ihn? Wann wurde er zuletzt rotiert? Ist der öffentliche Schlüssel im DNS noch identisch mit dem, was der Provider als privaten Schlüssel nutzt?
CNAME-Delegationen prüfen: Viele Provider nutzen CNAME-Delegierungen für DKIM (selektor._domainkey.deinedomain.de CNAME selektor._domainkey.provider.com). Wenn der Provider sein DNS umzieht oder einen Dienst einstellt, kann diese CNAME-Kette brechen. Überprüfe alle CNAME-Delegationen regelmäßig auf Auflösbarkeit.
Schlüssellänge: Schlüssel unter 1024 Bit gelten als unsicher und werden von einigen Mailprovidern abgelehnt. Der Standard ist heute 2048 Bit, RSA oder EdDSA. Überprüfe die Schlüssellänge für alle aktiven Selektoren.
Alte Selektoren deaktivieren: Wenn du einen Provider wechselst oder einen neuen Selektor aktivierst, entferne den alten DNS-Record. Aktive aber nicht genutzte Selektoren erhöhen die Angriffsfläche, weil ein Angreifer theoretisch versuchen könnte, den alten Selektor für gefälschte Signaturen zu nutzen.

DMARC: Policy, Reporting und Subdomain-Handling

DMARC-Fehlkonfigurationen sind oft weniger offensichtlich als SPF- oder DKIM-Probleme, haben aber strategische Auswirkungen auf deinen Sicherheitsgrad:

rua-Postfach erreichbar und nicht überfüllt: Wenn die Mailbox für Aggregatberichte nicht mehr erreichbar ist oder übervoll ist, verwerfen Provider die Berichte. Du verlierst damit deine Sichtbarkeit über Sendeaktivitäten. Richte die rua-Adresse auf ein Postfach, das regelmäßig überwacht wird, oder nutze einen DMARC-Analyse-Service wie DMARCFlow, der Reports direkt parst.
Subdomain-Policy explizit setzen: Ohne expliziten sp=-Parameter erben Subdomains die DMARC-Policy der Root-Domain. Das kann gewünscht sein oder nicht. Wenn Subdomains eigene Policies benötigen (z.B. mail.deinedomain.de auf p=none wegen Weiterleitung), setze das explizit.
Reporting-Intervall prüfen: Der Parameter ri= definiert das gewünschte Berichtsintervall in Sekunden (Standard: 86400 = 24h). Provider halten sich nur bedingt daran, aber ein expliziter Wert signalisiert deine Präferenz.
pct-Parameter bei policy-Eskalation: Wenn du die Policy von p=none auf p=quarantine hochfährst, nutze den pct=-Parameter für einen schrittweisen Rollout: pct=10 → pct=50 → pct=100. Das gibt dir die Möglichkeit, unbekannte Probleme zu erkennen, bevor alle Mails betroffen sind.

Regelmäßige Kontrollen automatisieren

Ein einmaliger Audit löst das Problem nicht dauerhaft. Richte ein regelmäßiges Health-Check-Verfahren ein:

Monatlicher automatischer Scan: DMARCFlow überprüft deine DNS-Records täglich und alertet dich bei Veränderungen. Alternativ kannst du mit einem einfachen Shell-Script oder CI/CD-Job die aktuellen DNS-Records mit einer Soll-Konfiguration aus Git vergleichen.
Vierteljährliches Provider-Review: Überprüfe einmal pro Quartal, welche E-Mail-Provider du aktiv nutzt, und räume SPF-Includes und DKIM-Selektoren von inaktiven Providern auf.
Onboarding-Checkliste für neue Tools: Jedes neue SaaS-Tool, das E-Mails im Namen deiner Domain senden soll, durchläuft einen definierten Prozess: SPF-Eintrag prüfen, DKIM konfigurieren, Alignment testen, DMARC-Report prüfen, Freigabe durch IT-Sicherheit.
DMARC-Berichte als Frühwarnsystem: Neue unbekannte Quellen in deinen Aggregatberichten sind das erste Zeichen, dass entweder ein neues System ohne Genehmigung integriert wurde oder ein Angriff läuft. Schalte DMARCFlow-Alerts ein, um sofort benachrichtigt zu werden.

Starte mit dem DMARCFlow DMARC-Prüfer und dem SPF-Prüfer – beide zeigen dir den aktuellen Status in unter 30 Sekunden, kostenlos und ohne Registrierung.