Syntaxprüfung vs. MX-Prüfung vs. SMTP-Verifizierung: Was jede Stufe erkennt

Eine Syntaxprüfung bestätigt, dass eine Adresse korrekt aufgebaut ist. Eine MX-Prüfung bestätigt, dass die Domain Mailserver veröffentlicht. Eine SMTP-Prüfung fragt diesen Server, ob das konkrete Postfach existiert. Jede Stufe erkennt Fehler, die die vorherige nicht sehen kann, und nur die letzte sagt etwas über die Person aus. Die echten Abfragen unten zeigen genau, wo jede Stufe endet.

Die meisten Erklärungen hören bei „Syntax ist schwach, MX ist besser, SMTP ist am besten“ auf. Das stimmt, verdeckt aber den interessanten Teil: Jede Stufe hat Grenzfälle, in denen die naheliegende Lesart falsch ist. Wir haben die DNS-Abfragen in diesem Beitrag am 1. Oktober 2026 mit dig über eine gewöhnliche Internetverbindung ausgeführt. Die Rohdaten stehen in unseren Recherchenotizen.

Die drei Stufen im Überblick

Jede Stufe beantwortet eine andere Frage, und keine kann die Frage der nächsten beantworten.

Stufe	Frage, die sie beantwortet	Aufwand	Erkennt	Erkennt nicht
Syntax	Sieht das wie eine E-Mail-Adresse aus?	Mikrosekunden, kein Netzwerk	Fehlendes @, Leerzeichen, doppelte Punkte, zu lange Teile	Tippfehler-Domains, tote Domains, tote Postfächer
MX / DNS	Kann diese Domain E-Mails empfangen?	Eine DNS-Abfrage	Nicht existierende Domains, Null-MX, die meisten Tippfehler-Domains	Tote Postfächer auf funktionierenden Domains
SMTP RCPT TO	Nimmt dieser Server E-Mails für dieses Postfach an?	Eine TCP-Verbindung über Port 25, ein paar Sekunden	Gelöschte und nie existierende Postfächer	Catch-all-Domains, Server, die annehmen und später bouncen

Stufe 1: Syntax

Die Syntaxprüfung lehnt Eingaben ab, die keine Adresse sein können, und sonst nichts. Sie ist die einzige Stufe, die ohne Netzwerk auskommt. Das macht sie ideal für sofortiges Feedback im Formular und nutzlos als Urteil.

Was sie berechtigterweise erkennt:

Eingabe	Warum sie durchfällt
jane.doe.example.com	Kein @
jane doe@example.com	Leerzeichen ohne Anführungszeichen
jane..doe@example.com	Aufeinanderfolgende Punkte in einem Local Part ohne Anführungszeichen
jane@	Keine Domain
Ein Local Part mit 70 Zeichen	RFC 5321 Abschnitt 4.5.3.1.1 begrenzt den Local Part auf 64 Oktette

Was sie zu Recht durchlässt, weil all das gültige Syntax ist:

• asdkjhaslkdjh@gmail.com: korrekt aufgebaut, aber sicher keine Person.
• jane@gmial.com: korrekt aufgebaut, falsche Domain.
• jane+newsletter@gmail.com: korrekt aufgebaut und echt. Plus-Adressierung ist legitim, und ein strenger Regex, der sie ablehnt, weist echte Nutzer ab.

Der häufige Fehler geht in die andere Richtung: ein Regex, der so streng ist, dass er gültige Adressen ablehnt. Warum, erklären wir in Warum Regex für die E-Mail-Validierung scheitert. In einer Verifizierungs-Pipeline muss die Syntaxprüfung nur streng genug sein, um Datenmüll aufzuhalten, bevor Sie eine DNS-Abfrage dafür ausgeben.

Stufe 2: MX und DNS

Die MX-Stufe fragt im DNS nach, welche Server E-Mails für die Domain annehmen, und die Antwort kann mehr als zwei Formen haben. Die meisten Anleitungen behandeln sie als Ja oder Nein. Das haben wir für acht Domains tatsächlich zurückbekommen:

