Um eine Catch-all-E-Mail-Adresse zu prüfen, beginnen Sie mit der Adresse und ihrem Mailweg. Danach vergleichen Sie die SMTP-Antwort für den gewünschten Empfänger mit der Antwort für einen zufällig erzeugten Kontroll-Empfänger. Nimmt der Server beide an, kennen Sie das Verhalten der Domain. Ob das angefragte Postfach existiert, wissen Sie weiterhin nicht. Behandeln Sie das Ergebnis als risky und verwenden Sie eine Bestätigungs-E-Mail, wenn Sie die Kontrolle über das Postfach nachweisen müssen.
Eine Catch-all-Domain kann Mail für jeden Namen annehmen, auch für Namen, die niemand verwendet. Deshalb passt auf solche Adressen kein schlichtes „gültig“ oder „ungültig“. Die Definition einer Catch-all-Domain erklärt die Regel; hier geht es um die Prüfung und Ihre Entscheidung danach.
Schritt 1: Eindeutige Fehler vor dem Netzwerk erkennen
Prüfen Sie zuerst die Syntax: lokaler Teil, Domain und Gesamtlänge. Dafür brauchen Sie noch keine DNS-Abfrage. Ein internationalisierter lokaler Teil kann beim späteren SMTP-Kontakt die Erweiterung SMTPUTF8 benötigen. Sie ist in RFC 6531 beschrieben. Eine bestandene Syntaxprüfung beweist nur, dass die Adresse formal aufgebaut ist.
Danach prüfen Sie, ob die Domain existiert und wohin sie eingehende Mail leitet. Eine eindeutig nicht existente Domain oder ein ausdrücklicher Null-MX kann die Prüfung vor SMTP beenden. Fehlt dagegen nur ein gewöhnlicher MX-Eintrag, ist die Domain noch nicht ausgeschlossen: Nach RFC 5321 kommt gegebenenfalls ein impliziter Mailweg über ihre A- oder AAAA-Adresse infrage. RFC 7505 definiert den Null-MX. Der Beitrag zum MX-Eintrag erläutert die Unterschiede.
Ein funktionierender Mailweg sagt, wohin eine Nachricht gehen könnte. Er belegt kein Postfach wie alex@example.com.
Schritt 2: Den gewünschten Empfänger abfragen
Eine vollständige Prüfung kann eine SMTP-Sitzung öffnen und die Adresse mit RCPT TO nennen. Der Zielserver kann sie annehmen, die Antwort vertagen, ablehnen oder die Probe verhindern. Emvero beendet die Probe vor DATA; dabei wird keine E-Mail gesendet. RFC 5321 trennt Empfängerangabe und Nachrichtentext.
Eine positive Antwort belegt die Annahme in dieser Sitzung. Noch wissen Sie nicht, ob der Server echte von erfundenen Empfängern unterscheidet. Eine vorübergehende Antwort oder eine blockierte Probe lässt die Frage offen. Selbst eine intern als „Postfach nicht gefunden“ eingeordnete Antwort wird nach der aktuellen Emvero-Regel als unknown mit SMTP_RECIPIENT_REJECTED_AMBIGUOUS gemeldet. Sie führt nicht automatisch zu reject.
Schritt 3: Nach einer Annahme einen Kontroll-Empfänger testen
Wurde die angefragte Adresse angenommen, nennen Sie in derselben Sitzung genau eine neu erzeugte, unwahrscheinliche Adresse an der gleichen Domain. Verwenden Sie einen Zufallswert statt eines vertrauten Namens wie test: Ein solcher Name könnte tatsächlich existieren. Die Emvero-Dokumentation zum Catch-all-Verhalten beschreibt diese Kontrolle.
| Angefragte Adresse | Kontrolladresse | Was folgt daraus? |
|---|---|---|
| Angenommen | Angenommen | Der Server nimmt beliebige Namen an. Die Domain verhält sich wie eine Catch-all-Domain; das einzelne Postfach bleibt unbelegt. |
| Angenommen | Eindeutig abgelehnt | Der Server unterscheidet Empfänger. Die Annahme der angefragten Adresse ist ein stärkerer Postfach-Beleg, aber keine Zusage für spätere Zustellung. |
| Angenommen | Vorübergehende oder mehrdeutige Antwort | Ob die Domain Catch-all verwendet, bleibt offen. Diese Antwort ist keine eindeutige Ablehnung. |
| Abgelehnt oder keine Probe | Nicht gesendet | Es gibt keine Annahme, die sich durch eine Kontrolladresse einordnen ließe. Lesen Sie die erste Antwort für sich. |
Die Kontrolle misst eine Regel der Domain. Sie ist keine Suche nach ihren Postfächern und beweist nicht, wer ein Postfach besitzt. Emvero kann einen bereits bekannten Catch-all-Status wiederverwenden, statt bei jeder Adresse erneut einen Kontroll-Empfänger zu nennen.
Schritt 4: Aus dem Ergebnis eine Handlung ableiten
Bei einer bekannten Catch-all-Domain kann eine vollständige Prüfung so aussehen:
{
"status": "risky",
"action": "allow_with_email_confirmation",
"checks": { "smtp": "accepted", "accept_all": "yes" },
"reason_codes": ["SMTP_RCPT_ACCEPTED", "ACCEPT_ALL_DOMAIN"]
}
SMTP_RCPT_ACCEPTED beschreibt die Antwort zum Empfänger. ACCEPT_ALL_DOMAIN erklärt, warum sie kein einzelnes Postfach belegt. Lesen Sie status, action, checks.accept_all und reason_codes zusammen. Eine SMTP-Ablehnung wird nicht zu einem eindeutigen Domain-Fehler: Das fertige Ergebnis kann unknown bleiben. Ein falsches Adressformat, eine nicht existente Domain oder ein Null-MX sind andere, frühere Gründe für eine Zurückweisung.
Bei einer Registrierung kann die Person zunächst fortfahren und ihre Adresse per E-Mail bestätigen. Der Leitfaden für Registrierungsformulare zeigt, wie Sie risky und unknown behandeln, ohne sie als sicheren Fehler auszugeben.
Bei der Listenbereinigung halten Sie Catch-all-Adressen getrennt von gesichert unzustellbaren Adressen und bewahren das Alter der Beobachtung auf. Mailwege und Empfängerregeln können sich ändern. Der Leitfaden zur Bereinigung von E-Mail-Listen beschreibt die Prüfung dieser Gruppe.
Für die Kontaktaufnahme müssen Herkunft und Erlaubnis der Adresse getrennt betrachtet werden. Eine technische Prüfung belegt keine Einwilligung. Eine Bestätigung zeigt nur, dass jemand zum Zeitpunkt der Reaktion Zugriff auf das Postfach hatte. Sie garantiert weder spätere Zustellung noch Platzierung im Posteingang.
Bekannten Status abfragen oder vollständig prüfen
Der kostenlose Catch-all-Checker zeigt einen bereits festgestellten Domain-Status. Er öffnet keine SMTP-Sitzung; ohne verlässliche Information bleibt die Antwort unknown. Neue Belege zum Empfänger erfordern eine vollständige Prüfung über die API zur E-Mail-Verifizierung:
curl -sS https://api.emvero.tech/v1/verifications \
-H "Authorization: Bearer emv_your_credential" \
-H "Content-Type: application/json" \
-d '{"email":"alex@example.com","variant":"full"}'
Während der Empfänger geprüft wird, kann die API zunächst pending melden. Lesen Sie im fertigen Ergebnis action und reason_codes, bevor Ihre Anwendung entscheidet. Bei allow_with_email_confirmation klärt eine echte Bestätigungs-E-Mail die offene Frage, keine weitere SMTP-Probe.