E-Mail Validator: Syntax, Domain und MX-Record prüfen

Die Stolperfalle: Ein Tippfehler, den jede Regex durchwinkt

info@gnail.com besteht praktisch jede Syntaxprüfung mit Bravour. Genau ein @-Zeichen, gültiger Local-Part, eine Domain mit Punkt und TLD, alles nach RFC 5322 in Ordnung. Das Problem: "gnail.com" ist einfach die falsche Domain, ein simpler Vertipper von "gmail.com". Eine reine Regex-Prüfung sieht davon nichts, sie kennt keine echten Domains, nur Muster. Die Mail geht raus, bounct später zurück, und im schlimmsten Fall hat die Absender-Reputation schon gelitten, bevor jemand den Fehler bemerkt.

Genau deshalb prüft dieses Tool mehr als nur die Zeichenkette.

Was dieser Validator tatsächlich prüft

• Syntax: Entspricht die Adresse RFC 5322? Genau ein @, keine unerlaubten Zeichen im Local-Part.
• Domain-Existenz: Ist die Domain registriert und per DNS auflösbar (A- oder AAAA-Record vorhanden)?
• MX-Record: Hat die Domain überhaupt einen zuständigen Mailserver eingetragen? Ohne MX-Record kann dort niemand Post empfangen, selbst wenn die Domain existiert.
• Rollen-Adressen: Hinweis bei typischen Funktionspostfächern wie info@, support@ oder abuse@, die sich schlecht für Marketing-Opt-Ins eignen.
• Wegwerf-Dienste: Abgleich mit einer Liste bekannter Wegwerf-Domains wie Mailinator oder 10MinuteMail.

Wieso wir keine Test-Mail verschicken

Der naheliegende nächste Schritt wäre, per SMTP eine Verbindung zum Ziel-Mailserver aufzubauen und bis zum RCPT TO-Kommando zu gehen, um die Antwort des Servers auszuwerten. In der Praxis ist das wenig verlässlich: Viele große Mailserver antworten grundsätzlich mit "accept all" und verwerfen ungültige Adressen erst intern, unsichtbar für den Prüfenden. Manche Anbieter markieren wiederholte SMTP-Anfragen ohne echten Versand außerdem als verdächtiges Verhalten. Wir bleiben deshalb bewusst auf der Protokoll-Ebene: Syntax und DNS. Das liefert eine solide Einschätzung, ohne beim Zielserver Alarm auszulösen.

RFC-Syntax kurz erklärt

• Der Local-Part vor dem @ darf Buchstaben, Ziffern und bestimmte Sonderzeichen enthalten, unter anderem ., -, _ und +.
• Die Domain muss einer gültigen Host-Syntax folgen: mindestens ein Punkt, eine anerkannte TLD am Ende.
• Gesamtlänge maximal 254 Zeichen, davon Local-Part bis 64 und Domain bis 253 Zeichen.
• Leerzeichen und Zeichen außerhalb von ASCII benötigen Sonderformate wie Quoted Strings oder IDN-Kodierung.

Was der Validator nicht leisten kann

Auch mit MX-Prüfung bleibt eine Restunsicherheit: Ob ein konkretes Postfach tatsächlich existiert, lässt sich ohne echten Zustellversuch nicht zu 100 Prozent klären. Und ob Ihre eigenen ausgehenden Mails beim Empfänger ankommen, hängt von ganz anderen Einstellungen ab, die dieses Tool gar nicht prüft:

• SPF-TXT-Record auf der Absender-Domain, legt fest, welche Server in ihrem Namen versenden dürfen.
• DKIM-Signatur, eine kryptografische Signatur der versendeten Nachricht.
• DMARC-TXT-Record, die Policy, nach der Empfänger mit fehlgeschlagenen Prüfungen umgehen (none, quarantine oder reject).

Diese Einträge lassen sich bei Bedarf mit unserem DNS-Lookup direkt einsehen.

Typische Einsatzszenarien

• Formulare: Sofortige Rückmeldung, wenn sich jemand beim Eintippen vertippt.
• CRM-Pflege: Bestehende Kontaktlisten auf offensichtlich kaputte Adressen durchgehen.
• Registrierungen: Offensichtlich erfundene Adressen frühzeitig abfangen.
• Support-Systeme: Verhindern, dass Antwortmails ins Leere laufen.

Datenschutz

Die eingegebene Adresse wird serverseitig gegen das DNS geprüft und danach verworfen. Wir legen keine Adresslisten an und geben nichts an Dritte weiter. Gedacht ist das Tool für die stichprobenartige Einzelprüfung, Massenabfragen sind ratenbegrenzt.