Domain	DNS-Status	MX-Antwort	Bedeutung
gmail.com	NOERROR	Fünf MX-Hosts von Google	Kann E-Mails empfangen
outlook.com	NOERROR	outlook-com.olc.protection.outlook.com	Kann E-Mails empfangen
nonexistent-domain-zz918273.com	NXDOMAIN	keine	Domain existiert nicht. Mit Sicherheit ungültig
example.com	NOERROR	0 .	Null-MX: nimmt ausdrücklich keine E-Mails an
yahoo.co	NOERROR	0 .	Null-MX. Ein Tippfehler von yahoo.com, der E-Mails ablehnt
gmial.com	NOERROR	keine, aber ein A-Record existiert	Kein MX. Siehe die Regel zum impliziten MX unten
gmai.com	NOERROR	1 mail.h-email.net.	Eine Tippfehler-Domain mit funktionierendem MX
hotmial.com	SERVFAIL bei der ersten Abfrage, dann 5 mail.h-email.net.	Ein vorübergehender DNS-Fehler, dann ein funktionierender MX	Erneut versuchen, nie aufgrund von SERVFAIL entscheiden

In dieser Tabelle stecken vier Lektionen.

Null-MX ist ein endgültiges „Nein“

example.com und yahoo.co veröffentlichen einen einzelnen MX-Eintrag, der mit der Präferenz 0 auf . zeigt. Das ist ein Null-MX, definiert in RFC 7505: „Um anzuzeigen, dass eine Domain keine E-Mails annimmt, veröffentlicht sie einen einzelnen MX-RR ... mit ... der Präferenzzahl 0 und einem Label der Länge null“ („To indicate that a domain does not accept email, it advertises a single MX RR ... with ... preference number 0 and a zero-length label“). Eine naive Prüfung, die nur fragt, ob es einen MX-Eintrag gibt, sieht einen Eintrag und lässt die Domain durch. Eine korrekte erkennt den Punkt und lässt jede Adresse dieser Domain durchfallen. Mit dem MX-Lookup-Tool können Sie jede Domain prüfen.

Kein MX ist nicht ganz dasselbe wie keine E-Mail

gmial.com hat keine MX-Einträge, aber einen A-Record. Nach RFC 5321 Abschnitt 5.1 gilt: „Wird eine leere Liste von MX-Einträgen zurückgegeben, wird die Adresse so behandelt, als wäre ihr ein impliziter MX-RR ... zugeordnet, der auf diesen Host zeigt“ („If an empty list of MXs is returned, the address is treated as if it was associated with an implicit MX RR ... pointing to that host.“). Ein sendender Server soll also den A-Record versuchen.

In der Praxis betreibt eine Domain ohne MX und nur mit einer geparkten Webseite fast nie einen Mailserver, sodass der Zustellversuch scheitert. Das streng korrekte Verhalten ist aber, „kein MX, hat A-Record“ als „den Host auf Port 25 versuchen“ zu behandeln und erst dann durchfallen zu lassen, wenn nichts antwortet. Solche Domains sofort als ungültig zu werten, ist meist richtig und gelegentlich falsch.

Tippfehler-Domains können die MX-Prüfung bestehen

gmai.com und hotmial.com veröffentlichen beide einen MX, der auf denselben Drittanbieter-Host zeigt, mail.h-email.net. E-Mails, die dorthin gehen, erreichen nicht die Person, die sich bei ihrer Gmail-Adresse vertippt hat. Die MX-Stufe kann Ihnen das nicht sagen. Sie meldet zutreffend, dass die Domain E-Mails empfängt. Deshalb ist die Tippfehlererkennung eine eigene Prüfung neben dem DNS: Sie vergleicht die Domain mit einer Liste bekannter Falschschreibungen großer Anbieter. Siehe E-Mail-Tippfehler bei der Anmeldung abfangen.

SERVFAIL ist nicht NXDOMAIN

Unsere erste Abfrage für hotmial.com lieferte SERVFAIL. Eine zweite lieferte einen MX-Eintrag. RFC 5321 legt ausdrücklich fest, dass eine nicht existierende Domain „als Fehler gemeldet werden MUSS“ („MUST be reported as an error“), während gilt: „Wird ein vorübergehender Fehler zurückgegeben, MUSS die Nachricht in die Warteschlange gestellt und später erneut versucht werden“ („If a temporary error is returned, the message MUST be queued and retried later.“). Ein Verifizierungstool, das SERVFAIL als ungültig markiert, löscht echte Adressen, sobald ein DNS-Server eine schlechte Minute hat.

Stufe 3: die SMTP-Postfachprüfung

Die SMTP-Prüfung ist die einzige Stufe, die nach dem Postfach statt nach der Domain fragt. Das Verifizierungstool verbindet sich über Port 25 mit dem MX-Host mit der höchsten Priorität, stellt sich vor, nennt einen Absender und dann mit RCPT TO den Empfänger. Der Antwortcode des Servers ist die Antwort, und die Verbindung wird geschlossen, bevor eine Nachricht gesendet wird. Die vollständige Unterhaltung zeigen wir Schritt für Schritt in E-Mail-Adresse prüfen, ohne zu senden.

