MX- und TXT-Einträge erklärt

Was sind MX-Einträge?

Ein MX-Eintrag mappt eine Domain auf einen oder mehrere Mail Exchanger, jeweils mit einer Prioritätszahl. Absender versuchen zuerst die niedrigste Zahl; gleiche Prioritäten können lastverteilt werden. Beispiel: `10 mail.example.com` und `20 mail-backup.example.com`.

MX-Ziele müssen Hostnamen mit A- oder AAAA-Einträgen sein — keine nackten IP-Adressen. Nach MX-Änderungen mit dem DNS Checker prüfen und TTL-Ablauf auf alten Caches abwarten. Kombinieren Sie MX-Checks mit dem Blacklist Checker, wenn eingehende Mail plötzlich im Spam landet.

Produktions-Domains sollten mindestens zwei MX-Hosts in verschiedenen Netzen veröffentlichen. Ist der primäre Exchanger nicht erreichbar, versuchen Absender gemäß RFC 5321 den nächsten Prioritätswert. Dokumentieren Sie beide Prioritäten in Change-Tickets und führen Sie nach jedem MX-Edit den DNS Checker erneut aus, damit Support-Threads live Prioritäten zeigen, keine Panel-Screenshots.

Was sind TXT-Einträge?

TXT-Einträge speichern beliebige Textstrings. Mail-Betreiber veröffentlichen SPF am Apex (oder Legacy-Subdomain) als `v=spf1 ...`, DKIM als Selektoren wie `default._domainkey.example.com` und DMARC unter `_dmarc.example.com`. Site-Verifizierung nutzt kurze Tokens (`google-site-verification=...`, `MS=ms...`).

Mehrere Strings in einer TXT-Antwort sind normal. Manche Panels teilen lange DKIM-Keys in Chunks. Beim Troubleshooting kopieren Sie den exakten zusammengefügten Wert aus dem DNS Checker statt aus einem PDF abzutippen.

TXT wird auch für BIMI, MTA-STS und TLS-RPT in fortgeschrittenen Mail-Setups genutzt — weiterhin als Text unter vorhersagbaren Namen. Rotiert Ihr Provider DKIM-Selektoren, können alte und neue Selektoren kurz nebeneinander stehen; fragen Sie TXT nach jeder Rotation ab und notieren Sie TTL, bevor Sie retired Keys entfernen.

SPF, DKIM und DMARC in TXT

SPF listet Hosts, die Mail für Ihre Domain senden dürfen (`v=spf1 include:... ~all`). Pro Owner-Name darf nur ein SPF-TXT existieren — doppelte SPF-Strings invalidieren die Policy vollständig. Includes zusammenführen statt zweiten Eintrag am Apex hinzuzufügen.

DKIM veröffentlicht einen Public Key unter `selector._domainkey.example.com`. Alignment mit der From-Header-Domain zählt für DMARC pass/fail. Nach Relay-Onboarding bestätigen Sie den Selektor-TXT im DNS Checker gegen das Provider-Dashboard, bevor Sie Bulk-Kampagnen senden.

DMARC unter `_dmarc.example.com` setzt Policy (`p=none`, `quarantine`, `reject`) und Report-Adressen (`rua=`, `ruf=`). Starten Sie mit `p=none` für Aggregate Reports, dann verschärfen, wenn SPF und DKIM zuverlässig alignen. Prüfen Sie alle drei Familien nach jeder Mail-Migration erneut mit dem DNS Checker — MX allein beweist nie korrektes SPF.

MX und TXT online prüfen

Schritt 1 — DNS Checker öffnen und Domain (Apex oder Subdomain) eingeben. Schritt 2 — Vollständigen Lookup ausführen oder MX- und TXT-Abschnitte fokussieren. Schritt 3 — Priorität, Ziele und TXT-Strings mit dem Setup-Guide Ihres Mail-Providers vergleichen. Schritt 4 — Bei veralteten Werten TTL notieren und nach Ablauf erneut abfragen.

Für reine MX-Abfragen das DIG-Tool öffnen, Typ MX wählen und den Answer-Bereich prüfen. Dieselbe Domain in WHOIS nutzen, um zu bestätigen, dass Nameserver zum bearbeiteten DNS-Panel passen.

