Erfahren Sie, was eine MX‑Prüfung bestätigt, wie man mit Null‑MX, falsch konfigurierten Domains und temporären DNS‑Fehlern umgeht und warum Wiederholversuche und Caching falsche Ablehnungen reduzieren.
Eine MX‑Prüfung sagt aus, ob eine Domain Mailrouten in DNS veröffentlicht, also ob E‑Mails wahrscheinlich an diese Domain zugestellt werden können. Sie bestätigt jedoch nicht, dass ein konkretes Postfach existiert oder dass ein Server Ihre Nachricht auch annimmt.
Nein. Eine Domain kann gültige MX‑Einträge haben und trotzdem E‑Mails ablehnen, weil die Adresse nicht existiert, der Server unbekannte Absender blockiert oder zusätzliche Prüfungen erforderlich sind. Betrachten Sie MX als Signal auf Domain‑Ebene, nicht als Beweis für die Zustellbarkeit eines einzelnen Postfachs.
Ein Null‑MX ist eine explizite Richtlinie des Domain‑Inhabers: „Bitte keine E‑Mails an diese Domain schicken.“ Er erscheint oft als MX‑Eintrag, dessen Ziel ein einzelner Punkt ist (``.`), was bedeutet, dass es absichtlich keinen Zustellort gibt.
„Kein MX“ ist uneindeutig, weil manche Mailserver auf A/AAAA‑Fallbacks zurückgreifen, wenn kein MX vorhanden ist—die Domain kann in manchen Setups also trotzdem E‑Mails empfangen. Null‑MX ist eindeutig: Die Domain sagt ausdrücklich, dass sie keine E‑Mails annimmt, daher ist ein Ablehnen bei der Anmeldung meist gerechtfertigt.
Weil ein MX‑Hostname zwar in DNS vorhanden sein kann, aber dennoch unbrauchbar ist, wenn er nicht auf eine IP‑Adresse auflöst. Die Überprüfung, dass jedes MX‑Ziel A‑/AAAA‑Einträge hat, fängt häufige Fehler ab, bei denen Mailrouting konfiguriert aussieht, aber tatsächlich nicht erreichbar ist.
Timeouts bedeuten meist, dass Ihr Resolver in der vorgegebenen Zeit keine Antwort erhalten hat—wegen Paketverlust, langsamer autoritativer Server, Ratenbegrenzung oder temporärer Netzprobleme. Das ist typischerweise ein wiederholbarer (retryable) Fehler und kein sicherer Hinweis darauf, dass die Domain keine E‑Mails empfangen kann.
SERVFAIL zeigt an, dass der Resolver die Abfrage nicht abschließen konnte, oft wegen temporärer DNS‑Probleme wie Ausfällen upstream oder DNSSEC‑Fehlern. In den meisten Fällen sollten Sie kurz erneut versuchen und falls das Problem bestehen bleibt, das Ergebnis als „unbekannt“ statt als dauerhaft ungültig behandeln.
Als praktische Vorgabe eignen sich 2–3 Versuche innerhalb eines kleinen Zeitbudgets (insgesamt etwa 1–2 Sekunden für den DNS‑Schritt), wobei nur bei wiederholbaren Fehlern wie Timeouts oder SERVFAIL neu versucht wird. Falls die Abfrage weiterhin fehlschlägt, vermeiden Sie wenn möglich ein hartes Ablehnen und verschieben Sie die Verifizierung auf einen späteren Zeitpunkt.
Erfolgreiche Ergebnisse können Sie mit der DNS‑TTL cachen, aber begrenzen Sie die maximale Dauer (z. B. nicht länger als 24 Stunden), damit Sie keine veralteten Urteile vertrauen. Negative oder fehlerhafte Ergebnisse sollten kurz (oft 1–5 Minuten) zwischengespeichert werden, um bei kurzen Ausfällen nicht ständig DNS‑Anfragen zu wiederholen.
Speichern Sie ein Ergebnis zusammen mit einem Grundcode (z. B. Domain existiert nicht, Null‑MX, temporärer DNS‑Fehler, MX‑Ziel ohne IP) und einem Zeitstempel der Prüfung. Wenn Sie nicht selbst alle Randfälle abdecken wollen, kann Verimail eine strukturierte Antwort liefern, die Syntaxprüfungen, Domain‑/MX‑Verifikation und Erkennung von Wegwerf‑E‑Mail‑Providern in einem API‑Aufruf kombiniert.
Eine MX‑Prüfung beantwortet eine praktische Frage: Kann diese Domain irgendwo E‑Mails empfangen? Sie versucht nicht zu bestimmen, ob eine Person real ist, und sie bestätigt nicht, dass ein bestimmtes Postfach existiert. Sie prüft nur, wie die Mail‑Zustellung der Domain in DNS eingerichtet ist.
Wenn die Prüfung erfolgreich ist, bedeutet das in der Regel, dass die Domain Mailserver (oder ein anerkanntes Fallback) veröffentlicht und dass Nachrichten theoretisch an diese Domain geroutet werden können. Das ist beim Signup oder beim Erfassen von Leads nützlich, weil es offensichtlichen Unsinn wie erfundene Domains herausfiltert, bevor Sie sie speichern oder Mails senden.
MX‑Ergebnisse sind jedoch keine Garantie für ein Postfach. Eine Domain kann gültige MX‑Einträge haben und trotzdem Mails ablehnen: Die Adresse könnte nicht existieren, der Server unbekannte Absender blockieren oder zusätzliche Prüfungen verlangen. MX kann auch nicht sagen, ob ein Postfach voll ist, ob eine Domain geparkt ist oder ob ein Benutzer auf das Postfach zugreifen kann.
Ein typischer Validierungsablauf behandelt MX als frühes Tor, nicht als endgültiges Urteil. Beginnen Sie mit der Basis‑Syntaxprüfung, bestätigen Sie dann, dass die Domain eine plausible Mailroute hat (MX und verwandte DNS‑Signale), und wenden Sie erst danach höherwertige Regeln an, wie Erkennung von Wegwerf‑Providern, Spam‑Trap‑Risiken und Allowlists oder Sperrlisten.
Das „Fehler“-Ergebnis ist genauso wichtig wie die Tatsache, dass es fehlgeschlagen ist. Die meisten Systeme sehen eine kleine Menge an Ergebnistypen:
Behandeln Sie MX als starkes Signal auf Domain‑Ebene, aber niemals als Beweis dafür, dass ein konkretes Postfach zustellbar ist.
DNS ist das Telefonbuch des Internets. Wenn Sie eine Domain eingeben, gibt DNS Einträge zurück, die Computern sagen, wohin sie sich verbinden und wie.
Bei einer MX‑Prüfung (und jeder grundlegenden E‑Mail‑Domain‑Verifikation) stoßen Sie immer wieder auf ein paar Record‑Typen:
DNS‑Antworten können sich im Laufe der Zeit ändern, selbst für dieselbe Domain. Caching ist der häufigste Grund: Ihr Gerät, Router, ISP und öffentliche Resolver speichern Antworten, bis die TTL abläuft. Wenn ein Domain‑Inhaber gerade seine Mail‑Konfiguration behoben hat, sehen einige Nutzer die neuen MX‑Einträge schnell, während andere noch Minuten oder Stunden alte Antworten sehen.
Ein Resolver ist der DNS‑Dienst, der die Abfragen in Ihrem Auftrag durchführt. Die Wahl des Resolvers ist wichtig, weil verschiedene Resolver unterschiedliche Cache‑Zustände, Netzwege und Timeout‑Verhalten haben. Ein Resolver kann sofort eine saubere Antwort zurückgeben, während ein anderer wegen Nichterreichbarkeit eines autoritativen Nameservers einen temporären Fehler liefert.
Deshalb kann eine Domain im Büro‑WLAN „gut“ aussehen, aber über ein Mobilnetz „schlecht“. Beispielsweise löst der MX‑Host an einem Ort problemlos auf, während anderswo ein Resolver beim Abruf des A/AAAA‑Eintrags time‑outet, sodass die Domain kaputt erscheint, obwohl es nur ein momentanes DNS‑Problem ist.
Diese Grundlagen helfen, DNS‑Ergebnisse als Signale und nicht als absolute Wahrheit zu behandeln. Sie erklären auch Randfälle wie Null‑MX, Fehlkonfigurationen und temporäre Ausfälle.
Behandeln Sie die Domain zunächst als Benutzereingabe, nicht als „bereits sauber“. Entfernen Sie führende/nachgestellte Leerzeichen, lesbare Punkte am Ende und wandeln Sie in Kleinbuchstaben um. Wenn der Nutzer internationale Zeichen eingibt (z. B. ü oder 例), konvertieren Sie die Domain vor der DNS‑Abfrage in ihre IDN‑Form (häufig Punycode genannt), damit Sie tatsächlich das prüfen, was DNS speichert.
Führen Sie danach die MX‑Abfrage für diese normalisierte Domain aus. Wenn Sie mehrere Einträge erhalten, sortieren Sie sie nach Priorität (niedrigere Zahlen werden zuerst versucht). Diese Reihenfolge ist später wichtig, wenn Sie tiefere Prüfungen durchführen, weil eine „gute“ Domain einen defekten MX und zugleich einen funktionierenden MX haben kann.
Nachdem Sie MX‑Ergebnisse haben, validieren Sie die Ziele, nicht nur die Tatsache, dass „etwas existiert“. Jeder MX‑Eintrag verweist auf einen Hostnamen, und dieser Hostname sollte auf mindestens einen A‑ oder AAAA‑Eintrag auflösen. Falls nicht, können Mailserver ihn nicht erreichen, obwohl der MX‑Eintrag vorhanden ist.
Wenn keine MX‑Einträge vorhanden sind, prüfen Sie, ob die Basisdomain A/AAAA‑Einträge hat. Viele Systeme behandeln das als Fallback, weil einige Mailserver bei fehlendem MX an die A/AAAA‑Einträge der Domain zustellen. Die Grenzen sind wichtig: Es beweist immer noch nicht, dass die Domain E‑Mail annimmt, und schützt nicht vor Domains, die absichtlich keine E‑Mails empfangen.
Ein sicherer Ablauf sieht so aus:
Speichern Sie nicht nur „Bestanden/Fehlgeschlagen“. Behalten Sie einen Status, einen Grundcode (z. B. MX_FOUND, NO_MX_BUT_A, MX_TARGET_NO_IP, DNS_TIMEOUT) und einen checked_at‑Zeitstempel, damit Sie wissen, wann nachgeprüft werden muss.
Ein Null‑MX‑Eintrag ist die deutliche Aussage eines Domain‑Inhabers: „Diese Domain nimmt keine E‑Mails an.“ Es ist keine fehlerhafte Konfiguration und kein temporärer Ausfall. Es ist eine bewusste Richtlinie.
Im DNS erscheint es üblicherweise als MX‑Eintrag mit einem speziellen Ziel, einem einzelnen Punkt (.). Dieser Punkt bedeutet „nirgendwohin“. Eine MX‑Abfrage kann also erfolgreich sein und Ihnen dennoch mitteilen, keine Mails an diese Domain zuzustellen.
Null‑MX unterscheidet sich von zwei ähnlichen Ergebnissen, die auf den ersten Blick gleich aussehen können:
Bei Null‑MX besteht keine Zweideutigkeit. Wenn Ihre Prüfung Null‑MX zurückgibt, ist das sichererweise ein Ablehnen der Domain bei der Anmeldung oder das Fordern einer anderen Adresse. Sie durchzulassen führt zu vorhersehbaren Bounces und schadet der Zustellbarkeit.
Wie Sie das Nutzern erklären, ist wichtig. Vermeiden Sie DNS‑Fachbegriffe und bleiben Sie handlungsorientiert:
Behandeln Sie Null‑MX außerdem getrennt von „konnte jetzt nicht geprüft werden“. Null‑MX sollte eine sichere Ablehnung sein. Temporäre Fehler dagegen sollten einen Wiederholpfad auslösen, nicht eine sofortige Sperre.
Viele E‑Mail‑Domain‑Setups sind nicht eindeutig „ja“ oder „nein“. Sie existieren, aber ihr DNS ist so unordentlich, dass eine MX‑Prüfung verwirrende Ergebnisse liefern kann. Ziel ist es, echte Nutzer nicht abzuweisen und gleichzeitig Domains zu blockieren, die keine E‑Mails empfangen können.
Häufige Fehlkonfigurationen sind MX‑Einträge, die auf einen nicht existenten Mail‑Host verweisen—oft weil der Domain‑Inhaber den Provider wechselte und veraltete Einträge zurückließ. Ein weiterer häufiger Fehler ist ein ungültiges MX‑Ziel: MX muss auf einen Hostnamen zeigen, nicht auf eine IP‑Adresse. Sie können auch auf CNAME‑Ketten stoßen, die ins Nichts führen, sich aufschaukeln oder sich je nach Resolver unterschiedlich verhalten.
Manche Domains haben keinen nutzbaren Zustellpfad: kein MX und kein funktionierendes A/AAAA‑Fallback. Andere liefern inkonsistente Antworten (MX‑Einträge erscheinen in einer Abfrage und verschwinden in der nächsten), meist wegen Propagation‑Problemen oder falsch konfiguriertem DNS‑Hosting.
Klassifizieren Sie basierend auf der Sicherheit der Aussage.
Behandeln Sie das Ergebnis als harte Ablehnung, wenn die Domain eindeutig keine E‑Mails annehmen kann, z. B. ein ungültiges MX‑Ziel (wie eine IP‑Adresse) oder MX‑Hosts, die über mehrere Versuche konsistent NXDOMAIN liefern.
Behandeln Sie es als weiche Ablehnung, wenn das Ergebnis vorübergehend sein könnte (Timeouts, inkonsistente Antworten, SERVFAIL). In diesem Fall fordern Sie den Nutzer zum erneuten Versuch auf oder erlauben die Anmeldung, markieren die Adresse jedoch zur späteren Bestätigung.
Verwenden Sie einen Unbekannt‑Index für Domains, die merkwürdig, aber nicht eindeutig defekt sind, und kombinieren Sie das MX‑Ergebnis mit anderen Signalen, statt eine sofortige Entscheidung zu treffen.
Eine fehlgeschlagene MX‑Abfrage bedeutet nicht immer, dass eine Domain keine E‑Mails empfangen kann. Manchmal hat Ihr Resolver (oder der DNS‑Provider der Domain) gerade einen schlechten Moment. Wenn Sie jeden Fehler als „ungültig“ werten, lehnen Sie echte Nutzer bei kurzen Zwischenfällen ab.
Dies sind übliche DNS‑Fehlerergebnisse und wie sie sich in der Praxis typischerweise einordnen lassen:
TC=1).Ein praktischer Ansatz ist, Fehler in wiederholbar vs endgültig zu klassifizieren. Timeouts, SERVFAIL, REFUSED und Trunkierung sind typischerweise „nochmals versuchen“, idealerweise mit kurzem Backoff und einer Obergrenze (2–3 Versuche). Erst nach wiederholtem Scheitern sollten Sie zu einer weicheren Entscheidung wie „unbekannt“ statt „ungültig“ übergehen.
Für Debugging‑Zwecke protokollieren Sie genug, um Muster zu erkennen, ohne unnötige personenbezogene Daten zu speichern: die abgefragte Domain (nicht die vollständige E‑Mail), den Fehlercode und verwendeten Resolver, Anzahl und Zeitstempel der Versuche, ob ein TCP‑Retry stattfand und ob die Antwort ein Cache‑Treffer war.
DNS ist meistens schnell, aber nicht perfekt zuverlässig. Wenn Sie ein einzelnes Timeout als hartes „Nein“ werten, lehnen Sie echte Nutzer bei kurzen Störungen ab. Eine gute MX‑Prüfung balanciert Geschwindigkeit mit einem kleinen Sicherheitsnetz.
Halten Sie Wiederholversuche begrenzt und vorhersehbar, damit Nutzer nicht bei einem Formular hängenbleiben:
Backoff und Jitter bedeuten einfach, dass bei jedem Versuch etwas länger gewartet wird und perfekte Synchronität vieler Nutzer vermieden wird. Das verhindert Lastspitzen, bei denen viele Anmeldungen gleichzeitig DNS bombardieren.
Caching verhindert, dass Sie dieselbe Frage ständig erneut stellen. Cachen Sie positive Ergebnisse mit der DNS‑TTL, wenn vorhanden, aber begrenzen Sie die Dauer (z. B. maximal 24 Stunden), damit Sie nicht alte Daten ewig vertrauen.
Für negative oder fehlerhafte Ergebnisse cachen Sie kurz (oft 1–5 Minuten). Das verhindert, dass Sie DNS während kurzer Störungen überlasten, und beruhigt Ihre eigenen Systeme.
Zwingen Sie eine Neubewertung, wenn es wichtig ist: der Nutzer ändert seine E‑Mail, Sie sehen nach längerer Inaktivität neue Aktivitäten oder Ihre letzte Prüfung älter ist als Ihre maximale Cache‑Grenze.
Eine MX‑Prüfung ist nützlich, aber es ist leicht, sie wie ein endgültiges Urteil zu behandeln.
Ein Fehler ist zu glauben, dass „MX existiert“ bedeutet, eine E‑Mail‑Adresse sei zustellbar. MX sagt nur, dass eine Domain irgendwo behauptet, Mail anzunehmen. Es sagt nichts darüber, ob ein Postfach existiert, ob der Server unbekannte Nutzer ablehnt oder ob die Domain sicher ist.
Ein anderer Fehler ist, beim ersten Timeout, SERVFAIL oder einer instabilen DNS‑Antwort hart zu scheitern. DNS ist nicht perfekt zuverlässig. Wenn Sie eine Anmeldung ablehnen, weil eine einzige Abfrage fehlgeschlagen ist, lehnen Sie echte Nutzer während kurzer Ausfälle ab.
Null‑MX wird ebenfalls oft falsch verstanden. Ein Null‑MX‑Eintrag ist ein klares Signal, dass die Domain keine E‑Mails empfängt. Ignorieren Sie ihn und Sie akzeptieren die Domain trotzdem—dann haben Sie später garantiert Bounces.
Viele Implementierungen hören zu früh auf, nachdem sie MX‑Hostnamen gelesen haben. Sie lösen die MX‑Ziele nie zu A/AAAA‑Einträgen auf, was eine häufige Fehlerursache übersieht: Die Domain veröffentlicht MX, aber die Ziele lösen nicht auf oder sind nur in einer nicht erreichbaren Adressfamilie vorhanden.
Caching kann auch nach hinten losgehen, wenn es ohne Ablaufstrategie gemacht wird. Ergebnisse „für immer“ zu speichern bedeutet, dass Sie Domains ablehnen, die nur kurz Probleme hatten, oder Domains weiter akzeptieren, die den Maildienst später entfernt haben.
Die Muster, die in Produktion am meisten Probleme machen, sind:
Wenn Sie bei der Anmeldung validieren, denken Sie in Begriffen von Vertrauen, nicht von Sicherheit. Wiederholen Sie temporäre DNS‑Fehler, cachen Sie Ergebnisse kurz und kombinieren Sie MX‑Checks mit anderen Signalen.
Verwenden Sie diesen Ablauf, nachdem Ihre MX‑Prüfung ein Ergebnis geliefert hat:
Ein konkretes Beispiel: Ein Nutzer meldet sich mit [email protected] an während Ihr Resolver einen kurzen DNS‑Ausfall hat. Die erste Abfrage time‑outet und Ihre App lehnt die Anmeldung ab. Wenn Sie ein- oder zweimal innerhalb einer Sekunde erneut versuchen, erhalten Sie oft eine saubere Antwort, ohne das Formular merklich zu verlangsamen. Wenn es weiterhin fehlschlägt, erlauben Sie die Anmeldung, markieren die E‑Mail als „später zu verifizieren“ und prüfen Sie sie im Hintergrund erneut.
Bewahren Sie Ergebnisse nur kurz auf. Das Caching aktueller Erfolge und Fehler reduziert wiederholte Abfragen und hilft zu unterscheiden zwischen „diese Domain kann keine E‑Mails empfangen“ und „DNS war eine Minute lang instabil“.
Ein Nutzer versucht, sich mit einer echten Arbeits‑E‑Mail anzumelden, z. B. [email protected]. Ihre App führt während der Anmeldung eine MX‑Prüfung durch, um zu sehen, ob die Domain Mails empfangen kann. Zur gleichen Zeit hat der DNS‑Provider der Domain ein kurzes Problem.
Bei der ersten Abfrage bekommt Ihr System kein klares Ja oder Nein. Stattdessen time‑outet die DNS‑Abfrage oder gibt SERVFAIL zurück. Das bedeutet nicht, dass die Domain gefälscht ist. Es bedeutet, dass der Resolver in dem Moment keine Antwort bekam.
Wenn Sie das als „ungültige Domain“ behandeln und die Anmeldung blockieren, entsteht ein false‑reject. Der Nutzer probiert es eine Minute später erneut und es funktioniert, was Ihre Validierung willkürlich erscheinen lässt.
Ein sicherer Ablauf trennt „definitiv schlecht“ von „vorübergehend unbekannt“:
Wiederholversuche helfen, weil viele DNS‑Störungen nur kurz sind. Kurzfristiges Caching hilft, weil mehrere Anmeldungen aus derselben Firma oft nahe beieinander stattfinden. Wenn Ihr erster Versuch wegen eines transienten Ausfalls scheitert, kann ein zu langes Caching dieses Fehlschlagen zu einer Sperre echter Nutzer machen.
Wenn der Support fragt „Warum wurde meine E‑Mail abgelehnt?“, geben Sie keine Schuld an den Nutzer. Eine klare Antwort wäre: „Wir konnten Ihre E‑Mail‑Domain wegen eines temporären DNS‑Problems in dem Moment nicht bestätigen. Bitte versuchen Sie es erneut oder verwenden Sie eine andere Adresse."
Eine MX‑Prüfung ist ein starkes Signal, sollte aber nicht das einzige Tor sein. Der nächste Schritt ist, rohe DNS‑Ergebnisse in eine klare Policy zu überführen, die Ihr Produkt konsistent anwendet.
Entscheiden Sie, wie Sie mit jedem Ergebnis verfahren. Null‑MX ist meist ein harter Block, weil die Domain ausdrücklich keine E‑Mails annimmt. Ein temporärer DNS‑Fehler sollte selten eine dauerhafte Ablehnung sein. Fehlkonfigurationen liegen dazwischen: Sie können die Anmeldung erlauben, aber verlangen, dass der Nutzer seine Adresse bestätigt, bevor er wichtige Aktionen durchführen kann.
Ein einfaches Policy‑Framework, das viele Teams nutzen, sieht so aus:
Kombinieren Sie MX‑Ergebnisse mit anderen Checks, damit Sie DNS nicht übervertrauen. Gute Abdeckung umfasst in der Regel RFC‑konforme Syntaxprüfungen, Basis‑Domain‑Verifikation, MX‑Lookup und Wegwerf‑E‑Mail‑Erkennung.
Konsistenz ist genauso wichtig wie Genauigkeit. Verwenden Sie stabile Grund‑Codes und mappen Sie sie auf Produktverhalten. Wenn der Support „dns_temporary_failure“ sieht, aber Analytics „invalid_domain“ loggt, können Sie das Geschehen nicht zuverlässig messen.
Wenn Sie nicht alle Randfälle selbst bauen und pflegen möchten, kann ein mehrstufiger Validator eine strukturierte Antwort zurückgeben, statt DNS‑ und Sperrlisten‑Aufrufe zusammenzureimen. Zum Beispiel kombiniert Verimail (verimail.co) RFC‑konforme Syntaxprüfungen, Domain‑ und MX‑Verifikation sowie Echtzeit‑Abgleich mit bekannten Wegwerf‑Providern in einem einzigen API‑Aufruf.
Fügen Sie schließlich eine Review‑Schleife hinzu. Verfolgen Sie, wie oft Warnungen später erfolgreich bestätigt werden, wie oft blockierte Nutzer den Support kontaktieren und ob Ausreißer mit Resolver‑Vorfällen zusammenfallen. Passen Sie dann Wiederholversuche und Caching so an, dass kurze Ausfälle nicht zu verlorenen Anmeldungen werden.