TXT-Records erklärt: SPF, DKIM und DMARC

Ein TXT-Record enthält beliebigen Text, der an einen Domainnamen gebunden ist. Das klingt banal, doch genau darüber wird das gesamte E-Mail-Vertrauenssystem veröffentlicht — dazu der Großteil der Domain-Inhaberschaftsprüfungen, die Sie je durchführen werden.

Das Kernproblem ist, dass SMTP, 1982 entworfen, jedem Server erlaubt, als beliebige Domain zu senden. Nichts im Protokoll verhindert das. SPF, DKIM und DMARC sind drei Schichten, die nachträglich aufgesetzt wurden, um das zu beheben, und alle drei liegen in TXT-Records.

SPF: welche Server als Sie senden dürfen

SPF (Sender Policy Framework) veröffentlicht eine Liste von Servern, die für Ihre Domain Mails versenden dürfen. Ein empfangender Server vergleicht die verbindende IP mit dieser Liste.

example.com.    3600    IN    TXT    "v=spf1 include:_spf.google.com ip4:93.184.216.34 ~all"

DKIM: eine kryptografische Signatur

DKIM (DomainKeys Identified Mail) signiert jede ausgehende Nachricht mit einem privaten Schlüssel. Sie veröffentlichen den passenden öffentlichen Schlüssel im DNS, und Empfänger prüfen die Signatur.

selector1._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEB..."

Der Teil selector1 wird von Ihrem Mail-Anbieter gewählt und in jeder signierten Nachricht mitgeführt, sodass Empfänger wissen, welchen Schlüssel sie abrufen müssen. Mit Selectors können Sie Schlüssel rotieren oder mehrere Anbieter parallel betreiben, ohne Konflikte.

Der Vorteil von DKIM gegenüber SPF ist, dass die Signatur die Nachricht selbst abdeckt und deshalb Weiterleitungen übersteht. Seine Schwäche ist, dass es nichts über Nachrichten aussagt, die ganz ohne Signatur eintreffen — genau diese Lücke schließt DMARC.

DMARC: was zu tun ist, wenn die ersten beiden scheitern

DMARC (Domain-based Message Authentication, Reporting and Conformance) verbindet die beiden anderen: Es verlangt, dass SPF oder DKIM nicht nur bestehen, sondern mit der sichtbaren From-Adresse übereinstimmen (Alignment), und es sagt Empfängern, was bei einem Fehlschlag zu tun ist.

_dmarc.example.com.    IN    TXT    "v=DMARC1; p=quarantine; rua=mailto:reports@example.com; pct=100"

Alle drei sicher einführen

Die Reihenfolge ist entscheidend. Direkt zu p=reject zu gehen ist der klassische Weg, die eigenen Rechnungen unzustellbar zu machen.

1. 1

   Alles erfassen, was als Sie sendet

   Ihr Mail-Anbieter, ja — aber auch Rechnungstools, CRM, Marketingplattformen, Ticketsysteme und die Transaktionsmails Ihrer App. Alles, was hier übersehen wird, geht später kaputt.

2. 2

   SPF mit Soft Fail veröffentlichen

   Nehmen Sie jeden Absender aus Schritt eins auf und enden Sie mit ~all. Soft Fail markiert nicht aufgeführte Absender als verdächtig, ohne Mails zu zerstören, während Sie die Liste prüfen.

3. 3

   DKIM-Signierung aktivieren

   Schalten Sie sie bei jedem Anbieter ein und veröffentlichen Sie die Selector-Records, die er Ihnen gibt. Senden Sie eine Testnachricht und bestätigen Sie, dass die Signatur verifiziert wird.

4. 4

   DMARC bei p=none beginnen

   Nur Überwachung. Sammeln Sie zwei bis vier Wochen lang aggregierte Berichte — sie decken Absender auf, die Sie vergessen hatten.

5. 5

   Schrittweise verschärfen

   Sobald Berichte nur noch legitime Quellen als bestanden zeigen, wechseln Sie zu p=quarantine, gegebenenfalls zunächst mit pct=25, und dann zu p=reject, wenn alles sauber ist.

TXT-Records sind nicht nur für E-Mail da

Derselbe Record-Typ trägt die Domain-Inhaberschaftsprüfung für Dutzende Dienste — Google Search Console, Microsoft 365, Facebook und andere verlangen, dass Sie ein Token als TXT-Record veröffentlichen, und prüfen dann dessen Vorhandensein.

example.com.    IN    TXT    "google-site-verification=rXsLp2..."
example.com.    IN    TXT    "MS=ms12345678"

Diese koexistieren problemlos. Eine Domain kann viele TXT-Records haben; die Regel lautet nur, dass es genau einen mit dem Anfang v=spf1 geben muss.

Prüfen Sie jede Domain mit dem Lookup-Tool, um alle ihre TXT-Records zusammen zu sehen — ein schneller Weg, einen doppelten SPF-Record oder ein nie entferntes Verifizierungs-Token zu entdecken.