DNS einfach erklärt: Wenn Website oder E-Mail haken

Wenn etwas hakt, prüfe in dieser Reihenfolge:

1. Was ist genau betroffen? Hauptdomain, www, eine Subdomain, Mail-Empfang oder Mail-Versand?
2. Wer gibt die DNS-Antwort? Das zeigen die aktiven Nameserver.
3. Passt der einzelne Eintrag zum Soll-Wert deines Anbieters?
4. Wird der richtige Dienst bereits erreicht? Dann liegt der Fehler wahrscheinlich nicht mehr im DNS.

Ich halte es für einen Fehler, bei einer Störung mehrere Records auf Verdacht zu ändern. Sichere zuerst den aktuellen Stand, ändere nur einen begründeten Wert und prüfe danach erneut.

Was DNS macht – und was nicht

Stell dir die Domain wie den Namen eines Geschäfts vor. DNS liefert die Wegbeschreibung. Website, Postfach und Zertifikat sind jedoch eigene Dienste am Ziel.

Ein Resolver fragt DNS für dich ab. Die maßgebliche Antwort kommt von den autoritativen Nameservern der Domain. Änderst du einen Record in einem Dashboard, das gar nicht zu den aktiven Nameservern gehört, ändert sich öffentlich nichts.

Die wichtigsten Record-Typen:

• A: Name zu IPv4-Adresse.
• AAAA: Name zu IPv6-Adresse.
• CNAME: ein Name wird Alias eines anderen Namens, etwa www.example.com für ein Hosting-Ziel.
• MX: Server, die E-Mails für die Domain annehmen.
• TXT: Textangaben, unter anderem für SPF, DKIM oder DMARC.

Eine gefundene IP beweist nur, dass eine Adresse vorhanden ist. Sie beweist nicht, dass Webserver, HTTPS oder Anwendung fehlerfrei laufen.

DNS-Störung prüfen: der sichere Ablauf

1. Fehler auf einen Namen und Dienst begrenzen

Schreibe den genauen Namen auf: example.com, www.example.com oder shop.example.com. Prüfe, ob der Fehler nur bei dir, im ganzen Team oder auch über Mobilfunk auftritt. Ist nur ein Gerät betroffen, sind lokaler Cache, Browser oder Netzwerk wahrscheinlicher als ein weltweit falscher Record.

2. Aktive DNS-Verwaltung finden

Registrar, DNS-Anbieter, Hosting und E-Mail-Anbieter können vier verschiedene Firmen sein. Maßgeblich sind die öffentlich eingetragenen Nameserver.

Ohne Terminal kannst du Google Admin Toolbox Dig öffnen und zuerst NS abfragen. Vergleiche das Ergebnis mit dem Anbieter, bei dem du Änderungen erwartest. Für eine öffentliche DNS-Abfrage genügt die Domain; Passwörter oder Schlüssel gehören dort nie hinein.

3. Ist- und Soll-Wert vergleichen

Prüfe nur den Record des betroffenen Dienstes:

• Website: A, AAAA oder CNAME für genau diesen Namen.
• Mail-Empfang: MX für die Mail-Domain.
• Mail-Versand oder Spamproblem: SPF, DKIM und DMARC nach Vorgabe des Mail-Anbieters.
• DNS-Anbieterwechsel: NS und, falls aktiviert, DNSSEC/DS.

Der Soll-Wert muss aus der aktuellen Anleitung deines Anbieters kommen. Werte aus einem fremden Tutorial sind keine sichere Vorlage.

4. TTL und Cache richtig einordnen

TTL bestimmt, wie lange eine DNS-Antwort zwischengespeichert werden darf. Nach einer Änderung können Resolver noch die alte Antwort liefern, bis ihr Cache abläuft. Entscheidend ist die TTL vor der Änderung. Eine nachträglich verkürzte TTL holt eine bereits gespeicherte Antwort nicht sofort zurück.

Darum ist „DNS dauert immer 24 Stunden“ keine ehrliche Regel. Die Dauer hängt vom alten Record, seiner TTL, den Resolvern und bei Nameserver-Wechseln zusätzlich von der Delegation ab. Prüfe alten und neuen Wert; warte nicht blind.

5. Grenze zwischen DNS und Dienst finden

Kommt das erwartete Ziel zurück, ist die Wegbeschreibung vorhanden. Prüfe dann den Dienst:

• 404 oder 500 kommt von einem erreichten Websystem.
• Eine Zertifikatswarnung betrifft HTTPS oder die Domain-Zuordnung am Webserver.
• Ein Mail-Bounce kann auf Konto, Richtlinie, Authentifizierung, Speicher oder Empfänger hinweisen.
• Eine langsame Website wird selten allein durch einen anderen DNS-Record schnell.

Wenn DNS stimmt, führt der Leitfaden zur HTTPS-Prüfung bei Zertifikatswarnungen sinnvoller weiter.

Website und E-Mail getrennt behandeln

Wenn die Website nicht erreichbar ist

Prüfe Hauptdomain und www einzeln. Sie können unterschiedliche Records besitzen. Zeigt DNS auf das erwartete Ziel, prüfe Hoster-Status und Einstellungen: Kennt der Webserver die Domain? Läuft die Anwendung? Ist das Zertifikat gültig?

