Wegwerf-, vertippte und E-Mail-Adressen ohne Mailserver bei der Registrierung erkennen

Geben Sie Ihrem Registrierungsformular eine frühe Prüfung jeder Adresse: Syntax, bekannte Wegwerf-/Temporär-Domains, ob die Domain überhaupt einen Mailserver hat, wahrscheinliche Tippfehler und Funktionsadressen – als Urteil accept, review oder reject samt Gründen. Rufen Sie POST /v1/email/validate aus dem JavaScript Ihres Formulars auf oder prüfen Sie Listen in großen Mengen aus Ihrem Backend oder im Dashboard.

Die E-Mail-Prüfungs-Referenz lesen Den Signup-Missbrauch-Workflow ansehen →

Anfrage und Authentifizierung

Senden Sie einen JSON-Body { "email": "user@example.com" } an POST /v1/email/validate mit einem veröffentlichbaren, Origin-gebundenen Schlüssel im Header X-Api-Key – derselbe Schlüsseltyp und dasselbe Modell erlaubter Origins wie bei GET /v1/geo, daher ist der direkte Aufruf aus einem Registrierungsformular während der Eingabe oder beim Absenden unbedenklich. Serverseitig schaltet Ihr geheimer Schlüssel POST /v1/email/batch (bis zu 100 Adressen pro Anfrage), asynchrone Listenjobs mit bis zu 100.000 Adressen (per API oder über die Dashboard-Seite Email lists, CSV rein und CSV raus) sowie POST /v1/signup/check frei, das die E-Mail-Prüfung mit den Netzwerkindikatoren der registrierenden IP zu einem Score kombiniert.

Erst das Urteil lesen, dann die Gründe

verdict ist das schwerwiegendste Ergebnis: reject bei ungültiger Syntax, einer nicht existierenden Domain, einer Domain ohne Mailserver oder einer Wegwerf-Domain; review bei einem vermuteten Tippfehler, einer Funktionsadresse wie info@, einer Domain mit nur implizitem Mailserver oder einer nicht abgeschlossenen DNS-Abfrage; sonst accept. reasons listet jede zutreffende Bedingung auf, damit Ihr Formular eine gezielte Meldung anzeigen kann – und wenn didYouMean gesetzt ist, bieten Sie statt einer Fehlermeldung die Korrektur an.

Wann Sie es aufrufen sollten

Rufen Sie die Prüfung beim Verlassen des Felds oder beim Absenden auf, nicht bei jedem Tastendruck – eine noch unvollständige Adresse bei jedem Zeichen zu prüfen, erzeugt Anfragen ohne nützliches Signal und kann eine Fehlermeldung flackern lassen, während der Besucher noch tippt. Jeder Aufruf zählt als eine Anfrage.

Wenn die Anfrage fehlschlägt

Fail open: Lassen Sie die Registrierung weiterlaufen, wenn die Netzwerkanfrage fehlschlägt oder das Zeitlimit überschreitet, statt wegen eines clientseitigen Ausfalls jeden Besucher zu blockieren. Serverseitig wird eine fehlgeschlagene DNS-Abfrage als Grund dns_unavailable (Urteil review) gemeldet, nie als Fehler oder reject. Bewahren Sie alles auf, was der Besucher bereits eingegeben hat, damit ihn eine fehlgeschlagene Prüfung nie seine Eingabe kostet.

Wie Wegwerf-Domains erkannt werden

Bekannte Wegwerf-/Temporär-Domains werden aus drei von der Community gepflegten Open-Source-Listen zusammengeführt (siehe Datenquellen), alle paar Stunden aktualisiert und durch eine Allowlist ergänzt, damit ein fehlerhafter Upstream-Eintrag nie einen großen Anbieter markieren kann. Subdomains einer gelisteten Domain werden ebenfalls erkannt. Neue Wegwerf-Domains, die noch auf keiner Liste stehen, werden oft über ihren Mailserver erkannt: Wegwerf-Dienste lassen viele Domains auf dieselben wenigen Mail-Hosts zeigen, und eine Domain, deren Mailserver bekanntermaßen gelistete Domains bedient, wird mit disposableSource: mx_host markiert. Ein sehr neuer Anbieter auf einem neuen Mailserver wird möglicherweise noch nicht erkannt.

Nutzung und Kontingent

Jede geprüfte Adresse zählt als eine Anfrage gegen das gemeinsame Monatskontingent Ihres Tarifs – eine Einzelprüfung, jede Adresse in einem Batch, jede eindeutige Adresse in einem Listenjob – zusammen mit Ihrem übrigen Traffic und derselben Ratenbegrenzung pro Minute. Es gibt keinen separaten E-Mail-Tarif und keinen eigenen Preis. Die Ratenbegrenzung pro Minute zählt HTTP-Aufrufe, nicht Einträge: Ein Batch mit bis zu 100 IPs oder E-Mail-Adressen zählt als eine Anfrage, während jeder Eintrag weiterhin einzeln auf das monatliche Anfragekontingent angerechnet wird.

