Domain Intelligence

Lista de proveedores de correo desechable (2026) para la validación de datos B2B

blureshot marzo 28, 2026 15 min de lectura 658 visitas
disposable email providers list 2024 - Mastering Lead Quality: The Definitive Disposable Email Providers List 2024 for B2B Data Validation
disposable email providers list 2024 - Mastering Lead Quality: The Definitive Disposable Email Providers List 2024 for B2B Data Validation

Las direcciones de correo desechables existen por un motivo legítimo — nadie quiere entregar una identidad permanente a cada formulario de internet — y generan un problema operativo real para cualquiera que mantenga una base de datos de contactos. Esta guía explica qué son los proveedores de correo desechable, cómo funciona realmente la detección, por qué mantener una lista estática es el más débil de los métodos disponibles y cómo construir un enfoque de detección que siga funcionando a medida que aparecen nuevos proveedores.

TL;DR / IDEAS CLAVE

  • Una dirección desechable es un buzón real y entregable con una vida corta. Normalmente supera las comprobaciones de sintaxis, las de MX y la verificación SMTP, y por eso la validación de correo genérica no la detecta.
  • Las listas de dominios se quedan obsoletas muy rápido. Los proveedores rotan cientos o miles de dominios alias, y cualquier lista mantenida a mano queda desactualizada en cuestión de semanas.
  • El registro MX es la señal más duradera. Los dominios alias cambian constantemente; los servidores de correo que hay detrás cambian mucho menos, así que clasificar por MX detecta dominios que todavía no aparecen en ninguna lista.
  • Las listas de código abierto son el punto de partida correcto, no la meta: los repositorios mantenidos por la comunidad ofrecen una cobertura amplia de forma gratuita y se actualizan de forma continua.
  • Bloquear es una decisión de producto, no una decisión de datos. Bloquear sin más los dominios desechables en el registro también bloquea a usuarios legítimos preocupados por su privacidad. Puntuar y restringir suele ser mejor que rechazar.
  • Dónde ayudan los datos de zona: los paquetes de zona enriquecidos incluyen el registro MX de cada dominio, lo que permite encontrar todos los dominios de un TLD que comparten infraestructura de correo con un proveedor desechable conocido.
  • Qué contienen los paquetes: El formato de descarga depende del paquete y se indica en la página del producto. Sin direcciones de correo ni datos de contacto personales de ningún tipo.

Índice


Qué son los proveedores de correo desechable y por qué las listas se quedan obsoletas

Una dirección de correo desechable — también llamada temporal, de usar y tirar o burner — es un buzón que un servicio crea bajo demanda, normalmente sin registro, y descarta al cabo de minutos o días. El usuario obtiene una bandeja de entrada en el navegador, recibe el correo de confirmación y no vuelve nunca. Algunos proveedores ofrecen bandejas públicas en las que cualquier dirección del dominio puede leerla quien acierte con ella; otros generan alias privados que reenvían a un buzón real que el destinatario ya posee.

El detalle crítico para quien escribe código de validación es que se trata de buzones reales y operativos. El dominio tiene registros MX válidos, el servidor de correo acepta el correo dirigido a esa dirección y el intercambio de verificación SMTP se completa con éxito. La validación de sintaxis pasa, la validación DNS pasa y las comprobaciones de existencia del buzón pasan. Nada del conjunto de herramientas de validación estándar distingue una dirección desechable de una permanente, porque a nivel de protocolo no hay diferencia. Por tanto, la detección consiste en identificar al proveedor, no en probar la dirección.

Ahí está la dificultad. Un único servicio de correo desechable opera normalmente desde decenas hasta miles de dominios alias, que existen precisamente para que el bloqueo a nivel de dominio no funcione. Los dominios rotan, se retiran cuando aparecen en listas de bloqueo públicas y se sustituyen por otros recién registrados. Una lista que compilaste a mano hace tres meses ya no incluye los dominios registrados desde entonces, y los proveedores saben perfectamente cómo se compilan esas listas.