Wenn Domain, Hosting und technische Verantwortung noch unklar sind, zeigt der Vergleich der Hosting-Modelle, welche Aufgaben beim Anbieter und welche bei dir liegen.

Wenn E-Mails nicht ankommen

Für eingehende E-Mails ist der MX-Record der erste DNS-Prüfpunkt. Stimmen die veröffentlichten MX-Werte mit der Anbieteranleitung überein, suche als Nächstes bei Domainstatus, Benutzerkonto, Weiterleitung, Quarantäne, Speicher oder Anbieter-Störung.

Wenn versendete E-Mails im Spam landen oder abgewiesen werden

SPF, DKIM und DMARC haben verschiedene Aufgaben:

• SPF veröffentlicht, welche Systeme eine Domain für den Versand nutzen dürfen.
• DKIM versieht eine Nachricht mit einer prüfbaren Signatur.
• DMARC verbindet SPF und DKIM mit der sichtbaren Absenderdomain und veröffentlicht Regeln für fehlgeschlagene Prüfungen.

Diese Records garantieren keinen Platz im Posteingang. Der aktuelle DMARC-Standard stellt klar: Eine bestandene Prüfung beweist nicht, dass eine Nachricht sicher oder erwünscht ist. Reputation, Inhalt und Empfängerregeln zählen ebenfalls. Ich würde eine strenge DMARC-Regel deshalb nicht blind kopieren: Erst legitime Versanddienste erfassen, SPF und DKIM prüfen und Berichte auswerten.

Sonderfall DNSSEC beim Nameserver-Wechsel

DNSSEC ergänzt DNS um prüfbare Signaturen. Das schützt vor gefälschten Antworten, macht Anbieterwechsel aber empfindlicher. Bleibt beim Registrar ein alter DS-Eintrag aktiv, während neue Nameserver andere Schlüssel verwenden, können prüfende Resolver SERVFAIL liefern.

Ändere DNSSEC oder DS nur nach dem Migrationsplan der beteiligten Anbieter. Bei SERVFAIL direkt nach einem Nameserver-Wechsel ist DNSSEC ein wichtiger Prüfpunkt, aber nicht die einzig mögliche Ursache.

Vor jeder Änderung: der Rückweg

Sichere die Records als Export oder Screenshot. Notiere Anbieter, Zeitpunkt, alten Wert, neuen Wert und TTL. Ändere nur den betroffenen Eintrag. So kannst du eine falsche Änderung gezielt zurücknehmen.

Lass bei kritischen Wechseln den alten Web- oder Maildienst während des Übergangs erreichbar. Für geschäftswichtige E-Mail ist ein zweiter Kontaktweg sinnvoll.

Gute Angaben für den Support

Für den Support hat sich diese sachliche Form bewährt:

• betroffene Domain oder Subdomain;
• Website, Mail-Empfang oder Mail-Versand;
• Fehlerbeginn mit Zeitzone;
• aktive Nameserver und DNS-Anbieter;
• erwarteter und öffentlich sichtbarer Record;
• letzte Änderung, Zeitpunkt und vorherige TTL;
• genaue Fehlermeldung oder Bounce ohne Passwörter und Schlüssel;
• Ergebnis aus einem zweiten Netz oder öffentlichen Resolver.

So bekommt der Support Beobachtungen statt der Vermutung „DNS ist kaputt“.

Häufige Fragen

Soll ich den DNS-Cache leeren?

Sieht nur ein Gerät den alten Stand, können lokales Cache-Leeren oder Neustarten von Browser und Netzwerk helfen. Das ändert weder den autoritativen Record noch alle Resolver. Google Public DNS bietet ein Werkzeug für seinen eigenen Cache; andere Resolver bleiben davon unberührt.

Hilft ein anderer öffentlicher DNS-Resolver?

Er kann zeigen, ob Resolver unterschiedliche Antworten liefern. Das ist Diagnose, kein Ersatz für korrekte autoritative Records. Ändere Firmen- oder Router-Einstellungen nicht ohne Zustimmung.

Muss ich www und Hauptdomain getrennt anlegen?

Oft ja: example.com und www.example.com sind verschiedene Namen. Die genaue Einrichtung gibt dein Hosting-Anbieter vor. Sonderfunktionen für Aliase an der Hauptdomain sind nicht automatisch normale CNAMEs.

Wann selbst ändern, wann Support fragen?

Ändere selbst, wenn Zuständigkeit, Soll-Wert, betroffener Record und Rückweg klar sind. Frage den Support, wenn Nameserver und Dashboard nicht zusammenpassen, DNSSEC beteiligt ist, mehrere Maildienste existieren oder der alte Stand unbekannt ist. Bei einer laufenden Geschäftsstörung ist frühes Eskalieren meist billiger als weitere Änderungen auf Verdacht.

Fazit

Die schnellste DNS-Diagnose beginnt mit einer Frage: Welcher Name und welcher Dienst sind betroffen? Prüfe danach aktive Nameserver, den einen passenden Record, TTL und schließlich den Dienst am Ziel. So trennst du DNS-, Hosting-, HTTPS- und Mailprobleme, ohne eine funktionierende Konfiguration zu beschädigen.