Bei einer E-Mail-Verifizierung wird vor der Nutzung einer Adresse geprüft, ob sie technisch erreichbar sein könnte. Die Prüfung beginnt beim Aufbau, geht über Domain und Mailweg und kann den empfangenden Server nach dem Empfänger fragen. Jeder Schritt liefert einen Beleg. Keiner garantiert, dass eine spätere Nachricht ankommt. Manche Server lassen keine eindeutige Antwort zu.
Das ist wichtig, bevor Sie eine Registrierung akzeptieren, einen Kontakt übernehmen oder eine vorhandene Liste anschreiben. Eine glaubwürdig aussehende Adresse allein reicht dafür nicht.
Format, Verifizierung und Bestätigung: drei verschiedene Fragen
Unter „Validierung“ verstehen Anbieter teils die gesamte Prüfung. Wer nur das Format prüft, beantwortet jedoch eine engere Frage:
| Frage | Verfahren | Aussage |
|---|---|---|
| Ist die Adresse korrekt aufgebaut? | Syntaxprüfung | Lokaler Teil und Domain entsprechen den Strukturregeln. Ob Domain und Postfach existieren, bleibt offen. |
| Kann die Adresse Mail empfangen? | E-Mail-Verifizierung vor dem Versand | DNS, Mailweg und gegebenenfalls die Antwort des Mailservers liefern technische Belege. |
| Kontrolliert jemand dieses Postfach? | Bestätigung per E-Mail | Jemand hat zu diesem Zeitpunkt einen Link oder Code aus einer zugestellten Nachricht verwendet. |
Ob eine Adressprüfung den Bestätigungslink ersetzen kann, erklärt der Vergleich von E-Mail-Verifizierung und Bestätigung.
Die Gegenüberstellung von SMTP- und Syntaxprüfung hilft, wenn Sie zwischen Formatprüfung und Empfängerbelegen entscheiden müssen.
Die fünf Schritte der E-Mail-Verifizierung
Emvero prüft nur so weit, wie es für eine Aussage nötig und möglich ist. Ein eindeutiger Fehler kann die Prüfung früh beenden. Auch eine vollständige Prüfung kann am Ende unknown melden.
1. Syntax: Ist die Adresse gültig aufgebaut?
Zuerst werden der lokale Teil vor @, die Domain dahinter und die vollständige Adresse geprüft. Ein Formfehler lässt sich ohne Netzwerkzugriff feststellen. Besteht die Adresse diesen Schritt, ist damit noch keine Domain und kein Postfach nachgewiesen. Einzelheiten stehen im Beitrag zur E-Mail-Syntax.
Ein Formularbeispiel zur E-Mail-Prüfung mit JavaScript zeigt, wie Sie diesen ersten Schritt im Browser umsetzen.
2. Domain: Gibt es einen DNS-Eintrag?
Nun wird die Domain über DNS geprüft. Eine eindeutige Antwort, dass sie nicht existiert, ist ein negativer Beleg. Eine existierende Domain kann aber nur eine Website betreiben und keine Mail annehmen. Das positive DNS-Ergebnis erlaubt also lediglich den nächsten Schritt.
3. Mailweg: Wohin würde eine Nachricht gehen?
MX-Records nennen üblicherweise die Mailserver einer Domain. Ein Null-MX sagt ausdrücklich, dass sie keine Mail annimmt. Fehlt ein MX-Record, ist das allein noch kein Fehler: SMTP kennt einen impliziten Weg über den Domain-Host. Der MX-Record-Artikel erklärt die Unterschiede. Selbst ein funktionierender Mailweg belegt nur die Erreichbarkeit der Domain, nicht die Existenz eines bestimmten Postfachs. Die Regeln stehen in RFC 5321, Abschnitt 5.1 und für Null-MX in RFC 7505.
Eine Domain-Prüfung endet hier und öffnet keine SMTP-Verbindung. Belege über den Empfänger erfordern eine vollständige Prüfung.
4. Empfänger: Was antwortet der Mailserver?
Wenn das Ziel es zulässt, nennt eine vollständige Prüfung dem empfangenden Server die Adresse. Er kann den Empfänger annehmen, ausdrücklich ablehnen, die Entscheidung vertagen oder seine Empfängerregeln verbergen. Selbst eine als „Postfach nicht gefunden“ eingeordnete Antwort bleibt nach der aktuellen Emvero-Regel unknown und führt nicht automatisch zur Ablehnung. Eine nachweislich fehlende Domain oder ein Null-MX kann dagegen schon vor SMTP undeliverable begründen. Eine Annahme ist ein positiver Beleg, kann aber auch von einer Catch-all-Regel stammen.
Die SMTP-Probe bleibt beim Umschlag der Nachricht stehen:
EHLO verifier.example
MAIL FROM:<probe@verifier.example>
RCPT TO:<person@example.com>
RSET
QUIT
Erst DATA würde den Nachrichteninhalt einleiten. Emvero erreicht diesen Schritt bei der Verifizierung nicht; es wird keine Bestätigungs-E-Mail gesendet. RFC 5321, Abschnitt 3.3 beschreibt den Ablauf und erklärt, warum manche Server erst später über einen Empfänger entscheiden. Mehr dazu steht im Beitrag zum SMTP-Handshake.
5. Einordnung: Welche Aussage tragen die Belege?
Am Schluss werden die Beobachtungen und weitere Signale zusammengeführt: Catch-all-Verhalten, eine Wegwerfadresse, ein wahrscheinlicher Tippfehler in der Domain oder ein Rollenpostfach wie support@. Ein Wegwerf- oder Rollenpostfach kann technisch erreichbar sein. Ob es für Ihren Ablauf geeignet ist, entscheiden Sie selbst. Bei einer Catch-all-Domain sagt die Annahme womöglich nur etwas über eine allgemeine Serverregel aus.
Wenn der Mailserver keine klare Antwort gibt
Drosselung, eine vorübergehende Zurückstellung, verborgene Empfängerinformationen und Zeitüberschreitungen verhindern oft einen eindeutigen Befund. Das ist kein dauerhafter Fehler der Adresse. Auch wenn ein Server beliebige Namen annimmt, beweist eine positive Antwort auf RCPT TO kein einzelnes Postfach. Deshalb kann eine abgeschlossene Prüfung risky oder unknown ergeben.
Ergebnis und Empfehlung getrennt lesen
Vier status-Werte schließen die Prüfung ab:
status |
Bedeutung |
|---|---|
deliverable |
Mailweg und vorhandene Empfängerbelege sprechen für Annahme, ohne künftige Zustellung zu garantieren. |
risky |
Mail kann ankommen, aber ein konkretes Signal verlangt Aufmerksamkeit. |
undeliverable |
Ein dauerhafter technischer Befund spricht gegen die Adresse. |
unknown |
Die vorhandenen Belege reichen für keine eindeutige Aussage. |
pending bedeutet, dass die Empfängerprüfung noch läuft oder in der Warteschlange steht. Es ist ein Transportzustand, kein fünftes Urteil. Fragen Sie das Ergebnis nach dem angegebenen Intervall erneut ab.
Die übrigen Felder zeigen, wie das Urteil entstand: checks enthält die Ergebnisse der Schritte, reason_codes nennt die Signale und freshness das Alter der DNS- und SMTP-Belege. confidence ist ein Evidenzwert, keine Zustellwahrscheinlichkeit. action empfiehlt allow, allow_with_email_confirmation oder reject. Diese Empfehlung folgt nicht starr aus status: Bei risky sind je nach Ursache sowohl allow als auch allow_with_email_confirmation möglich. Im Artikel zum Lesen eines Prüfungsergebnisses werden die Felder vertieft; die API für E-Mail-Verifizierung zeigt das Antwortformat.
Was Sie mit dem Ergebnis tun können
Bei einer einzelnen Adresse lesen Sie neben dem Status auch die Gründe. unknown ist kein anderes Wort für ungültig. Sie können eine einzelne Adresse prüfen und die Belege direkt ansehen.
Bei Registrierung oder Checkout kann ein klarer technischer Fehler Anlass für eine Korrektur sein. Einen wahrscheinlichen Tippfehler kann die Person sofort beheben. Falls die Kontrolle des Postfachs wichtig ist, kann bei risky oder unknown eine Bestätigungs-E-Mail folgen. Der Leitfaden für Registrierungsformulare ordnet die Ergebnisse in diesen Ablauf ein.
Bei einer bestehenden Liste trennen Sie belegte Ausfälle, Risikosignale und offene Fälle. Behalten Sie freshness im Blick: DNS- und Serverbeobachtungen gelten nicht auf Dauer. Ein Rollen- oder Wegwerfpostfach ist auch bei technischer Erreichbarkeit eine Frage Ihrer Regeln.
Die Verifizierung beweist weder Identität noch Einwilligung, Interesse, Posteingangsplatzierung oder künftige Zustellung. Eine Bestätigung belegt nur, dass jemand das Postfach beim Klicken oder Eingeben des Codes kontrolliert hat. Treffen Sie mit technischen Belegen nur die Entscheidung, die diese Belege tatsächlich tragen.