También conviene ser preciso sobre la magnitud del problema en lugar de repetir un porcentaje llamativo. La prevalencia de direcciones desechables varía enormemente según el producto: una app de consumo que ofrece una recompensa inmediata al registrarse presenta una tasa completamente distinta de la de una herramienta B2B que exige un correo corporativo y una demo programada. Mide tu propia tasa antes de diseñar una respuesta. Cualquier cifra citada sin fuente ni metodología — incluidas las que aparecen en artículos sobre este tema — debe tomarse como mera decoración.

¿Necesitas datos MX de un TLD completo?
Los paquetes de zona enriquecidos incluyen el registro MX de cada dominio de la zona.
Ver datasets → | Ver precios →


Métodos de detección, ordenados por durabilidad

Los enfoques de detección varían mucho en su capacidad de resistir el contacto con un proveedor que trata activamente de eludirlos. Aproximadamente, en orden de durabilidad:

1. Clasificación basada en MX (la más duradera)

Los dominios alias son baratos y prescindibles; la infraestructura de correo no lo es. Un proveedor que gestiona dos mil dominios suele apuntarlos todos al mismo puñado de servidores de correo. Si resuelves el registro MX del dominio de la dirección y comparas ese servidor de correo con la infraestructura de correo desechable conocida, detectas dominios registrados esta misma mañana que no aparecen en ninguna lista.

Es el método en el que más merece la pena invertir, y es el que los datos de zona enriquecidos respaldan directamente, ya que el MX es una columna del archivo. El proceso de construcción se describe en la siguiente sección.

2. Listas de código abierto mantenidas por la comunidad

Varios repositorios públicos siguen la pista de los dominios desechables y aceptan contribuciones continuas: el proyecto disposable-email-domains, muy utilizado, es el punto de partida habitual, y la mayoría de los validadores comerciales se nutren de fuentes similares. La cobertura es amplia, el precio es cero y actualizar consiste en un git pull. La debilidad es intrínseca: una lista siempre va por detrás de los dominios más nuevos, y un dominio que ha dejado de ser desechable rara vez se elimina.

Úsala como base y espera que capture la cola larga de proveedores conocidos, no los recién creados.

3. API comerciales de validación

Los validadores de pago combinan la coincidencia con listas, la clasificación por MX, el sondeo SMTP y las señales de comportamiento del tráfico de toda su base de clientes; esta última entrada es la que no puedes replicar. Son la opción pragmática para filtrar registros en tiempo real cuando necesitas una respuesta en cien milisegundos y no quieres mantener el pipeline por tu cuenta. Los costes escalan por comprobación y la clasificación de cada proveedor difiere en los casos límite, así que prueba dos con la misma muestra antes de decidirte.

4. Heurísticas de registro e infraestructura

Débiles por separado, útiles en conjunto. Un dominio registrado hace unos días, que resuelve a una red de hosting llena de sitios efímeros, sin contenido web y con servidores de nombres genéricos, tiene más probabilidades de ser infraestructura de usar y tirar que un dominio de quince años con un sitio real detrás. Trátalas como entradas de una puntuación, nunca como regla de rechazo por sí solas: todo negocio legítimo recién creado también tiene un dominio registrado hace unos días.

5. Listas de bloqueo de dominios estáticas mantenidas a mano (las menos duraderas)

El enfoque por defecto y el que antes falla. Se añade algo cuando un compañero detecta un rebote; nunca se elimina nada; nadie se hace cargo del archivo. En unos meses es más una pieza de museo que un control. Si este es tu enfoque actual, sustituirlo por una lista de código abierto que se actualice automáticamente es el cambio de mayor valor disponible.

Una nota sobre qué hacer con un resultado positivo

Detección y política son decisiones distintas. Bloquear sin más todos los dominios desechables en el registro también ahuyenta a usuarios preocupados por su privacidad que habrían convertido, y hay muchos. Puntos intermedios habituales: permitir el registro pero retener las acciones irreversibles hasta que se confirme una dirección; exigir verificación antes de ampliar una prueba; dejar pasar los registros con dominio desechable pero excluirlos de las campañas de recaptación de pago. Para las listas de prospección B2B el cálculo es más sencillo: una dirección desechable rebotará o nunca se leerá, así que eliminarla antes de enviar protege la entregabilidad sin ninguna desventaja real.