Was sie erkennt, das die früheren Stufen nicht sehen können:

Adresse	Syntax	MX	SMTP
former.employee@company.com (Postfach gelöscht)	Bestanden	Bestanden	Abgelehnt, 550 5.1.1
random-string-xyz@gmail.com	Bestanden	Bestanden	Abgelehnt, 550 5.1.1
real.person@gmail.com	Bestanden	Bestanden	Angenommen, 250

Das ist die Stufe, auf die es bei Hard Bounces in einer Liste echter Menschen ankommt. Wenn Menschen den Job wechseln oder Konten aufgeben, funktioniert die Domain weiter, und nur das Postfach stirbt. Deshalb sieht das nur diese Stufe.

Wo SMTP an seine Grenzen stößt

Auch die SMTP-Stufe hat Grenzen, und sie sind der Grund, warum es ein viertes Ergebnis gibt: riskant.

• Catch-all-Domains antworten auf jede Adresse mit 250, auch auf solche, die nicht existieren können. Ein gutes Verifizierungstool testet zuerst eine zufällige Adresse, um das zu erkennen. Siehe Was ist eine Catch-all-Domain.
• Anbieter, die annehmen und später bouncen, antworten bei RCPT TO mit 250 und schicken später einen Bounce. Yahoo ist das bekannteste Beispiel; mehr dazu in Warum sich Yahoo-Adressen schwer verifizieren lassen.
• Greylisting und Timeouts liefern einen vorübergehenden 4xx-Code oder gar nichts. Versuchen Sie es später erneut.
• Blockierter Port 25 auf Seiten des Verifizierungstools. Die Prüfung findet gar nicht statt. Wir haben das bei Cloud-Hosts gemessen, im Beitrag darüber, dass Cloud-Anbieter Port 25 blockieren.

In jedem dieser Fälle ist die ehrliche Ausgabe „riskant“ oder „unbekannt“. „Gültig“ zu melden, ist geraten.

Welche Stufen Sie je nach Situation brauchen

Nutzen Sie so viele Stufen, wie Ihr Latenzbudget erlaubt, und hören Sie bei allem, was Sie anschreiben wollen, nie bei der Syntax auf.

Situation	Auszuführende Stufen	Warum
Formularfeld live, während der Nutzer tippt	Nur Syntax	Sofortiges Feedback, keine Netzwerkaufrufe
Absenden des Formulars	Syntax + MX + Tippfehlerprüfung, SMTP, wenn es innerhalb Ihres Timeouts antwortet	Siehe Echtzeit-Verifizierung in Anmeldeformularen
Cold-E-Mail-Liste vor einer Kampagne	Alle drei, plus Catch-all-Erkennung	Ein totes Postfach kostet Reputation, nicht nur einen verschwendeten Versand
Alte Newsletter-Liste, die erneut angeschrieben wird	Alle drei	Der Verfall passiert auf Postfach-Ebene, die Syntax und MX nicht sehen können
Bereinigung erfasster Daten im CRM, kein Versand geplant	Syntax + MX	Günstig, findet die toten Domains

Wie SimpleVerifier sie ausführt

Wir führen die drei Stufen nacheinander aus und hören auf, sobald eine eine eindeutige Antwort liefert: Fehlerhafte Syntax oder eine Domain ohne Mailserver ergibt „ungültig“, ohne dass eine SMTP-Verbindung geöffnet wird. Funktionierende Domains gehen in die RCPT TO-Prüfung. Alles, was der Mailserver nicht bestätigen würde, einschließlich Catch-all-Domains, kommt als „riskant“ zurück, nie als „gültig“.

Das Fazit für die Praxis

Syntax ist ein Filter, MX ist ein Domain-Test, SMTP ist der Postfach-Test. Hört ein Tool oder ein selbst geschriebenes Skript bei MX auf, sagt es Ihnen, dass die Domain funktioniert, und nichts über die Person. Bevor Sie einem davon vertrauen, lesen Sie die DNS-Antwort richtig: NXDOMAIN und Null-MX sind harte Fehler, SERVFAIL bedeutet erneut versuchen, und eine Tippfehler-Domain mit funktionierendem MX ist ein Problem, das keine DNS-Abfrage meldet.

Um alle drei Stufen an einer Adresse zu sehen, probieren Sie das kostenlose E-Mail-Verifizierungstool aus.