SMTP-Validierung erklärt: Wie E-Mail-Validatoren wirklich funktionieren

Die meisten E-Mail-Prüfer behaupten, genau zu sein. Nur wenige erklären, wie sie eine Adresse tatsächlich überprüfen.

Hier ist diese Erklärung.

Was ist SMTP?

SMTP = Simple Mail Transfer Protocol
Es ist die Sprache, in der Mailserver E-Mails senden und empfangen.

Wenn Sie eine E-Mail versenden:
1. Ihr Client verbindet sich mit einem SMTP-Server
2. Sendet MAIL FROM: you@yourcompany.com
3. Sendet RCPT TO: recipient@their.com
4. Der Server antwortet 250 OK (yes, we accept it) or 550 Reject (no, we don't)
5. Der Client sendet den Nachrichtentext

SMTP-Validierung: Die echte Prüfung

SMTP-Validierung simuliert die Schritte 1–4 ohne die eigentliche E-Mail zu senden.

Deshalb ist dies die einzige Möglichkeit, sicher zu wissen, ob ein Postfach tatsächlich existiert.

Der SMTP-Handshake

→ Client: EHLO Mail.Validator.com
← Server: 250 OK ESMTP

→ Client: MAIL FROM:<Validator@mail.Validator.com>
← Server: 250 OK

→ Client: RCPT TO:<Test@gmail.com>
← Server: 250 OK
     (Postfach existiert und akzeptiert Mail)

→ Client: QUIT
← Server: 221 Bye

Wenn der RCPT TO returns 250, lautet die Adresse Gültig.
Wenn es 550, lautet die Adresse Ungültige.
Antwortet der Server nicht, ist es Riskant oder Unbekannt.

Warum andere Methoden versagen

❌ Nur Syntaxprüfung

Test@example.com ✅ (korrekt aussieht Guter)
Test.12345@example.com ❌ (könnte keine existieren)

Die Syntax ist korrekt, aber wir wissen nicht, ob das Postfach existiert.

❌ Nur MX-Record-Prüfung

Domain: gmail.com → MX: aspmx.l.google.com (ja, existiert)
Aber: tut Test@gmail.com tatsächlich existierenEinzeln Unbekannt.

✅ SMTP-Validierung

Verbinden auf gmail SMTP → RCPT TO Test@gmail.com
← 550 Nein solche Benutzer
Ergebnis: UNGÜLTIG (Postfach doesn't existieren)

Die Herausforderung: Catch-All-Domains

Einige Server (besonders ältere) sagen "ja" an jede Adresse:

→ RCPT TO: realuser@company.com
← 250 OK

→ RCPT TO: fakeuser123456789@company.com
← 250 OK (auch akzeptiert!)

Diese sind Catch-All-Domains. Die SMTP-Prüfung allein kann nicht feststellen, ob sie echt ist.

Erweitert: Bewertung + Catch-All-Erkennung

Bessere Validatoren kombinieren SMTP mit weiteren Signalen:

• Domain-Reputation — ist bekannt, dass der Mailserver Nachrichten zurückweist?
• Aktuelle Aktivität — war diese Domain in den letzten 90 Tagen aktiv?
• Honeypot-Prüfungen — handelt es sich um eine bekannte Spam-Falle?
• Risky- und Catch-All-Markierung — "Per SMTP gültig, könnte aber Catch-All sein"

Bewertung 0–10 = Vertrauensstufe, nicht nur bestanden oder nicht bestanden.

Geschwindigkeit vs. Genauigkeit

Warum SMTP-Validierung wichtig ist

✅ Schützt die Absender-Reputation — vor dem Versand prüfen
✅ Senkt die Bounce-Rate — SMTP erkennt ungültige Adressen vor dem Versand
✅ Spart Credits — zahlen Sie dem ESP nicht für unzustellbare E-Mails
✅ Verbessert die Zustellbarkeit — ISPs belohnen saubere Versandpraktiken

So prüfen Sie selbst (nur für Entwickler)

import smtplib

Domain = "gmail.com"
try:
    smtp = smtplib.SMTP(f"mx.{Domain}")
    smtp.Mail("test@validator.com")
    code, msg = smtp.rcpt("recipient@gmail.com")
    if code == 250:
        print("Valid")
    else:
        print("Invalid")
    smtp.quit()
except:
    print("Risky/Unknown")

In der Produktion sollten Sie jedoch einen Dienst nutzen. Die SMTP-Validierung im großen Maßstab ist komplex (Firewalls, Ratenbegrenzungen, Verzögerungen).

SMTP im Detail

SMTP ist ein Textprotokoll. Eine Sitzung ist eine kurze Unterhaltung mit einer Folge von Befehlen und numerischen Antworten. Für die Validierung ist nur die erste Hälfte relevant – der Teil, bevor ein Nachrichtentext gesendet wird.

Ports und TLS

• 25 – der klassische Server-zu-Server-Port. Wird von Hosting-Anbietern häufig blockiert, um Spam zu verhindern, weshalb Validierungsdienste eigene Infrastruktur nutzen.
• 465 – implizites TLS (SMTPS).
• 587 – Submission-Port mit STARTTLS, wird von E-Mail-Clients verwendet.

Ein Validator benötigt die Erreichbarkeit von Port 25 am MX des Empfängers. Wenn Ihr eigener Server Port 25 nicht erreichen kann, können Sie SMTP-Prüfungen nicht zuverlässig selbst durchführen – das ist der häufigste Grund, warum Teams die Verifizierung auslagern.

EHLO, MAIL FROM, RCPT TO

→ EHLO Validator.example.com
← 250-Mail.example.com
← 250-PIPELINING
← 250 SIZE 35882577

→ MAIL FROM:<Prüfung@validator.example.com>
← 250 OK

→ RCPT TO:<person@example.com>
← 250 OK

EHLO opens the session and asks which extensions the server supports. MAIL FROM declares the envelope sender. RCPT TO is the actual test: the server accepts or rejects the recipient. QUIT ends the session.

Der entscheidende Punkt: RCPT TO wird beantwortet, bevor Nachrichtendaten gesendet werden. Genau das macht eine Validierung ohne Zustellung der E-Mail möglich.

SMTP-Antwortcodes richtig lesen

Ein Validator, der jede Antwort ungleich 250 als "ungültig" wertet, liegt falsch: 4xx-Codes sind vorübergehend und lösen sich beim erneuten Versuch oft von selbst.

Warum Syntax- und MX-Prüfungen nicht ausreichen

Beide sind günstig und als erster Filter nützlich, doch keine von beiden kann die einzig entscheidende Frage beantworten: Nimmt dieses Postfach E-Mails an?

• Syntax sagt Ihnen, dass die Zeichenfolge wie eine Adresse aussieht. Sie kann nicht erkennen, dass die Firma geschlossen wurde.
• MX sagt Ihnen, dass die Domain einen Mailserver hat. Sie kann nicht erkennen, dass person@ was never created.
• SMTP mit diesem Server kommuniziert und nach genau diesem Empfänger fragt. Nur dieser Schritt liefert eine echte Antwort.

Die praktische Folge: Eine Liste, die Syntax- und MX-Prüfungen besteht, kann dennoch zu 20–30 % unzustellbar sein. Deshalb sind "kostenlose E-Mail-Prüfer", die nur reguläre Ausdrücke verwenden, zwar beliebt, für die Zustellbarkeit aber nutzlos.

Catch-All-Domains im Detail

Ein Catch-All-Server ist so konfiguriert, dass er E-Mails für jeden lokalen Teil einer Adresse annimmt. Das ist eine legitime Konfiguration – Unternehmen nutzen sie, damit ein Tippfehler in der Adresse eines Interessenten nicht stillschweigend verloren geht –, sie erschwert jedoch die SMTP-Validierung.

So gehen Sie mit Catch-All-Domains um:

1. Erkennen Sie sie. Senden Sie eine Testnachricht an einen zufälligen, offensichtlich erfundenen lokalen Teil. Antwortet der Server ebenfalls mit 250, handelt es sich um eine Catch-All-Domain.
2. Markieren, nicht löschen. Hinter Catch-All-Adressen stehen häufig echte Personen. Löscht man sie, kann das 5–15 % einer B2B-Liste kosten.
3. In kleinen Paketen versenden und Öffnungs- sowie Bounce-Raten messen. Schneidet ein Catch-All-Segment gut ab, behalten Sie es.
4. Zusätzliche Signale nutzen – etwa Domain-Reputation, bisherige Interaktion und Muster-Abgleich –, um Catch-All-Adressen zu bewerten.

Greylisting, Ratenbegrenzung und Anti-Harvesting

Echte Mailserver sind keine Testumgebungen. Rechnen Sie mit Folgendem:

• Greylisting — Der Server lehnt Erstabsender vorübergehend mit einem 4xx-Code ab und erwartet einen erneuten Versuch. Validierungsdienste wiederholen Versuche automatisch.
• Ratenbegrenzung — Zu viele Verbindungen von einer IP-Adresse werden gedrosselt. Gute Anbieter verteilen Prüfungen auf mehrere IPs und über die Zeit.
• Anti-Harvesting — Manche Server antworten bewusst mehrdeutig, wenn jemand viele Adressen prüft.
• Honeypots — Adressen, die ausschließlich dazu dienen, Massenversender zu entlarven. Ein guter Validator markiert sie.

Deshalb funktionieren selbst gebaute Validierungsskripte bei zehn Adressen, scheitern aber bei zehntausend.

Echtzeit vs. Batch und das Async-Muster

• Echtzeit eignet sich für Anmeldeformulare und Kassenseiten: eine Adresse, eine sofortige Antwort, mit einem strikten Timeout, sodass der Nutzer nie länger als ein bis zwei Sekunden wartet.
• Batch eignet sich für Listen: Tausende Adressen, Wiederholungsversuche und eine Ergebnisdatei, die Sie segmentieren können.
• Asynchron ist das Produktionsmuster für beides: Adresse in die Warteschlange stellen, sofort antworten, im Hintergrund verifizieren und den Datensatz aktualisieren, sobald das Ergebnis vorliegt.

Blockieren Sie niemals einen Request-Thread durch einen SMTP-Handshake mit einem entfernten Server. Ein langsamer oder feindseliger Server kann die Verbindung 30 Sekunden oder länger blockieren.

Ein besseres Python-Beispiel

import smtplib
import dns.resolver

def Prüfung(Domain: str, Adresse: str, timeout: int = 10) -> str:
    try:
        mx = str(dns.resolver.resolve(Domain, "MX")[0Andere.exchange).rstrip(".")
        mit smtplib.SMTP(mx, 25, timeout=timeout) as smtp:
            smtp.ehlo_or_helo_if_needed()
            smtp.Mail("check@validator.example.com")
            code, _ = smtp.rcpt(Adresse)
            if code in (250, 251):
                return "valid"
            if code in (450, 451, 452, 552):
                return "risky"
            if code in (550, 551, 553):
                return "invalid"
            return "unknown"
    except Ausnahme:
        return "unknown"

Selbst diese vereinfachte Version stößt im großen Maßstab an Grenzen: Sie ignoriert Greylisting, erkennt keine Catch-all-Adressen, nutzt nur eine IP-Adresse und wird von Anbietern blockiert, die Anfragen ratenbegrenzen. Sie ist ein Lernwerkzeug, kein Produktionsvalidator.

Grenzen und Ethik

Kein Validator kann die Zustellbarkeit garantieren. Postfächer werden zwischen Prüfung und Versand geschlossen, Server ändern ihre Richtlinien, und eine "gültige" Adresse kann dennoch aufgegeben werden. Nutzen Sie die Verifizierung, um vorhersehbare Fehlschläge zu vermeiden, nicht um eine Kampagne ohne Bounces zu versprechen.

Ethisch gilt: Validieren Sie nur Adressen, zu denen Sie eine rechtliche Grundlage für die Kontaktaufnahme haben. SMTP-Abfragen sind ein technischer Vorgang, sie ersetzen aber keine Einwilligung. Wer Validierung nutzt, um eine gekaufte Liste zu bereinigen, macht den Versand dadurch nicht rechtmäßig.

Was die Validierung nicht erkennen kann

• Engagement – Eine gültige Adresse wird Ihre E-Mail möglicherweise nie öffnen.
• Absicht – Eine echte Person möchte Ihr Angebot vielleicht nicht.
• Einwilligung – Eine zustellbare Adresse ist keine rechtliche Grundlage.
• Zukünftiger Zustand – Ein Postfach kann einen Tag nach der Prüfung geschlossen werden.

Die Verifizierung beseitigt technische Unsicherheit. Alles Übrige ist nach wie vor Marketing.

Zuerst die eigene Domain testen

Bevor Sie eine Liste validieren, prüfen Sie Ihre Versanddomain:

• Senden Sie eine Testnachricht an ein Postfach, das Sie kontrollieren, bei Gmail, Outlook und einer Unternehmensdomain.
• Prüfen Sie die Ausrichtung von SPF, DKIM und DMARC.
• Beobachten Sie die ersten 200 Sendungen jeder neuen Domain genau. Das Aufwärmen ist wichtiger als jeder einzelne Verifizierungslauf.

Eine saubere Liste, die von einer Domain mit fehlerhafter Authentifizierung aus versendet wird, landet trotzdem im Spam.

Häufig gestellte Fragen

Sendet die SMTP-Validierung eine E-Mail?
Nein. Sie endet bei RCPT TO, before any message body is transmitted.

Warum werden manche gültigen Adressen als riskant eingestuft?
Greylisting, vorübergehende Serverfehler oder Richtlinien gegen Adressernte. Versuchen Sie es nach 24–48 Stunden erneut.

Kann ich von meinem eigenen Server aus validieren?
Nur, wenn er Port 25 erreichen kann und weder ratenbegrenzt noch auf einer Blacklist ist. Die meisten Shared-Hosts blockieren ihn.

Ist die Erkennung von Catch-All-Domains zuverlässig?
Sie zeigt zuverlässig an, dass eine Domain Catch-All ist. Sie kann jedoch nicht feststellen, ob ein bestimmtes Postfach existiert.

Welche Genauigkeit kann ich erwarten?
Ein guter SMTP-basierter Validator liegt in etwa 95–99 % der Fälle richtig; die verbleibende Unsicherheit entsteht vor allem durch Catch-All-Domains und temporäre Fehler.

SPF, DKIM und DMARC – jeweils kurz erklärt

• SPF listet die Server auf, die E-Mails für Ihre Domain versenden dürfen. Es handelt sich um einen DNS-TXT-Eintrag, der nicht mehr funktioniert, wenn das Limit von 10 DNS-Abfragen überschritten wird.
• DKIM fügt jeder Nachricht eine kryptografische Signatur hinzu, damit der Empfänger prüfen kann, dass sie nicht verändert wurde. Rotieren Sie die Schlüssel regelmäßig.
• DMARC legt fest, was Empfänger tun sollen, wenn SPF oder DKIM fehlschlägt (none, quarantine, reject), und sendet Ihnen Berichte. Beginnen Sie mit p=none, read the reports, then tighten.

Die SMTP-Validierung prüft den Empfänger; SPF, DKIM und DMARC bestimmen, ob Ihre eigenen E-Mails beim Versand als vertrauenswürdig gelten. Eine verifizierte Liste, die von einer Domain mit fehlerhafter Authentifizierung versendet wird, scheitert trotzdem. Richten Sie das DMARC-Reporting ein, bevor Sie eine Kampagne skalieren – die Berichte zeigen Ihnen die Absender, die Sie vergessen haben.

Jetzt validieren

Kostenlos starten →

100 SMTP-Validierungen pro Monat, ohne Kreditkarte.