Una lista inicial de proveedores conocidos

Estos son servicios de correo desechable veteranos y ampliamente conocidos. Es un punto de partida para probar tu lógica de detección, no una lista de bloqueo exhaustiva: cada uno de ellos opera dominios alias adicionales y aparecen proveedores nuevos continuamente.

Proveedor Modelo Nota de detección
Mailinator Bandeja pública, cualquier dirección del dominio Muchos dominios alias, infraestructura MX compartida
Guerrilla Mail Bandeja temporal, por sesión Varios dominios rotativos, incluido sharklasers.com
10 Minute Mail Bandeja con caducidad automática Dominios efímeros, servidores de correo constantes
YOPmail Bandeja pública, sin registro Amplio conjunto de dominios alias publicado
Temp-Mail Bandeja temporal con dominios rotativos El conjunto de dominios cambia con frecuencia; el MX es mucho más estable
Maildrop Bandeja pública Pocos dominios, fácil de identificar
Dispostable Bandeja pública Dominio principal estable
Servicios de alias con reenvío Alias privado que reenvía a un buzón real Entregables y a menudo permanentes: clasifícalos aparte

Esa última fila importa más de lo que parece. Los servicios de alias con reenvío los usan mucho personas preocupadas por su privacidad que sí quieren recibir el correo, y la dirección suele seguir funcionando durante años. Meterlos en el mismo saco que las bandejas públicas de usar y tirar te costará usuarios reales. Dales su propia categoría y su propia política.


Cómo crear un conjunto de detección basado en MX a partir de datos de zona

El objetivo es una lista de servidores de correo asociados a proveedores desechables, más todos los dominios de una zona que apunten a ellos. Ese conjunto es mucho más duradero que una lista de dominios porque sobrevive a la rotación de alias.

Paso 1 — Consigue datos MX de las zonas que te interesan. Los paquetes de zona enriquecidos incluyen el registro MX de cada dominio. Consulta /zones/ para los 716 archivos de zona por TLD y sus versiones enriquecidas, con el número de filas visible antes de la compra, y /datasets/ para las 27 colecciones seleccionadas entre zonas. El catálogo completo de 1,538 paquetes está en /packages/. Los paquetes empiezan en $3.50 y se descargan al instante en formato ZIP, exportados en el momento de la compra. Pro cuesta $29/mes (50 paquetes, 10 datasets, 30,000 llamadas API); Enterprise cuesta $99/mes (200 paquetes, 50 datasets, 300,000 llamadas API); consulta /pricing/.

Paso 2 — Descomprime y revisa el esquema.

unzip com-enriched.zip
head -3 com-enriched.csv
# domain,ns,mx,ip,cms

Paso 3 — Parte de dominios de proveedores conocidos. Empieza con una lista de dominios desechables de código abierto y con la tabla anterior, y guarda los dominios en un archivo:

curl -sL https://raw.githubusercontent.com/disposable-email-domains/disposable-email-domains/master/disposable_email_blocklist.conf \
  > seed-domains.txt
wc -l seed-domains.txt

Paso 4 — Extrae los servidores de correo que usan esos dominios. Cruza la lista inicial con el archivo de zona para recopilar los valores MX, que se convierten en tu huella de infraestructura:

-- mail hosts used by known disposable domains, most common first
SELECT z.mx, count(*) AS domains
FROM read_csv_auto('com-enriched.csv') z
JOIN read_csv_auto('seed-domains.txt', header=false, columns={'domain':'VARCHAR'}) s
  ON z.domain = s.domain
WHERE z.mx IS NOT NULL AND z.mx <> ''
GROUP BY z.mx
ORDER BY domains DESC;

Paso 5 — Expande de nuevo a todos los dominios que comparten esa infraestructura. Este es el paso que encuentra lo que ninguna lista tiene todavía:

-- all domains in the zone pointing at a known disposable mail host
SELECT domain, mx
FROM read_csv_auto('com-enriched.csv')
WHERE mx IN (SELECT mx FROM disposable_mx_hosts);