Archivieren Sie Checker-Ausgabe in Tickets: Prioritäten, Exchanger-Hostnamen, vollständige SPF/DKIM/DMARC-Strings und TTL-Werte. Zeigen Authentication-Results nach Fix noch Fehler, warten Sie ein volles TTL-Fenster und führen Sie den DNS Checker erneut aus — rekursive Caches überleben oft den Save-Klick in der Panel. Für Bulk-Mail speichern Sie Testnachrichten-Header neben dem DNS-Snapshot.

Verifizierung und Drittanbieter-TXT-Tokens

Search Console, Microsoft 365, Stripe und Zertifikatsanbieter verlangen jeweils einen eindeutigen TXT-Nachweis am Apex oder unter `_dnsauth`-Labels. Diese Tokens koexistieren mit SPF als separate TXT-Einträge am gleichen Namen — anders als SPF sind mehrere unabhängige TXT-Strings an einem Owner gültig. Löschen Sie Verification-TXT nicht sofort nach Erfolg — manche Dienste prüfen die Domain periodisch erneut.

Bevor Sie «alte» TXT beim Cleanup löschen, bestätigen Sie, dass keine aktive Verifizierung oder DKIM-Keys sind. Der DNS Checker listet jeden TXT-Antwort an einem Namen, damit Sie gegen Provider-Docs vergleichen statt aus dem Gedächtnis zu raten. Für Stripe und CAs brauchen Sie oft separate `_dnsauth`- oder `_acme-challenge`-Labels — prüfen Sie den exakten Namen aus der Vendor-Dokumentation.

Nach Hinzufügen eines Verifizierungs-TXT sofort mit dem DNS Checker abfragen, dann erneut nach TTL, wenn der Anbieter noch Fehler meldet. Manche Registrare publizieren Zonen gebündelt alle paar Minuten — zwei identische Checker-Läufe fünf Minuten auseinander schaffen schneller Vertrauen als nur die Vendor-UI zu aktualisieren. Bei Status «pending» beide Checker-Läufe im Ticket als Publish-Nachweis archivieren.

Häufige Probleme

Fehlendes SPF ist der schnellste Weg in Spam-Ordner. Falsche MX-Priorität leitet Mail an abgeschaltete Hosts. Tippfehler in Verifizierungs-TXT brechen Search Console oder Microsoft-365-Setup. Veraltete Cache-Antworten nach nicht gesenkter TTL vor Cutover wirken wie «DNS kaputt», obwohl Propagation noch läuft.

Doppelte SPF-Einträge am gleichen Namen invalidieren SPF vollständig — in einen TXT zusammenführen. DMARC ohne ausgerichtetes DKIM/SPF meldet Fehler, behebt sie aber nicht; DMARC ist die Policy-Schicht über funktionierenden Auth-Einträgen.

MX auf ein nur-CNAME-Label zeigt auf strict Resolvern fehlende Auflösung. MX auf einen Hostnamen ohne funktionierende A/AAAA erzeugt stillen Mail-Verlust — bestätigen Sie Exchanger-Ziele im DNS Checker nach jeder MX-Ziel-Änderung.

MX und TXT bei Migrationen

Mail-Migrationen scheitern leise, wenn MX aktualisiert wird, bevor SPF/DKIM/DMARC beim neuen Provider bereit sind, oder wenn alte MX mit niedrigeren Prioritätszahlen als beabsichtigt bleiben. Publizieren Sie vor Cutover ein Baseline mit dem DNS Checker, dann diffen Sie MX- und TXT-Abschnitte stündlich im Migrationsfenster. Nehmen Sie neben dem Apex auch Subdomains wie mail oder smtp ins Baseline auf, wenn sie am Routing beteiligt sind.

Senken Sie TTL auf MX und kritischen TXT vierundzwanzig bis achtundvierzig Stunden vor dem Switch, wenn Ihr DNS-Host es erlaubt. Bestätigen Sie die niedrigere TTL öffentlich mit dem DNS Checker — manche Panels zeigen 300 Sekunden, während die Live-Zone noch 3600 liefert, bis der nächste Publish-Zyklus endet. Notieren Sie im Ticket, wer Publish beim Registrar und beim DNS-Host verantwortet, falls das unterschiedliche Teams sind.

