Zum Hauptinhalt springen

TXT-Record-Abfrage

Überprüfen Sie SPF, DKIM, DMARC und Ihre Textkonfigurationen

Probleme mit der E-Mail-Authentifizierung? Überprüfen Sie, ob Ihre TXT-Records für SPF, DKIM und DMARC korrekt veröffentlicht und propagiert sind.

Im iterativen Tracemodus wird der Resolver ignoriert.
Fragt mehrere öffentliche Resolver ab, um die Antworten zu vergleichen.

SPF, DKIM, DMARC

Zeigen Sie E-Mail-Authentifizierungsrecords an. Identifizieren Sie schnell Syntaxfehler oder fehlende Records.

Domain-Verifizierungen

Zeigen Sie Verifizierungstoken (Google, Microsoft, etc.) an, die in Ihrer DNS-Zone veröffentlicht sind.

Vollständige Syntax

Sehen Sie den vollständigen Wert jedes TXT, auch bei langen Records mit Verkettung.

Multi-Resolver

Vergleichen Sie Antworten von Google, Cloudflare, Quad9, um Propagierungsprobleme zu erkennen.

Kostenlos und unbegrenzt

Testen Sie so viele Domains wie nötig. Keine Anmeldung erforderlich.

Wie Sie die Optionen der DNS-Suchmaschine effektiv nutzen

Was ist der iterative Trace?

Der Trace führt die Auflösung Schritt für Schritt aus. Der Resolver fragt zuerst die Root-Server ab, dann die des TLD (.com, .fr, .eu) und anschließend die autoritativen Server der Zielzone. In jedem Schritt zeigt die Seite den abgefragten Server, die Antwort, den RCODE und die Latenz an.

  1. 1. Root

    Ermittlung der TLD-Server für den angefragten Namen.

  2. 2. TLD

    Verweis auf die NS der Zone (Delegation).

  3. 3. Autoritative Server

    Endgültige Antwort (oder Fehler) mit TTL und Latenz.

Wozu dient das?

  • Antworten nach Resolvern und Regionen vergleichen
  • Einen warmen Cache, einen zu langen TTL oder eine unvollständige Delegation erkennen
  • Einen Latenzunterschied oder einen unerwarteten RCODE erklären

Tipp: Lassen Sie den Trace für schnelle Checks deaktiviert; aktivieren Sie ihn, wenn Sie untersuchen oder ein Ticket/Post‑Mortem vorbereiten.

Was ist der klassische Trace?

Der klassische Trace befragt nur den ausgewählten Resolver (UDP oder DoH) und zeigt die Antwort so, wie sie von diesem Netzpunkt wahrgenommen wird. Sie erhalten den RCODE, die Antwortsektionen sowie die Latenz auf dem Abschnitt Client → Resolver.

  1. 1. Gewählter Resolver

    Verwendet das Preset oder die individuelle Konfiguration, um die Anfrage genau wie Ihr Dienst auszuführen.

  2. 2. Protokoll beibehalten

    Respektiert das ausgewählte Transportprotokoll (UDP, TCP oder DoH), um das reale Verhalten nachzustellen.

  3. 3. Detaillierte Antwort

    Zeigt die Bereiche Question, Answer und Authority/Additional, sofern vorhanden, mitsamt TTL und hilfreichen Metadaten.

Warum nutzen?

  • Die Sicht eines bestimmten Resolvers prüfen, bevor Sie die Delegation verdächtigen
  • Zwischengespeicherte Werte und die Wirkung eines TTL oder Flushs bestätigen
  • Eine Auflösung dokumentieren, wie sie ein Client oder Microservice erlebt

Tipp: Lassen Sie die Option für den iterativen Trace deaktiviert, wenn Sie einen bestimmten Resolver auditieren; aktivieren Sie sie anschließend, um den Pfad Root → TLD → Autoritativ zu vergleichen.

Wie funktioniert der Propagationstest?

Der Test befragt parallel eine Reihe öffentlicher Resolver (Google, Cloudflare, Quad9, OpenDNS, ISPs …) und gruppiert die Antworten nach Inhalt und RCODE. Sie sehen sofort, wer die Aktualisierung bereits übernommen hat.

  1. 1. Multipoint-Resolver

    Aktiviert die Propagations-Presets, um mehrere Akteure weltweit abzufragen.

  2. 2. Automatischer Vergleich

    Gruppiert identische Antworten und hebt Abweichungen oder resolver-spezifische Fehler hervor.

  3. 3. Verwertbare Zusammenfassung

    Liefert eine klare Übersicht, die Resolverliste, deren Latenzen und den Status jeder Gruppe.

Wann einsetzen?

  • Verfolgen, wie sich eine DNS-Änderung weltweit verbreitet
  • Veraltete Caches erkennen und über einen gezielten Flush entscheiden
  • Einen Propagationsstatus in einem Ticket oder Post-Mortem teilen

Tipp: Während des Propagationstests ist die Resolverauswahl gesperrt. Deaktivieren Sie den Modus, um zur Einzelanalyse zurückzukehren.

Was ist ein TXT-Record?

Ein TXT-Record (Text) veröffentlicht beliebigen Text, der mit einem Domainnamen verbunden ist. Es ist ein vielseitiges Format, das für viele Anwendungen verwendet wird, einschließlich E-Mail-Authentifizierung und Eigentumsverifizierung.

TXT-Record-Struktur:

FeldBeschreibungBeispiel
NameDie Domain oder Subdomain@ oder _dmarc
TypImmer TXTTXT
WertFreitext"v=spf1 include:_spf.google.com -all"
TTLCache-Dauer in Sekunden3600

Gängige TXT-Records

SPF (Sender Policy Framework)

Veröffentlicht am Domain-Root. Definiert Server, die berechtigt sind, E-Mails zu senden.

captaindns.com.  3600  IN  TXT  "v=spf1 include:_spf.google.com -all"

DKIM (DomainKeys Identified Mail)

Veröffentlicht bei selector._domainkey.domain.com. Enthält den öffentlichen Schlüssel zur Signaturprüfung.

selector._domainkey.captaindns.com.  3600  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBg..."

DMARC (Domain-based Message Authentication)

Veröffentlicht bei _dmarc.domain.com. Definiert die Richtlinie bei SPF/DKIM-Fehlern.

_dmarc.captaindns.com.  3600  IN  TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc@captaindns.com"

Best Practices

SPF

RegelErklärung
Nur ein SPF-RecordMehrere v=spf1 verursachen Fehler
Maximal 10 DNS-LookupsZählen Sie include, a, mx (nicht ip4/ip6)
Mit -all oder ~all beendenDefiniert Standardverhalten

DKIM

RegelErklärung
Mindestens 2048-Bit-SchlüsselRSA 1024 Bit ist veraltet
Ein Selektor pro DienstErleichtert Rotation

DMARC

RegelErklärung
Mit p=none beginnenBeobachten ohne Blockieren während der Einrichtung
rua konfigurierenBerichte für Diagnose erhalten

Ergänzende Tools

ToolZweck
SPF-InspektorDetaillierte SPF-Analyse und Validierung
DKIM-InspektorDKIM-Schlüssel und Signaturprüfung
DMARC-InspektorDMARC-Richtlinienanalyse
E-Mail-TesterVollständiger SPF/DKIM/DMARC-Test von Ihrem Server

Nützliche Ressourcen