Paso 6 — Revisa antes de desplegar. No pongas el resultado en producción sin examinarlo. Algunos servidores de correo dan servicio tanto a dominios desechables como legítimos, y una plataforma compartida producirá falsos positivos que te costarán registros reales. Ordena el resultado por servidor MX, revisa manualmente los grupos más grandes y añade un servidor al conjunto de bloqueo solo cuando sus dominios sean sistemáticamente de usar y tirar.

Paso 7 — Actualiza con una periodicidad fija. Vuelve a comprar el mismo paquete cada cierto tiempo y ejecuta de nuevo el pipeline. Aparecen nuevos dominios alias que apuntan a servidores de correo que ya conoces, y comparar instantáneas los saca a la luz sin ningún trabajo manual.

# list zone-file packages
curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://webtrackly.com/api/v1/packages/?type=zone"

# technology packages matching a keyword
curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://webtrackly.com/api/v1/packages/?type=technology&q=wordpress"

# details for one package
curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://webtrackly.com/api/v1/packages/com-zone/"

La API expone el catálogo de paquetes para que todo esto pueda ejecutarse de forma desatendida; la referencia está en /api/. No es un endpoint de validación de correo ni un servicio de consulta de dominios: la lógica de clasificación se queda en tu pipeline, donde puedes ajustarla.


Errores habituales en la validación de correo

  1. Depender de una lista de dominios mantenida a mano.

    • Qué falla: La detección se degrada en silencio a medida que los proveedores rotan dominios, y nadie se da cuenta hasta que suben las tasas de rebote.
    • La solución: Automatiza las actualizaciones desde una lista de código abierto mantenida y añade clasificación por MX para detectar los nuevos dominios alias en el primer contacto.
  2. Confundir la verificación SMTP con la detección de direcciones desechables.

    • Qué falla: El intercambio se completa con éxito — el buzón existe de verdad — y la dirección se marca como válida.
    • La solución: Asume que entregabilidad y permanencia son propiedades distintas. Además, un sondeo SMTP agresivo hace que tu IP acabe en greylisting: un segundo coste sin ningún beneficio.
  3. Bloquear directamente los dominios desechables en el registro.

    • Qué falla: Se ahuyenta a usuarios legítimos preocupados por su privacidad, mientras que los abusadores decididos simplemente usan el siguiente dominio.
    • La solución: Puntúa en lugar de rechazar. Restringe las acciones que de verdad te cuestan dinero — operaciones irreversibles, ampliaciones de prueba, envíos salientes — en vez de la cuenta en sí.
  4. Confundir el correo web gratuito con el correo desechable.

    • Qué falla: Los grandes proveedores de correo de consumo acaban en la lista de bloqueo y se rechaza una parte importante de los clientes reales.
    • La solución: Mantén tres categorías distintas — desechable, correo web gratuito de consumo y corporativo — con tres políticas distintas. Una dirección de consumo puede ser una señal B2B débil, pero no es una señal falsa.
  5. Dar por válidos los dominios catch-all.

    • Qué falla: Un servidor catch-all acepta correo para cualquier dirección, así que la verificación devuelve "válido" para direcciones que no existen y el correo se descarta en silencio.
    • La solución: Marca los catch-all por separado como "no verificables" y decide la política de forma explícita, en lugar de dejar que se escondan dentro del recuento de direcciones válidas.
  6. Validar una vez y nunca más.

    • Qué falla: Las direcciones se degradan — la gente cambia de trabajo, los dominios caducan, los buzones se cierran — y una lista validada hace un año no es una lista validada.
    • La solución: Vuelve a validar antes de cualquier envío grande y trata la recencia de la interacción como una señal de primer nivel, junto a la validez sintáctica.
  7. Citar una cifra de prevalencia que no has medido.

    • Qué falla: Un número sacado de un artículo determina una decisión de política, y resulta que tu tasa real difiere en un orden de magnitud.
    • La solución: Instrumenta tu propio flujo de registro, clasifica una muestra real y diseña la respuesta a partir de la tasa que has medido.

Preguntas frecuentes

P: ¿Qué es una dirección de correo desechable?
R: Un buzón creado bajo demanda, normalmente sin registro, y descartado al cabo de minutos o días. Es una dirección real y entregable, y por eso supera todas las comprobaciones de sintaxis, DNS y SMTP.

