Sendkit TeamCómo validar direcciones de email antes de enviar
Aprende a validar direcciones de email con verificaciones de sintaxis, búsquedas MX, detección de desechables y verificación SMTP para reducir rebotes y proteger tu reputación.

Cada email rebotado desgasta tu reputación como remitente. Envía suficientes y los proveedores de buzón empiezan a limitarte, a enviar tus mensajes a spam o a bloquearte por completo. La solución es directa: valida las direcciones de email antes de enviar cualquier cosa.
Esta guía desglosa cada capa de la validación de email, te muestra cómo implementarlas y recorre código real usando la API de validación de email de Sendkit.
Por qué importa la validación
Tres cosas pasan cuando envías a direcciones malas.
Tu tasa de rebote sube. Los ISP rastrean tu ratio de rebote. Cualquier cosa por encima del 2% es una señal de alarma. Si llegas al 5% constantemente, estás en problemas serios. Los rebotes duros (fallos permanentes) son los que más duelen porque indican que no estás manteniendo tu lista.
Tu reputación como remitente cae. Proveedores de buzón como Gmail y Outlook asignan puntajes de reputación a dominios e IPs de envío. Las tasas de rebote altas, las quejas de spam y los impactos en spam traps bajan ese puntaje. Una vez que se hunde, incluso tus emails legítimos caen en spam.
Desperdicias dinero. Todo ESP cobra por email enviado. Enviar a direcciones que nunca abrirán, harán clic o convertirán es tirar el dinero. Si estás en un plan de email transaccional, las direcciones malas consumen tu cuota sin devolverte nada.
La validación no es higiene opcional. Es infraestructura.
Las capas de la validación de email
Un solo regex no es suficiente. La validación adecuada es una pila de verificaciones, cada una atrapando problemas que la capa anterior se pierde.
Validación de sintaxis
La verificación más básica: ¿la dirección sigue las reglas definidas en RFC 5321 y RFC 5322? Necesitas una parte local, un símbolo @ y un dominio.
La mayoría de los desarrolladores recurren a regex aquí. Eso funciona para atrapar basura obvia como not-an-email o user@@domain.com. Pero las direcciones de email que cumplen con el RFC son sorprendentemente complejas. Cadenas entrecomilladas, comentarios y nombres de dominio internacionalizados hacen que un regex completo sea casi imposible de acertar.
Una buena verificación de sintaxis atrapa los errores obvios. No intentes hacer que los atrape todos.
const isValidSyntax = email => {
const pattern = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
return pattern.test(email);
};
// catches the basics
isValidSyntax('[email protected]'); // true
isValidSyntax('broken@@example.com'); // false
isValidSyntax('no-domain@'); // falseEste es tu primer filtro, no el último.
Verificaciones de DNS y registros MX
Una dirección puede verse sintácticamente válida y aun así no ser entregable. El dominio podría no existir, o podría no tener registros de intercambio de correo (MX) configurados.
Una búsqueda MX consulta al DNS por los servidores de correo responsables de un dominio. Sin registros MX, nadie está aceptando email allí.
import { promises as dns } from 'dns';
const hasMxRecords = async email => {
const domain = email.split('@')[1];
try {
const records = await dns.resolveMx(domain);
return records.length > 0;
} catch {
return false;
}
};
await hasMxRecords('[email protected]'); // true (assuming MX exists)
await hasMxRecords('[email protected]'); // falseEsto atrapa errores tipográficos en dominios (gmial.com en lugar de gmail.com) y dominios completamente inventados.
Detección de email desechable
Servicios de email desechable como Mailinator, Guerrilla Mail y Temp Mail dan a los usuarios direcciones de usar y tirar. La gente los usa para saltarse formularios de registro, obtener trials gratis o evitar emails de marketing.
Estas direcciones funcionan temporalmente pero mueren en horas o días. Enviarles desperdicia recursos y distorsiona tus métricas de engagement.
La detección depende de mantener una lista de proveedores de email desechable conocidos. Hay miles de ellos. Mantener esa lista actualizada es una carga de mantenimiento que probablemente no quieres asumir. Aquí es donde un servicio API se gana su lugar.
Verificación de buzón (verificación SMTP)
Esta es la verificación más profunda. Una verificación SMTP se conecta al servidor de correo del destinatario y recorre el handshake SMTP hasta el comando RCPT TO sin enviar realmente un mensaje. Si el servidor rechaza al destinatario, el buzón no existe.
Hay advertencias. Algunos servidores aceptan todas las direcciones durante el handshake y rebotan más tarde (dominios catch-all). Otros limitan o bloquean los intentos de verificación. No deberías ejecutar verificaciones SMTP desde tu propia infraestructura porque puede llevarte a la lista negra.
Esta verificación la maneja mejor un servicio que mantiene un pool de IPs y entiende las peculiaridades de distintos servidores de correo.
Detección de direcciones basadas en rol
Direcciones como admin@, info@, support@ y sales@ están basadas en rol. Típicamente reenvían a un grupo de personas o a un buzón compartido. No son inherentemente inválidas, pero conllevan mayor riesgo:
- Mayores tasas de queja porque varias personas leen el buzón
- Menor engagement porque nadie siente propiedad personal
- Algunas se usan como spam traps por organizaciones que prueban el comportamiento del remitente
Marcar las direcciones basadas en rol te permite decidir cómo manejarlas en lugar de tratarlas como direcciones personales.

