So validieren Sie E-Mails in Node.js, ohne ein Paket zu installieren

Node.js-Integration: Express-Anmelderoute

Hier ist ein vollständiger Express-Route-Handler, der die E-Mail beim POST validiert /signup mit nativem Abruf. Das Fail-Open-Muster stellt sicher, dass ein Botoi-Ausfall niemals echte Anmeldungen blockiert:

import express from 'express';

const app = express();
app.use(express.json());

app.post('/signup', async (req, res) => {
  const { email, password } = req.body;

  if (!email || !password) {
    return res.status(400).json({ error: 'Email and password are required' });
  }

  // Validate email before creating the account
  try {
    const validation = await fetch('https://api.botoi.com/v1/email/validate', {
      method: 'POST',
      headers: {
        'Content-Type': 'application/json',
        'Authorization': \`Bearer \${process.env.BOTOI_API_KEY}\`,
      },
      body: JSON.stringify({ email }),
      signal: AbortSignal.timeout(3000),
    });

    const result = await validation.json();

    if (result.success && !result.data.is_valid) {
      return res.status(422).json({
        error: 'Invalid email address',
        reason: result.data.reason,
      });
    }
  } catch {
    // Fail open: if the API is unreachable, let the signup proceed
    console.warn('Email validation API unreachable, skipping check');
  }

  // Email passed validation; continue with account creation
  // await createUser(email, password);

  return res.status(201).json({ message: 'Account created' });
});

app.listen(3000);

Die Route lehnt ungültige E-Mails mit einem 422 und dem spezifischen ab reason aus der API. Wenn die API nicht erreichbar ist, wird die Anmeldung fortgesetzt. Sie tauschen einen verpassten Scheck gegen einen ununterbrochenen Benutzerfluss ein.

Dreischichtige Validierung

Der /v1/email/validate endpoint deckt die Grundlagen ab. Kombinieren Sie für eine gründliche Prüfung drei Endpunkte:

• /v1/email/validate für Syntax und Format
• /v1/email-mx/verify zur Überprüfung des MX-Eintrags
• /v1/disposable-email/check zur Einwegerkennung

Diese Hilfsfunktion ruft alle drei auf und gibt ein strukturiertes Ergebnis zurück:

interface ValidationResult {
  valid: boolean;
  formatValid: boolean;
  mxValid: boolean;
  isDisposable: boolean;
  reason: string | null;
}

const API_BASE = 'https://api.botoi.com/v1';
const headers = {
  'Content-Type': 'application/json',
  'Authorization': \`Bearer \${process.env.BOTOI_API_KEY}\`,
};

async function validateEmail(email: string): Promise<ValidationResult> {
  const result: ValidationResult = {
    valid: true,
    formatValid: false,
    mxValid: false,
    isDisposable: false,
    reason: null,
  };

  // Layer 1: Syntax and format check
  const formatRes = await fetch(\`\${API_BASE}/email/validate\`, {
    method: 'POST',
    headers,
    body: JSON.stringify({ email }),
    signal: AbortSignal.timeout(3000),
  });
  const formatData = await formatRes.json();

  if (!formatData.success || !formatData.data.format_valid) {
    return { ...result, valid: false, reason: 'invalid_format' };
  }
  result.formatValid = true;

  // Layer 2: MX record verification
  const mxRes = await fetch(\`\${API_BASE}/email-mx/verify\`, {
    method: 'POST',
    headers,
    body: JSON.stringify({ email }),
    signal: AbortSignal.timeout(3000),
  });
  const mxData = await mxRes.json();

  if (!mxData.success || !mxData.data.has_mx) {
    return { ...result, valid: false, reason: 'no_mx_records' };
  }
  result.mxValid = true;

  // Layer 3: Disposable provider detection
  const dispRes = await fetch(\`\${API_BASE}/disposable-email/check\`, {
    method: 'POST',
    headers,
    body: JSON.stringify({ email }),
    signal: AbortSignal.timeout(3000),
  });
  const dispData = await dispRes.json();

  if (dispData.success && dispData.data.is_disposable) {
    return { ...result, valid: false, isDisposable: true, reason: 'disposable_provider' };
  }

  return result;
}

Benutzen Sie es so:

const result = await validateEmail('user@tempmail.xyz');

if (!result.valid) {
  console.log(\`Rejected: \${result.reason}\`);
  // Rejected: disposable_provider
}

Jede Ebene fängt eine andere Klasse schädlicher E-Mails ab. Formatprüfungen verhindern unnötige Eingaben. MX-Checks stoppen erfundene Domains. Wegwerfschecks verhindern Wegwerfanmeldungen. Zusammen schließen sie die Lücke, die Regex offen lässt.

Hinzufügen zu einer Next.js-API-Route

Die gleiche Logik funktioniert in einem Next.js App Router-Routenhandler unter app/api/validate-email/route.ts. Diese Version führt die Formatprüfung und die Einwegprüfung parallel aus, um die Latenz zu reduzieren:

import { NextResponse } from 'next/server';

const API_BASE = 'https://api.botoi.com/v1';
const headers = {
  'Content-Type': 'application/json',
  'Authorization': \`Bearer \${process.env.BOTOI_API_KEY}\`,
};

export async function POST(req: Request) {
  const body = await req.json();
  const email = body.email?.trim().toLowerCase();

  if (!email) {
    return NextResponse.json(
      { error: 'Email is required' },
      { status: 400 }
    );
  }

  try {
    // Run format check and disposable check in parallel
    const [formatRes, dispRes] = await Promise.all([
      fetch(\`\${API_BASE}/email/validate\`, {
        method: 'POST',
        headers,
        body: JSON.stringify({ email }),
        signal: AbortSignal.timeout(3000),
      }),
      fetch(\`\${API_BASE}/disposable-email/check\`, {
        method: 'POST',
        headers,
        body: JSON.stringify({ email }),
        signal: AbortSignal.timeout(3000),
      }),
    ]);

    const [formatData, dispData] = await Promise.all([
      formatRes.json(),
      dispRes.json(),
    ]);

    if (formatData.success && !formatData.data.format_valid) {
      return NextResponse.json(
        { valid: false, reason: 'Invalid email format' },
        { status: 422 }
      );
    }

    if (dispData.success && dispData.data.is_disposable) {
      return NextResponse.json(
        { valid: false, reason: 'Disposable emails are not allowed' },
        { status: 422 }
      );
    }

    // Then check MX records
    const mxRes = await fetch(\`\${API_BASE}/email-mx/verify\`, {
      method: 'POST',
      headers,
      body: JSON.stringify({ email }),
      signal: AbortSignal.timeout(3000),
    });
    const mxData = await mxRes.json();

    if (mxData.success && !mxData.data.has_mx) {
      return NextResponse.json(
        { valid: false, reason: 'Email domain has no mail server' },
        { status: 422 }
      );
    }

    return NextResponse.json({ valid: true });
  } catch {
    // Fail open on API errors
    return NextResponse.json({ valid: true });
  }
}

Rufen Sie diese Route über Ihr Anmeldeformular auf onBlur handler to validate the email before the user submits. Die Parallele Promise.all Hält die Antwortzeit für die meisten Anfragen unter 200 ms.

Umgang mit Randfällen

Drei Muster bringen naive Validatoren zum Stolpern:

Catch-All-Domains

Einige Domains akzeptieren E-Mails an jede beliebige Adresse. anything@catch-all-domain.com wird nicht hüpfen, aber das Postfach ist möglicherweise nicht vorhanden. Die MX-Prüfung bestätigt, dass die Domain über einen Mailserver verfügt. Zur Bestätigung des spezifischen Postfachs ist das Versenden einer E-Mail erforderlich, was bei diesem Ansatz absichtlich vermieden wird. Für die meisten Anmeldeabläufe reicht eine Überprüfung auf Domänenebene aus.

Rollenbasierte Adressen

Adressen wie admin@, info@, Und support@ sind gemeinsame Posteingänge. Sie sind gültig, aber sie sind schlechte Kandidaten für den Besitz eines Kontos, da keine einzelne Person sie kontrolliert. Die API kennzeichnet diese mit is_role: true. Sie können den Benutzer je nach den Anforderungen Ihres Produkts warnen oder die Anmeldung blockieren.

Plus Adressierung

user+tag@gmail.com liefert an user@gmail.com. Dies ist eine legitime Funktion, kein Missbrauch. Aber es ermöglicht einer Person, viele Konten mit demselben Postfach zu erstellen. Wenn Sie dies verhindern möchten, entfernen Sie die + Suffix vor der Validierung und speichern Sie die normalisierte Adresse.

Hier ist eine Funktion, die alle drei verarbeitet:

async function validateEmailStrict(email: string): Promise<{
  valid: boolean;
  warnings: string[];
  reason: string | null;
}> {
  const warnings: string[] = [];

  // Check for plus addressing (user+tag@gmail.com)
  const localPart = email.split('@')[0];
  if (localPart.includes('+')) {
    warnings.push('plus_addressing');
  }

  const res = await fetch('https://api.botoi.com/v1/email/validate', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'Authorization': \`Bearer \${process.env.BOTOI_API_KEY}\`,
    },
    body: JSON.stringify({ email }),
    signal: AbortSignal.timeout(3000),
  });

  const data = await res.json();

  if (!data.success) {
    return { valid: false, warnings, reason: 'api_error' };
  }

  // Flag role-based addresses (admin@, info@, support@)
  if (data.data.is_role) {
    warnings.push('role_based_address');
  }

  // Reject disposable providers
  if (data.data.is_disposable) {
    return { valid: false, warnings, reason: 'disposable_provider' };
  }

  // Reject domains with no MX records
  if (!data.data.is_valid && data.data.reason === 'no_mx_records') {
    return { valid: false, warnings, reason: 'no_mx_records' };
  }

  return { valid: data.data.is_valid, warnings, reason: null };
}

const result = await validateEmailStrict('admin+test@example.com');
// {
//   valid: true,
//   warnings: ['plus_addressing', 'role_based_address'],
//   reason: null
// }

NPM-Pakete vs. API-Ansatz

Der npm-Paketansatz fügt die Validierungslogik und ihre Daten (Domänenlisten, Regex-Muster) in Ihre Codebasis ein. Sie besitzen die Updates. Wenn ein neuer Einweganbieter startet, muss jemand eine PR öffnen, um ihn hinzuzufügen. Der API-Ansatz entlastet diese Wartung. The domain list updates server-side. Ihr Code bleibt gleich.

Der Nachteil: Eine API fügt eine Netzwerkabhängigkeit hinzu. Das in den Express- und Next.js-Beispielen gezeigte Fail-Open-Muster kümmert sich darum. Wenn die API ausfällt, ist die Validierung erfolgreich und Sie verlassen sich auf Ihre anderen Anmeldeschutzmaßnahmen (E-Mail-Bestätigung, Ratenbegrenzung). bis die API wiederhergestellt ist.