Was dies nicht überprüft

Jede Prüfung erfolgt auf Domain- oder Adressebene. Watch-IP kontaktiert nie den Mailserver des Empfängers, daher belegt ein Ergebnis nicht, dass das Postfach existiert, dass E-Mails dort ankommen oder dass es der sich registrierenden Person gehört. Ein Urteil accept bedeutet „kein Problem gefunden“, nicht eine bestätigt funktionierende Adresse – dafür nutzen Sie eine Bestätigungs-E-Mail.

Antwortfelder

syntaxValid: Ob die Adresse syntaktisch gültig ist.
isDisposable: Ob die Domain einem bekannten Wegwerf-/Temporär-Anbieter entspricht – direkt, über eine übergeordnete Domain oder über ihren Mailserver. Immer false, wenn syntaxValid false ist.
disposableSource: list, parent_domain oder mx_host – warum isDisposable true ist; sonst null.
mx: Der Mailserver-Status der Domain (found, implicit, none, null_mx, no_domain oder unknown) und ihr primärer MX-Host.
didYouMean: Eine wahrscheinliche Tippfehlerkorrektur wie gmial.com → gmail.com oder null.
isRoleAccount / isFreeProvider: Kennzeichen für Funktionsadressen (admin@, info@, noreply@…) und Postfachanbieter für Endkunden. Freemail-Anbieter ist nur informativ.
normalizedEmail / canonicalEmail: Die Adresse in Kleinbuchstaben und dieselbe ohne +Tags (und Gmail-Punkte), um doppelte Konten zu erkennen.
verdict / reasons: accept, review oder reject sowie jeder zutreffende Grundcode – die vollständige Liste finden Sie in der Referenz.

Auf das Urteil reagieren

JavaScript für das Anmeldeformular

async function checkEmail(email) {
  const response = await fetch('https://api.watch-ip.com/v1/email/validate', {
    method: 'POST',
    headers: { 'X-Api-Key': 'YOUR_PUBLISHABLE_KEY', 'Content-Type': 'application/json' },
    body: JSON.stringify({ email }),
  });
  if (!response.ok) return { state: 'unknown' }; // fail open – Registrierung bei Netzwerkfehler nicht blockieren

  const result = await response.json();
  if (result.didYouMean) return { state: 'suggest', suggestion: result.didYouMean };
  if (result.verdict === 'reject') return { state: 'reject', reasons: result.reasons };
  return { state: 'ok' }; // accept oder review: Registrierung zulassen und im Backend markieren
}

Zeigen Sie pro Grund eine eigene Meldung an – invalid_syntax, disposable_domain und no_mail_server erfordern unterschiedliche Korrekturen durch den Besucher – und bieten Sie didYouMean als Korrektur mit einem Klick an.

Häufig gestellte Fragen

Wird geprüft, ob das Postfach existiert?

Nein. Geprüft werden die Syntax, die Listen und DNS-Mailserver-Einträge der Domain sowie die Form der Adresse. Der Mailserver wird nie kontaktiert und es wird nicht bestätigt, dass das einzelne Postfach existiert – ein reject wegen no_mail_server betrifft die gesamte Domain.

Ist accept ein Beweis, dass die E-Mail funktioniert?

Nein. accept bedeutet, dass keine der Prüfungen ein Problem gefunden hat – nicht, dass die Adresse garantiert E-Mails empfängt oder der sich registrierenden Person gehört. Nutzen Sie eine Bestätigungs-E-Mail, wenn Sie das brauchen.

Können Nutzer die Browser-Validierung umgehen?

Ja. Jede browserseitige Prüfung, auch diese, lässt sich umgehen, indem JavaScript deaktiviert oder Ihr Registrierungs-Endpoint direkt aufgerufen wird. Setzen Sie jede wichtige Entscheidung im Backend durch – POST /v1/signup/check ist genau dafür gemacht.

Kann ich eine bestehende Liste bereinigen?

Ja. Laden Sie eine CSV-Datei auf der Dashboard-Seite Email lists hoch oder senden Sie bis zu 100.000 Adressen mit Ihrem geheimen Schlüssel an POST /v1/email/jobs und laden Sie anschließend eine Ergebnis-CSV mit Urteil und Gründen pro Zeile herunter. Duplikate werden einmal berechnet, Uploads und Ergebnisse nach 7 Tagen gelöscht.

Wie werden Anfragen gezählt?

Eine Anfrage pro geprüfter Adresse, angerechnet auf das gemeinsame Monatskontingent Ihres Tarifs. Duplikate innerhalb eines Listenjobs zählen einmal; eine Registrierungsprüfung zählt als eine Anfrage.