Validando con la API de Sendkit
Puedes apilar todas estas verificaciones tú mismo, o puedes hacer una sola llamada a la API. El endpoint de validación de email de Sendkit ejecuta verificaciones de sintaxis, DNS, desechables, SMTP y basadas en rol en una sola request y devuelve un resultado estructurado.
Validación de un solo email
const validateEmail = async email => {
const response = await fetch('https://api.sendkit.com/v1/email/validate', {
method: 'POST',
headers: {
Authorization: 'Bearer sk_live_your_api_key',
'Content-Type': 'application/json',
},
body: JSON.stringify({ email }),
});
return response.json();
};
const result = await validateEmail('[email protected]');
console.log(result);
// {
// "valid": true,
// "disposable": false,
// "mx_found": true,
// "role_based": false,
// "reason": "accepted_email"
// }La respuesta te dice todo lo que necesitas para tomar una decisión. valid es el veredicto general. Los otros campos te dan control granular sobre qué tan estricto quieres ser.
Validación en lote
Limpiar una lista existente significa validar miles o millones de direcciones. Hacerlo una por una es lento. El procesamiento en lote te permite enviar una lista y recibir resultados en bulk.
const validateBatch = async emails => {
const results = await Promise.allSettled(
emails.map(email =>
fetch('https://api.sendkit.com/v1/email/validate', {
method: 'POST',
headers: {
Authorization: 'Bearer sk_live_your_api_key',
'Content-Type': 'application/json',
},
body: JSON.stringify({ email }),
}).then(res => res.json())
)
);
return results.map((r, i) => ({
email: emails[i],
...(r.status === 'fulfilled' ? r.value : { valid: false, reason: 'request_failed' }),
}));
};
const emails = ['[email protected]', '[email protected]', '[email protected]'];
const results = await validateBatch(emails);Para listas grandes, añade control de concurrencia. Bombardear la API con 100,000 requests simultáneas no va a terminar bien. Un limitador simple de concurrencia mantiene todo fluido:
const validateWithConcurrency = async (emails, concurrency = 10) => {
const results = [];
const queue = [...emails];
const worker = async () => {
while (queue.length > 0) {
const email = queue.shift();
const result = await validateEmail(email);
results.push({ email, ...result });
}
};
const workers = Array.from({ length: concurrency }, () => worker());
await Promise.all(workers);
return results;
};Integración en un formulario de registro
El lugar de mayor valor para validar es el punto de recolección. Atrapa las direcciones malas antes de que entren a tu base de datos.
Aquí hay un ejemplo práctico para un backend Node.js manejando envíos de formulario:
import express from 'express';
const app = express();
app.use(express.json());
const validateEmail = async email => {
const response = await fetch('https://api.sendkit.com/v1/email/validate', {
method: 'POST',
headers: {
Authorization: `Bearer ${process.env.SENDKIT_API_KEY}`,
'Content-Type': 'application/json',
},
body: JSON.stringify({ email }),
});
return response.json();
};
app.post('/signup', async (req, res) => {
const { email, name } = req.body;
const validation = await validateEmail(email);
if (!validation.valid) {
return res.status(400).json({
error: 'Invalid email address',
reason: validation.reason,
});
}
if (validation.disposable) {
return res.status(400).json({
error: 'Disposable email addresses are not allowed',
});
}
if (validation.role_based) {
// allow but flag for review
console.warn(`Role-based email signup: ${email}`);
}
// proceed with account creation
// ...
return res.status(201).json({ message: 'Account created' });
});Esto atrapa las direcciones malas en la puerta. Los usuarios reciben feedback inmediato. Tu base de datos se mantiene limpia.
Qué hacer con los resultados de la validación
No todo resultado es un aceptar/rechazar binario. Construye una matriz de decisión:
Aceptar cuando valid es true, disposable es false y role_based es false. Esta es una dirección personal limpia. Envía sin problema.
Rechazar cuando valid es false. La dirección no es entregable. No envíes. Si esto es un formulario de registro, pide al usuario que pruebe con otra dirección.
Rechazar cuando disposable es true. Estas direcciones son temporales. Para apps transaccionales puede no importar, pero para cualquier cosa que requiera comunicación continua, bloquéalas.
Marcar para revisión cuando role_based es true. La dirección funciona, pero conlleva riesgo. Podrías aceptarla para email transaccional pero excluirla de las campañas de marketing.
const categorizeResult = result => {
if (!result.valid) return 'reject';
if (result.disposable) return 'reject';
if (result.role_based) return 'review';
return 'accept';
};Mantenlo simple. Tres cubetas. Automatiza las dos primeras, revisa manualmente la tercera.

