E-Mail-Verifizierung in Node.js: Über Regex hinaus zur Prüfung der E-Mail-Zustellbarkeit

Ein Service-Ablauf in Node.js für die E-Mail-Verifizierung: lokale Formatprüfung, eine serverseitige Prüfung der E-Mail-Zustellbarkeit und eine klare Handhabung jedes Ergebnisses.

Die E-Mail-Verifizierung in Node.js funktioniert am besten in zwei Ebenen auf dem Server. Zuerst normalisieren Sie die Eingabe und prüfen das Format lokal, damit offensichtliche Tippfehler Ihren Prozess gar nicht erst verlassen. Zweitens rufen Sie eine Prüfung der E-Mail-Zustellbarkeit wie POST /api/v1/check von EmailCheckPro über Ihren Server-Code mit einem Timeout auf und unterscheiden zwischen drei Ergebnissen: Zustellbar, Nicht zustellbar oder Unbestimmt. Ein Regex allein sagt Ihnen nur, ob eine Adresse korrekt aussieht; die Prüfung der E-Mail-Zustellbarkeit verrät Ihnen, ob sie zum Zeitpunkt der Prüfung E-Mails empfangen könnte, ohne dass eine Nachricht an sie gesendet wird. Bestätigungslinks bleiben ein separater Schritt für die Einwilligung und den Nachweis der Inhaberschaft.

Was E-Mail-Verifizierung in Node.js üblicherweise bedeutet

Sucht man nach diesem Thema, zeigen die meisten Anleitungen entweder einen Regex oder eine Express-Route, die einen Bestätigungslink per E-Mail versendet. Beides ist nützlich, beantwortet aber unterschiedliche Fragen, und eine Vermischung führt zu Fehlern.

Dieser Leitfaden behandelt die ersten beiden Ebenen, die ausgeführt werden, bevor Sie irgendetwas versenden. Sie ergänzen einen Bestätigungsablauf, anstatt ihn zu ersetzen. Das Muster spiegelt die Verifizierung auf Service-Ebene in anderen Frameworks wider: Der Browser kann schnelle Hinweise geben, aber die Entscheidung liegt auf dem Server, wo der API-Schlüssel und das gespeicherte Ergebnis liegen.

Schritt 1: Normalisierung und Formatprüfung

Beginnen Sie mit einer kleinen, vorhersehbaren Funktion. Entfernen Sie Leerzeichen, löschen Sie nachgestellte Satzzeichen, die oft durch Kopieren entstehen, schreiben Sie die Domain klein und belassen Sie den lokalen Teil so, wie er eingegeben wurde. Testen Sie das Ergebnis dann gegen ein allgemeines Muster.

