Comment valider les emails dans Node.js sans installer de package

Intégration Node.js : voie d'inscription express

Voici un gestionnaire de route Express complet qui valide l'e-mail lors du POST /signup en utilisant la récupération native. Le modèle d'ouverture en cas d'échec garantit qu'une panne de Botoi ne bloque jamais les véritables inscriptions :

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);

La route rejette les emails invalides avec un 422 et le spécifique reason de l'API. Si l'API est inaccessible, l'inscription se poursuit. Vous échangez un chèque manqué contre un flux d’utilisateurs ininterrompu.

Validation à trois niveaux

La /v1/email/validate le point final couvre les bases. Pour une vérification approfondie, combinez trois points finaux :

• /v1/email/validate pour la syntaxe et le format
• /v1/email-mx/verify pour la vérification des enregistrements MX
• /v1/disposable-email/check pour la détection jetable

Cette fonction d'assistance appelle les trois et renvoie un résultat structuré :

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;
}

Utilisez-le comme ceci :

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

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

Chaque couche détecte une classe différente de mauvais e-mails. Les vérifications de format arrêtent la saisie inutile. Les contrôles MX arrêtent les domaines inventés. Les chèques jetables empêchent les inscriptions jetables. Ensemble, ils comblent le vide que les regex laissent ouvert.

Ajout à une route API Next.js

La même logique fonctionne dans un gestionnaire de route Next.js App Router à app/api/validate-email/route.ts. Cette version exécute la vérification du format et la vérification jetable en parallèle pour réduire la latence :

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 });
  }
}

Appelez cet itinéraire à partir de votre formulaire d'inscription onBlur gestionnaire pour valider l’e-mail avant que l’utilisateur ne le soumette. Le parallèle Promise.all maintient le temps de réponse inférieur à 200 ms pour la plupart des demandes.

Gestion des cas extrêmes

Trois modèles font trébucher les validateurs naïfs :

Domaines fourre-tout

Certains domaines acceptent les e-mails à n'importe quelle adresse. anything@catch-all-domain.com ne rebondira pas, mais la boîte aux lettres n'existe peut-être pas. La vérification MX confirme que le domaine dispose d'un serveur de messagerie. La confirmation de la boîte aux lettres spécifique nécessite l'envoi d'un e-mail, ce que cette approche évite volontairement. Pour la plupart des flux d’inscription, la vérification au niveau du domaine suffit.

Adresses basées sur les rôles

Des adresses comme admin@, info@, et support@ sont des boîtes de réception partagées. Ils sont valides, mais ce sont de mauvais candidats à la possession d’un compte car aucune personne ne les contrôle. L'API les signale avec is_role: true. Vous pouvez avertir l'utilisateur ou bloquer l'inscription en fonction des besoins de votre produit.

Plus l'adressage

user+tag@gmail.com livre à user@gmail.com. Il s'agit d'une fonctionnalité légitime et non d'un abus. Mais cela permet à une personne de créer plusieurs comptes avec la même boîte aux lettres. Si vous souhaitez éviter cela, retirez le + suffixe avant validation et stocke l’adresse normalisée.

Voici une fonction qui gère les trois :

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
// }

Packages npm par rapport à l'approche API

L'approche du package npm place la logique de validation et ses données (listes de domaines, modèles d'expression régulière) dans votre base de code. Vous êtes propriétaire des mises à jour. Lorsqu'un nouveau fournisseur de produits jetables est lancé, quelqu'un doit ouvrir un PR pour l'ajouter. L’approche API décharge cette maintenance. La liste des domaines est mise à jour côté serveur. Votre code reste le même.

Le compromis : une API ajoute une dépendance réseau. Le modèle d'échec d'ouverture présenté dans les exemples Express et Next.js gère cela. Si l'API est en panne, la validation réussit et vous comptez sur vos autres protections d'inscription (confirmation par e-mail, limitation du débit) jusqu'à ce que l'API récupère.