Validación en tiempo real vs limpieza en lote
No son enfoques en competencia. Necesitas ambos.
La validación en tiempo real en el punto de entrada (formularios de registro, páginas de checkout, formularios de contacto) evita que los datos malos entren a tu sistema. Es proactiva. El costo en latencia es mínimo ya que una sola llamada a la API añade tal vez 200-500ms, que es invisible para los usuarios cuando validas en el blur en lugar del submit.
La limpieza en lote maneja las direcciones ya en tu base de datos. Las listas se degradan a aproximadamente 2-3% por mes. La gente cambia de trabajo, abandona buzones, los dominios expiran. Ejecuta validación en lote trimestralmente como mínimo, mensualmente si estás enviando alto volumen.
Un enfoque sólido se ve así:
- Valida cada dirección en la recolección en tiempo real
- Revalida tu lista completa en un calendario mensual
- Suprime cualquier dirección que falle la revalidación
- Monitorea las tasas de rebote después de los envíos y alimenta esos datos de vuelta a tu lista de supresión
Los dos enfoques se refuerzan entre sí. El tiempo real mantiene la puerta de entrada limpia. La limpieza en lote maneja la decadencia inevitable.
Cerrando
La validación de email no es un lujo. Cada dirección en tu lista que no puede recibir correo está dañando activamente tu entregabilidad. La solución es validación por capas: sintaxis, DNS, detección de desechables, verificación SMTP y verificaciones basadas en rol.
Puedes construir partes de esto tú mismo, pero las capas de verificación SMTP y detección de desechables son genuinamente difíciles de mantener. Una API maneja la complejidad y se mantiene actualizada a medida que los proveedores de desechables se multiplican y los comportamientos de los servidores de correo cambian.
Valida en el punto de recolección. Limpia tus listas existentes regularmente. Actúa sobre los resultados con reglas claras. Tus tasas de rebote bajarán, tu reputación como remitente se mantendrá y tus emails realmente llegarán a la gente a la que intentas llegar.
Compartir este artículo