SPF-, DKIM- und DMARC-Records überwachen

SPF, DKIM und DMARC sind TXT-Records an drei genau definierten Stellen Ihrer DNS-Zone. Sie zu überwachen heißt: diese drei Stellen beobachten und eine Warnung bekommen, sobald sich ihr Inhalt ändert. Warum sich das lohnt: Ein kaputter Record verhindert den Versand nicht. Die Mails verlassen Ihren Server weiterhin, sie landen nur im Spam oder werden abgewiesen, und Sie merken es meist erst Tage später, wenn ein Kunde eine fehlende Rechnung erwähnt oder die Öffnungsraten einbrechen. Dieser Artikel zeigt, wo jeder Record liegt, durch welche Alltagsoperationen die drei kaputtgehen und wie Sie alle drei Stellen mit einer Warnung versehen.

Wo SPF, DKIM und DMARC in Ihrem DNS liegen

Mechanismus	DNS-Position	So sieht der Record aus
SPF	TXT auf dem Apex (example.com)	v=spf1 include:_spf.google.com ~all
DMARC	TXT auf _dmarc.example.com	v=DMARC1; p=quarantine; rua=mailto:reports@example.com
DKIM	TXT auf <selector>._domainkey.example.com	v=DKIM1; k=rsa; p=MIGfMA0GCSq...

Den DKIM-Selektor legt Ihr E-Mail-Anbieter fest, nicht Sie. Google Workspace nutzt google, Microsoft 365 nutzt selector1 und selector2, und jedes Versandtool (Mailchimp, SendGrid, Brevo) bringt einen eigenen mit. Eine Domain, die über drei Tools versendet, hat deshalb oft drei oder mehr veröffentlichte DKIM-Selektoren, und manche Anbieter arbeiten mit CNAME-Delegation statt mit einem direkten TXT-Record. Eine Auffrischung zu TXT-Records im Allgemeinen finden Sie unter DNS-Record-Typen erklärt.

Wie diese Records in der Praxis kaputtgehen

In keinem der folgenden Szenarien kommt ein Angreifer vor. Es sind Routineoperationen, ausgeführt von Leuten mit guten Absichten.

Das überschriebene SPF

Eine Domain darf genau einen SPF-Record haben. Das ist die häufigste Bruchstelle: Ein Kollege richtet ein neues CRM oder Newsletter-Tool ein, folgt der Anleitung des Anbieters und trägt dessen SPF-Record ins DNS ein, als neuen Eintrag oder anstelle des bestehenden. In beiden Fällen ist das Zusammenführen, das hätte stattfinden müssen, ausgeblieben, und alle anderen Absender der Domain fallen ab sofort durch die SPF-Prüfung.

Die zweite SPF-Falle ist das Limit von 10 DNS-Lookups. Jedes include: kostet Lookups, verschachtelte Includes zählen mit. Kommen genug Tools zusammen, überschreitet der Record das Limit, und empfangende Server werten ihn als permanenten Fehler, obwohl jeder einzelne Eintrag legitim ist.

Die DKIM-Schlüsselrotation

E-Mail-Anbieter rotieren ihre Signaturschlüssel. Dann validiert ein alter Selektor nicht mehr, oder ein neuer Selektor taucht auf, den niemand im DNS veröffentlicht hat. Die schmerzhafteste Variante ist das CNAME-Aufräumen: Viele Anbieter delegieren DKIM über CNAME-Records in ihre eigene Zone, und eine gut gemeinte Aktion "ungenutzte Records löschen" entfernt die Delegation. Ab diesem Moment schlägt die Signatur fehl, ohne jedes Geräusch.

Der DNS-Umzug, der TXT-Records verliert

Zieht eine Domain zu einem neuen DNS-Anbieter um, überstehen die sichtbaren Records den Umzug gut. A, MX und CNAME werden kopiert, weil Website und Postfach sonst laut ausfallen würden. Die Records mit Unterstrich, _dmarc und alles unter _domainkey, werden am häufigsten vergessen, gerade weil nichts sichtbar kaputtgeht, wenn sie fehlen.

Was eine strenge DMARC-Policy verstärkt

DMARC mit p=none beobachtet nur. Mit p=quarantine oder p=reject handeln die Empfänger: Ihre eigenen legitimen Mails landen im Spam oder werden abgewiesen, sobald SPF und DKIM beide am Alignment scheitern. Genau dafür ist der Mechanismus da, denn er stoppt Phishing-Mails in Ihrem Namen. Die Klinge schneidet aber in beide Richtungen: Eine verschärfte Policy macht aus einem stillen SPF-Überschreiben einen sofortigen Zustellungsausfall.

Seit 2024 verlangen Gmail und Yahoo von Massenversendern einen DMARC-Record. Falls diese Anforderung Sie zum Veröffentlichen gebracht hat, lautet die sichere Reihenfolge: erst überwachen, dann verschärfen.

Alle drei mit Domain Sentinel unter Beobachtung stellen

So läuft es mit dem DNS-Monitoring von Domain Sentinel konkret ab. Nehmen Sie Ihre Domain in die Watchlist auf und aktivieren Sie das DNS-Monitoring. Die Standardprüfungen decken die TXT-Records auf dem Apex ab, Ihr SPF wird also ohne weitere Einrichtung überwacht. Für die beiden anderen Stellen tragen Sie die Hostnames unter Extra names ein: _dmarc sowie jeden DKIM-Selektor, den Sie nutzen, etwa google._domainkey oder selector1._domainkey. Pro Domain sind zehn zusätzliche Namen möglich, was für eine Handvoll Versandtools reicht.

Ein ehrlicher Hinweis: Domain Sentinel findet Ihre DKIM-Selektoren nicht selbst. Sie müssen wissen, welche Selektoren Ihre Anbieter verwenden; die Liste steht in den Authentifizierungseinstellungen des jeweiligen Anbieters. Nehmen Sie sich fünf Minuten, um sie zusammenzustellen, bevor Sie die Überwachung einrichten.

Die Records werden einmal täglich geprüft. Ändert sich ein beobachteter TXT-Record, bekommen Sie eine E-Mail mit dem alten und dem neuen Wert. Ein überschriebenes SPF oder ein verschwundener _dmarc-Record fällt so am nächsten Tag auf, nicht erst Wochen später. Domain Sentinel erkennt Änderungen; es bewertet nicht, ob Ihre SPF-Syntax oder Ihre DMARC-Policy korrekt ist. Für diese einmalige Prüfung nehmen Sie einen dedizierten Checker und lassen danach das Monitoring das Ergebnis bewachen. Wie sich das in die Überwachung einer Domain insgesamt einfügt, steht in Was ist DNS-Monitoring.

Den aktuellen Stand prüfen

Bevor Sie irgendetwas einrichten, schauen Sie sich an, was heute veröffentlicht ist:

dig TXT example.com
dig TXT _dmarc.example.com
dig TXT google._domainkey.example.com

Setzen Sie Ihre eigene Domain und Ihre Selektoren ein. Kein Terminal zur Hand? Das DNS-Lookup-Tool nimmt einen Hostnamen entgegen, damit lesen Sie _dmarc und jeden Ihrer DKIM-Selektoren direkt im Browser.

Drei konkrete Schritte für diese Woche: jedes Tool inventarisieren, das für Ihre Domain E-Mails versendet, und seinen DKIM-Selektor notieren; die drei Abfragen oben ausführen und Fehlendes korrigieren; dann die drei Stellen unter Beobachtung stellen. Erst danach sollte DMARC von p=none auf eine strengere Policy wandern.