Behalten Sie MX des alten Providers mit höherer Priorität (größerer Zahl), bis eingehende Zustellung auf dem neuen Stack validiert ist, dann entfernen Sie retired Exchanger. Ausgehende Mail kann alte SPF-Includes nutzen, bis Sie Apex-TXT aktualisieren — prüfen Sie beide Richtungen mit dem DNS Checker, bevor Sie das Ticket schließen. Notieren Sie das Entfernungsdatum alter MX, damit Sie später wissen, warum ein Backup-Exchanger noch existierte.

Dokumentieren Sie, wem jede TXT-Zeichenkette gehört (Marketing-Verifizierung, IT-Mail, Finance-DMARC-Reports), damit künftige Cleanups keine Produktions-Auth-Einträge versehentlich löschen.

Häufig gestellte Fragen

Wie lange dauert es, bis DNS-Änderungen sichtbar werden?

Die meisten Resolver beachten die TTL (Time To Live). Bei TTL 3600 Sekunden kann es bis zu einer Stunde dauern, bis gecachte Antworten ablaufen. Senken Sie die TTL vor Migrationen, nehmen Sie die Änderung vor und prüfen Sie mit dem DNS Checker, ob die neuen Werte live sind.

Kann ich MX und TXT prüfen, ohne dig zu installieren?

Ja. Öffnen Sie den DNS Checker, geben Sie Ihre Domain ein und filtern oder scrollen Sie zu MX- und TXT-Abschnitten. Für einen einzelnen Eintragstyp können Sie auch das DIG-Tool mit Typ MX oder TXT nutzen.

Warum funktioniert Mail, aber SPF schlägt trotzdem fehl?

SPF autorisiert nur sendende IPs oder Include-Ketten. Ein funktionierender MX-Eintrag bedeutet nicht, dass SPF korrekt ist. Vergleichen Sie Ihre ausgehenden SMTP-IPs mit der SPF-Include-Kette und prüfen Sie per TXT-Lookup, ob der Live-String zur Dokumentation Ihres Mail-Providers passt.

Sollte ich mehrere MX-Einträge verwenden?

Ja, für produktiven Mail-Betrieb. Veröffentlichen Sie mindestens zwei MX-Hosts mit unterschiedlichen Prioritäten (niedrigere Zahl = höhere Präferenz). Fällt der primäre Host aus, versuchen Absender den nächsten Prioritätswert gemäß RFC 5321.

Welche RFC definiert SPF?

SPF ist in RFC 7208 definiert (früher RFC 4408). DKIM ist RFC 6376 und DMARC ist RFC 7489. Alle werden als TXT-Einträge unter vorhersagbaren Namen veröffentlicht.

Kann ich MX und SPF auf demselben Hostname-Label veröffentlichen?

MX und SPF liegen meist auf verschiedenen Namen — MX am Apex oder Mail-Subdomain, SPF als TXT am Apex. Setzen Sie niemals CNAME auf ein Label, das auch MX oder SPF braucht. Nutzen Sie den DNS Checker, um zu bestätigen, dass keine konfliktierenden Typen denselben Owner-Namen teilen. Wenn ein Provider «einen Eintrag für alles» verlangt, meint das fast immer verschiedene Namen, nicht ein Label mit MX und SPF gleichzeitig.

Wie oft sollte ich MX und TXT in Production erneut prüfen?

Nach jeder DNS- oder Mail-Provider-Änderung plus vierteljährliche Audits für Domains mit Bulk-Mail. Automatisches Monitoring über die DN01-API kann warnen, wenn MX-Prioritäten oder SPF-Strings von erwarteten Werten abweichen. Für geschäftskritische Domains lohnt ein wöchentlicher Diff gegen ein Referenz-Ticket nach Registrar- oder CDN-Änderungen.

Speichert DNS Checker meine Lookups?

Erfolgreiche Prüfungen können in der lokalen Verlaufshistorie Ihrer Browsersitzung erscheinen. Nutzen Sie die dokumentierte API mit eigenem Token, wenn Sie wiederholbares Monitoring ohne Web-UI benötigen.