// Muster aus dem WHATWG HTML-Standard für type="email"-Eingaben
const EMAIL_PATTERN = /^[a-zA-Z0-9.!#$%&'*+\/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$/;

export function normalizeEmail(raw) {
 const trimmed = String(raw ?? '').trim().replace(/[.,;:]+$/, '');
 const at = trimmed.lastIndexOf('@');
 if (at < 1 || at === trimmed.length - 1) return null;
 const email = trimmed.slice(0, at) + '@' + trimmed.slice(at + 1).toLowerCase();
 return EMAIL_PATTERN.test(email) ? email : null;
}

Das Muster stammt aus dem WHATWG HTML-Standard, derselben Regel, die Browser für type="email"-Felder anwenden, sodass Client und Server übereinstimmen. Wenn Sie ein gepflegtes Paket bevorzugen, ist isEmail in validator.js eine gängige Wahl; wählen Sie eine Quelle der Wahrheit und verwenden Sie diese überall.

Häufige Fehler auf dieser Ebene:

• Zu strenge Muster, die +-Tags, lange Top-Level-Domains oder Subdomains ablehnen. Die OWASP-Anleitung empfiehlt, eine breite Palette gültiger Formate zu akzeptieren und nur eindeutig fehlerhafte Eingaben abzulehnen.
• Kleinschreibung der gesamten Adresse. Domains sind nicht zwischen Groß- und Kleinschreibung zu unterscheiden, aber das Ändern des lokalen Teils verändert das, was der Benutzer eingegeben hat.

Schritt 2: Aufruf der Prüfung der E-Mail-Zustellbarkeit vom Server

Node.js 18 und höher verfügen über ein globales fetch, daher ist keine HTTP-Bibliothek erforderlich. Der Aufruf muss auf dem Server erfolgen: Der API-Schlüssel verbraucht das Kontoguthaben und darf niemals in den Browser-Code gelangen.

const API_BASE = process.env.EMAILCHECK_API_BASE; // aus der API-Dokumentation

export async function checkDeliverability(email) {
 try {
 const res = await fetch(`${API_BASE}/api/v1/check`, {
 method: 'POST',
 headers: buildHeaders(), // Authentifizierungs-Header genau wie dokumentiert
 body: buildCheckBody(email), // Request-Body genau wie dokumentiert
 signal: AbortSignal.timeout(4000) // Ihr eigenes Zeitbudget
 });
 return await toOutcome(res); // 'deliverable' | 'undeliverable' | 'undetermined'
 } catch (err) {
 return 'not_completed'; // TimeoutError, Netzwerkfehler, etc.
 }
}

buildHeaders, buildCheckBody und toOutcome sind schlanke Hilfsfunktionen, die Sie basierend auf der EmailCheckPro API-Dokumentation schreiben, sodass die Authentifizierungs- und Felddetails an einem Ort bleiben und dem veröffentlichten Vertrag folgen. toOutcome sollte einfache Wörter zurückgeben, anstatt rohe Antwortobjekte durch Ihre Codebasis zu leiten.

AbortSignal.timeout() bricht die Anfrage nach dem von Ihnen gewählten Budget ab und löst einen TimeoutError aus, wodurch verhindert wird, dass ein langsames Netzwerk ein Anmeldeformular blockiert. Die Node.js fetch-Referenz listet die unterstützten Optionen auf. Wählen Sie das Timeout basierend auf der Toleranz Ihres Formulars; der obige Wert ist ein Beispiel, keine Vorgabe.

Die Prüfung der E-Mail-Zustellbarkeit akzeptiert Adressen auf nahezu jeder Domain. Wenn das Produkt öffentliche Avatare benötigt, ist die Profilbildprüfung für E-Mails auf Gmail-, Yandex- und Mail.ru-Domains beschränkt; leiten Sie andere Domains daher an das Zustellbarkeitsprodukt weiter.

Schritt 3: Handhabung von Zustellbar, Nicht zustellbar und Unbestimmt

Modellieren Sie das Ergebnis als eine kleine Gruppe von Zuständen und lassen Sie das Formular von dort aus entscheiden:

export async function screenSignupEmail(raw) {
 const email = normalizeEmail(raw);
 if (!email) return { ok: false, message: 'Bitte überprüfen Sie das E-Mail-Format.' };

 const outcome = await checkDeliverability(email);
 await saveCheck({ email, outcome, checkedAt: new Date() });

 switch (outcome) {
 case 'deliverable': return { ok: true, email };
 case 'undeliverable': return { ok: false, message: 'Diese Adresse konnte keine E-Mails empfangen. Bitte verwenden Sie eine andere.' };
 default: return { ok: true, email, flagged: true }; // unbestimmt oder nicht abgeschlossen
 }
}

Warum jeder Zweig sich so verhält:

• Zustellbar bedeutet, dass die Adresse zum Zeitpunkt der Prüfung E-Mails empfangen konnte. Fahren Sie fort und speichern Sie das Datum mit dem Ergebnis.
• Nicht zustellbar bedeutet, dass dies nicht möglich war. Bitten Sie freundlich um eine andere Adresse; beschuldigen Sie den Benutzer nicht, eine gefälschte Adresse eingegeben zu haben.
• Unbestimmt deckt Adressen ab, die nicht eindeutig geklärt werden können, wie z. B. Catch-All-Adressen. Die Echtzeit-API gibt für diese einen Geschäftscode anstelle eines Ergebnisses zurück, und sie werden nicht berechnet. Akzeptieren Sie die Adresse mit einer Markierung, anstatt zu raten.
• Nicht abgeschlossen deckt Timeouts und Netzwerkfehler ab. Wenn Sie den Benutzer mit einer Markierung fortfahren lassen, verhindern Sie, dass ein vorübergehendes Problem eine echte Anmeldung blockiert.

Ein Hintergrundjob kann später markierte Zeilen erneut prüfen, und die Bestätigungs-E-Mail, die Sie ohnehin senden, wird viele davon klären.

Überprüfung mehrerer Adressen von Node.js aus

Anmeldeformulare prüfen eine Adresse, aber Admin-Tools und Importe enthalten oft viele. Zwei dokumentierte Pfade decken diese ab.

Bis zu 100 Adressen gleichzeitig. POST /api/v1/batch-check akzeptiert 1–100 Adressen und gibt Ergebnisse in derselben Antwort in der Reihenfolge der Eingabe zurück. Teilen Sie größere Arrays in Blöcke von 100 auf und ordnen Sie jede Antwort ihrem Block nach Position zu. Jeder Eintrag gibt an, ob ein abgeschlossenes Ergebnis vorliegt; ein Eintrag ohne ein solches gehört in den Zweig "Unbestimmt" oder "Nicht abgeschlossen", niemals in "Nicht zustellbar".

Vorbereitete Dateien. Für Exporte und Migrationen schreiben Sie eine TXT- oder CSV-Datei mit einer vollständigen Adresse pro Zeile und übermitteln Sie diese mit POST /api/v1/bulk-tasks. Die Aufgabe wird asynchron ausgeführt, fragen Sie den Status also von einem Worker ab, nicht von einem Request-Handler:

const sleep = (ms) => new Promise((r) => setTimeout(r, ms));

async function waitForTask(taskRef) {
 for (;;) {
 const status = await getTaskStatus(taskRef); // GET /api/v1/bulk-tasks/{id}
 if (status.done) return status; // Erfolg oder Fehler
 await sleep(30_000); // fragen Sie niemals schneller ab als dies
 }
}

Eine erfolgreiche Aufgabe stellt eine Ergebnis-CSV unter einem Download-Link bereit, der 12 Stunden lang gültig ist; eine erneute Abfrage derselben Aufgabe liefert einen neuen Link. Ungültige und doppelte Zeilen werden während der Vorbereitung entfernt, führen Sie Ergebnisse also nach E-Mail-Adresse zusammen, nicht nach Zeilennummer. Produktbezogene Aufgabenlimits sind in der API-Dokumentation aufgeführt.

Produktions-Checkliste für eine Node.js-Integration

• Geheimnisse: Lesen Sie den API-Schlüssel aus der Umgebung oder einem Secret-Manager und halten Sie ihn aus Protokollen und Fehlerberichten fern.
• Caching: Speichern Sie das Ergebnis mit seinem Datum und verwenden Sie es innerhalb Ihres eigenen Zeitfensters für erneute Prüfungen wieder, damit das Bearbeiten eines Profilnamens keinen neuen Aufruf auslöst.
• Ihr eigener Endpunkt: Wenn die App eine Adressprüfungs-Route bereitstellt, fügen Sie Ratenbegrenzungen und konsistente Antworten hinzu, damit sie nicht dazu verwendet werden kann, zu prüfen, welche Konten existieren.
• Warteschlangen: Führen Sie erneute Prüfungen markierter Zeilen aus einer Job-Warteschlange mit einer Verzögerung und einer Begrenzung der Versuche aus, anstatt innerhalb der Anfrage erneut zu versuchen.
• Tests: Testen Sie normalizeEmail mit Plus-Tags, Subdomains, nachgestellten Leerzeichen und fehlenden Domains und testen Sie jeden Ergebnis-Zweig mit einem Stub für checkDeliverability, damit der UI-Text vor dem Start überprüft wird.
• KI-Tools: Teams, die auch mit KI-Assistenten arbeiten, können den MCP-Endpunkt unter https://emailcheckpro.com/mcp für Einzelprüfungen und bis zu 100 Adressen verwenden, während dateibasierte Aufgaben auf der REST-API verbleiben.

FAQ

Reicht ein Regex für die E-Mail-Verifizierung in Node.js aus?

Ein Regex reicht aus, um fehlerhafte Eingaben abzufangen, und er sollte zuerst ausgeführt werden, da er keine Kosten verursacht. Teams, die wissen müssen, ob eine Adresse zustellbar ist, fügen nach dem Regex eine serverseitige Prüfung hinzu und behalten den Bestätigungslink für die Einwilligung und den Nachweis der Inhaberschaft bei.

Sollte die Prüfung der E-Mail-Zustellbarkeit im Browser oder auf dem Server ausgeführt werden?

Auf dem Server. Der API-Schlüssel verbraucht das geteilte Kontoguthaben, daher ermöglicht die Offenlegung im Front-End-Code jedem, ihn zu verwenden. Eine Server-Route kann auch eigene Ratenbegrenzungen anwenden, das Ergebnis mit einem Datum speichern und entscheiden, wie mit unbestimmten oder zeitlich abgelaufenen Prüfungen umgegangen wird. Der Browser kann weiterhin sofortige Format-Hinweise unter Verwendung desselben WHATWG-Musters anzeigen.

Wie können Teams vermeiden, echte Benutzer zu blockieren, wenn eine Prüfung unbestimmt ist?

Akzeptieren Sie die Adresse mit einer Markierung, anstatt sie abzulehnen. Unbestimmte Ergebnisse, wie z. B. Catch-All-Adressen, sind kein Beweis dafür, dass eine Adresse schlecht ist, und sie werden nicht berechnet. Ein markiertes Konto kann weiterhin die Bestätigungs-E-Mail erhalten; ein späterer Job kann sie erneut prüfen, und Versand-Pipelines können markierte Zeilen zurückhalten, bis ein abgeschlossenes Ergebnis oder ein Bestätigungsklick registriert wurde.

Mehr erfahren

Wählen Sie die Produktinformationen, die zum nächsten Schritt in Ihrem Arbeitsablauf passen.

• Produkt-Dokumentation ansehen →
• Mit dem Team sprechen →