P: ¿Por qué no las detecta la validación de correo estándar?
R: Porque a nivel de protocolo no hay nada que detectar. El dominio tiene un MX válido, el servidor acepta el correo, el buzón existe. La detección tiene que identificar al proveedor en lugar de probar la dirección.

P: ¿Basta con una lista publicada de dominios desechables?
R: Como base, sí; como solución completa, no. Los proveedores operan grandes conjuntos rotativos de dominios alias precisamente para burlar el bloqueo a nivel de dominio. Combina la coincidencia con listas y la clasificación por MX.

P: ¿Por qué el registro MX es mejor señal que el dominio?
R: Los dominios alias son baratos y rotan constantemente. La infraestructura de correo que hay detrás cambia mucho más despacio, así que clasificar por servidor de correo detecta dominios que todavía no aparecen en ninguna lista.

P: ¿Debería bloquear las direcciones desechables en el registro?
R: Depende de tu producto. Bloquear también ahuyenta a usuarios legítimos preocupados por su privacidad. Condicionar a verificación las acciones caras o irreversibles suele ser mejor negocio que rechazar la cuenta. En las listas de correo saliente, eliminarlas antes de enviar es sencillamente lo correcto.

P: ¿WebTrackly valida direcciones de correo?
R: No. WebTrackly distribuye datos masivos de dominios en archivos descargables. Los paquetes de zona enriquecidos incluyen registros MX, que son la entrada para construir una detección basada en MX; la lógica de validación se queda en tu propio pipeline o en manos de un proveedor de validación.

P: ¿Los paquetes contienen direcciones de correo?
R: No. Los archivos contienen dominio, servidores de nombres, MX, IP resuelta y CMS detectado. No hay direcciones de correo, números de teléfono ni datos de contacto personales en ningún paquete.

P: ¿Qué tamaño tiene el catálogo?
R: 1,538 paquetes — 716 archivos de zona, 716 conjuntos de zona enriquecidos, 79 listas de sitios por tecnología y 27 datasets seleccionados — que cubren 285,582,781 dominios en los paquetes de zona, de los cuales 163,422,083 son .com. El dataset de todos los dominios registrados contiene 272,614,863 filas.

P: ¿Cómo mantengo los datos actualizados?
R: Cada paquete se exporta en el momento de la compra. Vuelve a comprar el mismo paquete más adelante y compara los dos archivos para ver qué dominios son nuevos.

P: ¿Qué hace la API?
R: Expone el catálogo. GET /api/v1/packages/?type=zone lista los paquetes de zona, ?type=technology&q=wordpress filtra los paquetes de tecnología y /api/v1/packages/{slug}/ devuelve los detalles de un paquete, con autenticación mediante bearer token.


Conclusión

La detección de correo desechable es un problema de mantenimiento, no de consulta. Los proveedores rotan dominios más rápido de lo que cualquier lista puede absorberlos, así que la pregunta no es qué lista descargar, sino qué señal sigue funcionando cuando los dominios cambian. Esa señal es la infraestructura de correo: los dominios alias son desechables por diseño; los servidores que hay detrás, no.

Un stack que funciona es por capas: una lista de código abierto actualizada automáticamente para dar amplitud, clasificación por MX para los dominios que la lista aún no ha visto y un proveedor de validación allí donde necesitas una respuesta en tiempo real durante el registro. Aliméntalo con tu propia tasa de prevalencia medida en lugar de con una cifra sacada de un artículo, mantén los servicios de alias con reenvío en su propia categoría y puntúa en lugar de rechazar. Si quieres construir tú mismo la capa MX, los paquetes de zona enriquecidos incluyen el registro MX de cada dominio de la zona, que es exactamente la entrada que requiere ese paso.

Ver el catálogo de datasets →

Compartir esta entrada

Entradas relacionadas

Comentarios (0)

Dejar un comentario

Aún no hay comentarios. ¡Sé el primero en comentar!

support_agent
WebTrackly Support
Usually replies within minutes
¡Hola!
Envíanos un mensaje y te responderemos lo antes posible.