Cómo validar correos electrónicos en Node.js sin instalar un paquete

Integración de Node.js: ruta de registro exprés

Aquí hay un controlador de ruta Express completo que valida el correo electrónico en POST /signup utilizando la recuperación nativa. El patrón de apertura fallida garantiza que una interrupción del botoi nunca bloquee los registros reales:

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 ruta rechaza correos electrónicos no válidos con un 422 y el específico reason desde la API. Si no se puede acceder a la API, se continúa con el registro. Cambia un cheque perdido por un flujo de usuarios ininterrumpido.

Three-layer validation

La /v1/email/validate El punto final cubre los conceptos básicos. Para una verificación exhaustiva, combine tres puntos finales:

• /v1/email/validate para sintaxis y formato
• /v1/email-mx/verify para verificación de registros MX
• /v1/disposable-email/check para detección desechable

Esta función auxiliar llama a los tres y devuelve un resultado estructurado:

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

Úselo así:

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

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

Cada capa detecta una clase diferente de correo electrónico incorrecto. Las comprobaciones de formato detienen la entrada de basura. Los controles MX detienen los dominios inventados. Los cheques desechables evitan los registros desechables. Juntos, cubren el espacio que las expresiones regulares dejan abierto.

Agregar a una ruta API Next.js

La misma lógica funciona en un controlador de ruta de Next.js App Router en app/api/validate-email/route.ts. Esta versión ejecuta la verificación de formato y la verificación desechable en paralelo para reducir la latencia:

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

Llame a esta ruta desde su formulario de registro onBlur controlador para validar el correo electrónico antes de que el usuario lo envíe. el paralelo Promise.all mantiene el tiempo de respuesta por debajo de 200 ms para la mayoría de las solicitudes.

Manejo de casos extremos

Tres patrones hacen tropezar a los validadores ingenuos:

Dominios generales

Algunos dominios aceptan correo electrónico en cualquier dirección. anything@catch-all-domain.com no rebotará, pero es posible que el buzón no exista. La verificación MX confirma que el dominio tiene un servidor de correo. Para confirmar el buzón específico es necesario enviar un correo electrónico, lo que este método evita intencionadamente. Para la mayoría de los flujos de registro, la verificación a nivel de dominio es suficiente.

Direcciones basadas en roles

Direcciones como admin@, info@, y support@ son bandejas de entrada compartidas. Son válidos, pero no son buenos candidatos para ser propietarios de una cuenta porque ninguna persona los controla. La API los marca con is_role: true. Puede advertir al usuario o bloquear el registro según las necesidades de su producto.

Más direccionamiento

user+tag@gmail.com entrega a user@gmail.com. Esta es una característica legítima, no un abuso. Pero permite que una persona cree muchas cuentas con el mismo buzón. Si quiere evitar esto, quite el + sufijo antes de la validación y almacenar la dirección normalizada.

Aquí hay una función que maneja los tres:

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

Paquetes npm versus enfoque API

El enfoque del paquete npm coloca la lógica de validación y sus datos (listas de dominios, patrones de expresiones regulares) en su código base. Eres dueño de las actualizaciones. Cuando se lanza un nuevo proveedor desechable, alguien debe abrir un PR para agregarlo. El enfoque API descarga ese mantenimiento. La lista de dominios se actualiza en el lado del servidor. Tu código sigue siendo el mismo.

La compensación: una API agrega una dependencia de la red. El patrón de apertura fallida que se muestra en los ejemplos de Express y Next.js maneja esto. Si la API no funciona, la validación pasa y usted confía en sus otras protecciones de registro (confirmación por correo electrónico, limitación de velocidad) hasta que la API se recupere.