Crea una lista de permitidos y denegados para dominios de correo en el registro que bloquee dominios desechables sin impedir empresas reales. Consejos para ownership y mantenimiento.
Por defecto, usa una lista de denegación que bloquee dominios de correo desechables conocidos y dominios vinculados a abuso repetido. Añade una lista de permitidos solo cuando el acceso deba estar limitado (por ejemplo, herramientas internas o un portal para clientes específicos).
Empieza con tus propios datos de registro de los últimos 30–90 días. Busca dominios con alto volumen de registros pero casi nula activación, rebotes permanentes repetidos o informes claros de abuso, y revisa algunas muestras antes de bloquear nada.
Normaliza primero el dominio del correo: elimina espacios, pásalo a minúsculas y quita cualquier punto final. Luego, por defecto, haz coincidir dominios exactos, porque los patrones amplios son la forma más fácil de bloquear usuarios legítimos por accidente.
Un buen predeterminado es «gana la lista de permitidos», de modo que una excepción revisada pueda desbloquear usuarios reales rápidamente incluso si existe una regla de denegación más amplia. Si eliges «gana la lista de denegados», prepárate para más tickets de soporte y recuperación más lenta cuando haya errores.
Evita reglas amplias como bloquear TLDs por país, dominios con guiones o cualquier cosa “poco común”. Antes de poner un dominio en la lista de denegados, comprueba si lo usan organizaciones reales (universidades, gobierno, grandes ISP) y revisa registros exitosos recientes desde ese dominio.
Muestra una razón clara y un siguiente paso sencillo. Por ejemplo: “Este proveedor de correo no está permitido. Usa un correo de trabajo o contacta al soporte para solicitar una excepción”, y asegúrate de que soporte vea cuál fue la regla exacta que activó el bloqueo.
Ejecuta las reglas en modo «solo registro» primero para medir impacto, luego despliega en pequeños lotes con un interruptor de reversión rápida. Prueba contra una muestra reciente de registros reales para estimar cuántos usuarios buenos bloquearías antes de aplicar la regla.
Asigna un responsable claro para aprobaciones y apelaciones, y registra cada cambio con una razón corta y una fecha de revisión. Sin propiedad, las listas se degradan y acabas con bloqueos permanentes que nadie puede explicar o eliminar con confianza.
Revisa la lista de denegados semanalmente y la de permitidos mensualmente como referencia práctica. Añade fechas de caducidad a bloqueos temporales y excepciones para que caduquen automáticamente a menos que alguien las renueve con evidencia nueva.
Las listas de dominio son una capa de política, no prueba de que una dirección sea real. Combínalas con validación de correo que verifique sintaxis, registros DNS y MX, y señales de proveedores desechables para bloquear menos usuarios legítimos mientras detectas registros malos.
Las reglas de dominio existen para proteger el registro de problemas previsibles: cuentas falsas, rebotes y abuso. Si la gente puede registrarse con direcciones desechables, acabarás con usuarios a los que no puedes contactar, tasas de rebote más altas y una base de datos desordenada. Los dominios desechables también son una herramienta común para bots y estafadores porque facilitan crear miles de cuentas.
Una lista de permitidos y una lista de denegados para dominios de correo en el registro es un control tosco pero útil. Funciona mejor cuando tienes claro qué intentas detener. Bloquear proveedores desechables conocidos, por ejemplo, puede reducir rápidamente registros de baja calidad, incluso antes de enviar un correo de verificación.
Ayuda separar dos ideas:
Esa diferencia importa porque el intercambio es real. Reglas más estrictas suelen significar menos registros malos, pero también más rechazos erróneos. Si bloqueas de forma demasiado amplia, rechazarás usuarios reales que intentan registrarse de buena fe.
Entonces, ¿qué cuenta como un dominio corporativo legítimo en tu contexto? Normalmente es un dominio propiedad de una organización real que puede recibir mensajes de forma fiable. Eso puede incluir el dominio principal de una empresa (como name.com), dominios regionales (como name.co.uk) o un dominio gestionado por un proveedor que usan para su personal. El objetivo es bloquear dominios riesgosos sin castigar el correo empresarial normal.
Una lista de dominios no es una característica: es una decisión de política que afecta ingresos, carga de soporte y confianza. Antes de construir una lista de permitidos y denegados para el registro, sé específico sobre qué estás previniendo.
La mayoría de los equipos tiene un objetivo principal (y un par de secundarios): detener direcciones desechables, reducir fraude en el registro o proteger la entregabilidad manteniendo datos malos fuera. El objetivo importa porque cambia qué bloqueas y cuán estricto eres. Bloquear dominios desechables suele ser seguro. Bloquear dominios de “correo gratuito” es arriesgado y a menudo bloquea usuarios legítimos.
También escribe lo que no vas a bloquear, aunque parezca sospechoso. Ejemplos comunes incluyen clientes que pagan, usuarios invitados, socios y cuentas internas. Una regla simple como “permitimos estos flujos, pero pueden marcarse para revisión” evita muchos bloqueos accidentales.
Decide dónde se aplica el cumplimiento para que las reglas sean consistentes en todo el producto: formularios de registro autoservicio, APIs públicas que crean usuarios, usuarios creados por administración en tu back office, flujos de invitación (a menudo más permisivos) y acciones sensibles como restablecer contraseña o cambiar correo (evita sorprender a usuarios existentes).
Finalmente, fija expectativas para soporte. Si alguien es bloqueado, ¿qué ve y cómo lo arregla? Un buen mensaje de bloqueo incluye una razón simple (“Este proveedor de correo no está permitido”), un siguiente paso seguro (usar un correo de trabajo o contactar soporte) y una vía clara de apelación.
Una lista de permitidos es la opción estricta. Solo dejas registrarse a quienes tienen un dominio que confías. Esto funciona mejor cuando ya sabes quién debe tener acceso.
Casos comunes de listas de permitidos incluyen herramientas internas para empleados, betas privadas donde las invitaciones van a empresas específicas, o portales B2B donde cada cuenta se corresponde con un dominio empresarial conocido. En estos escenarios, bloquear a una persona real es menos arriesgado porque los dominios correctos son predecibles y el soporte puede añadir los faltantes.
Una lista de denegados es la opción flexible. Dejas pasar la mayoría de los dominios, pero bloqueas los claramente de baja calidad o abusivos. Aquí es donde normalmente bloqueas dominios desechables, dominios vinculados a abuso repetido y patrones evidentes de correo desechable.
Un enfoque híbrido suele ser el más seguro para crecimiento: usa una lista de denegados como base y añade excepciones puntuales en la lista de permitidos para casos importantes. Por ejemplo, un cliente grande podría usar un dominio corporativo poco común, o un socio legítimo podría registrarse desde un subdominio que a primera vista parece sospechoso.
Mantén el lenguaje de las reglas simple para que sea fácil de revisar y difícil de malinterpretar. Coincide dominios exactos (por ejemplo, example.com) siempre que puedas. Decide de antemano si los subdominios se tratan como iguales (si mail.example.com debe contar). Si usas excepciones temporales, asígnales un responsable y una fecha de caducidad, y prefiere reglas pequeñas y claras en lugar de patrones ingeniosos que pueden bloquear a la gente equivocada.
Una lista inicial buena no es algo que descargas y pegas. Debe basarse en lo que realmente ocurre en tu flujo de registro. Así construyes una lista de permitidos y denegados que refleja riesgo real, no suposiciones.
Empieza con tus propios datos. Extrae los últimos 30 a 90 días de intentos de registro, usuarios confirmados, rebotes de correo, quejas de spam y cualquier informe de fraude o abuso. Agrupa por dominio y busca patrones como volumen alto con muy baja activación, rebotes permanentes repetidos o el mismo dominio creando muchas cuentas en poco tiempo.
Si tienes reportes internos, busca reincidentes. Una regla práctica: dominios que generan alto volumen pero casi ninguna interacción merecen revisión, no bloqueo automático. Elige un número pequeño, investiga algunas direcciones y confirma el comportamiento antes de añadir el dominio.
Construye el lado “bueno” también a partir del conocimiento interno. Pide a Ventas y Éxito del Cliente una lista corta de dominios de clientes principales y prospectos activos. Estos pueden convertirse en tu lista inicial de permitidos (o al menos en una lista de “nunca bloquear sin revisar”), lo que te ayuda a evitar fricciones accidentales para empresas reales.
Sea lo que sea que añadas, escribe por qué está allí. Mantén la nota corta y útil: la fuente (reporte, ticket, caso de fraude, datos de rebote), fecha de adición, quién lo aprobó, qué observaste y cuándo lo revisarás.
Ejemplo: ves 400 registros desde un solo dominio en una semana, pero cero confirmaciones y muchas IPs idénticas. Documentas la evidencia, lo añades a la lista de denegados y pones una revisión a 30 días por si el patrón cambia.
Trata el dominio del correo como entrada no confiable. Pequeñas diferencias de formato pueden romper tus reglas.
Normaliza cada dirección del mismo modo antes de compararla con cualquier lista: quita espacios, pásala a minúsculas y elimina un punto final (algunos sistemas tratan example.com. como válido). Haz esto una vez, cerca del punto donde el correo entra en tu sistema, para que todas las comprobaciones posteriores vean el mismo valor.
A continuación, decide cómo funciona la coincidencia y escríbelo. “Solo dominio exacto” es más seguro para la mayoría de equipos porque evita sorpresas. “Incluir subdominios” puede ser útil (por ejemplo, bloquear mail.disposable.com junto con disposable.com), pero también puede bloquear configuraciones legítimas si una empresa usa subdominios inusuales.
Escoge una regla de desempate y aplícala en todas partes. Muchos productos eligen “gana la lista de permitidos” para que una excepción revisada desbloquee usuarios reales inmediatamente, incluso si existe una regla de denegación más amplia. Si eliges “gana la lista de denegados”, espera más tickets de soporte y desbloqueos más lentos.
Un despliegue seguro suele verse así:
La forma más rápida de perder registros reales es bloquear con patrones amplios. Evita reglas como “denegar todos los TLDs de país” o “denegar cualquier cosa con un guion”. Muchas empresas reales usan dominios como company.co.uk, company.com.au o configuraciones regionales como eu.company.com.
Trata los subdominios como normales, no como sospechosos. Una gran empresa puede enrutar correo mediante subdominios para distintos equipos, regiones o adquisiciones. Si tu regla solo comprueba el “dominio principal”, asegúrate de manejar correctamente casos como company.co.uk vs company.com, y de no marcar mail.company.com como “desconocido”.
Ten cuidado con los proveedores de enrutamiento de correo. Algunas empresas legítimas envían y reciben correo a través de servicios que parecen genéricos, y sus registros MX pueden semejarse a los usados por servicios desechables o solo de marketing. Las reglas de dominio por sí solas no pueden determinar intención.
Una simple lista de comprobación de seguridad antes de añadir una regla de denegación:
Finalmente, crea un proceso de excepciones para cuentas de alto valor. Tras fusiones, un cliente puede tener cinco o diez dominios activos. Facilita que soporte o ventas soliciten una excepción temporal mientras verificas la propiedad y actualizas las reglas con seguridad.
Las reglas de dominio fallan mayormente por una razón aburrida: nadie las posee. Asigna a un equipo o rol una responsabilidad clara para aprobar cambios y gestionar apelaciones. No se trata de control, sino de velocidad y consistencia cuando un cliente real queda bloqueado.
Un flujo básico basta:
Cada cambio debe quedar registrado para que puedas explicarlo más tarde. Mantén el registro pequeño: quién lo solicitó, quién lo aprobó, qué cambió (dominio y tipo de regla), por qué (evidencia), cuándo se activó y cuándo volver a comprobar.
Fija un SLA para bloqueos disputados para que usuarios legítimos no queden atascados. Por ejemplo: acuse de recibo en 4 horas hábiles y resolución en 1 día hábil, con una vía de emergencia para clientes de pago.
Antes de denegar un dominio, exige evidencia, no sensaciones. Pruebas típicas incluyen alto volumen de registros con patrones claros de abuso, rebotes permanentes repetidos, quejas de spam o una alta tasa de coincidencia con proveedores desechables conocidos.
Ejemplo: Soporte informa que usuarios de acme-partners.com no pueden registrarse. El responsable revisa el registro, ve que fue bloqueado por 30 registros de spam en una hora, y cambia a una regla temporal más estricta más comprobaciones adicionales, para revisar de nuevo en 48 horas.
Una lista de dominios no es una configuración única. En cuanto dejas de atenderla, deriva: los patrones de abuso antiguos desaparecen, aparecen nuevos dominios desechables y una sola entrada mala puede bloquear silenciosamente a usuarios buenos.
Fija un ritmo de revisión acorde al riesgo. Semanal para la lista de denegados es un punto de partida común, ya que los atacantes se mueven rápido. Mensual para la lista de permitidos suele funcionar porque los dominios legítimos cambian más despacio.
Para evitar la degradación, haz que las decisiones temporales expiren por defecto. Si añades un dominio por una oleada de spam corta, adjunta una fecha de caducidad y una nota sobre por qué se añadió. Haz lo mismo para excepciones (“permitir este dominio para el Socio X hasta que termine el contrato”). Cuando llegue la fecha, la regla caduca a menos que alguien la renueve con evidencia fresca.
Sigue algunos métricas para ver si la lista ayuda o perjudica: tasa de bloqueos, tasa de apelaciones, falsos positivos (usuarios legítimos bloqueados confirmados), tasa de rebotes y concentración por dominio (qué porcentaje del tráfico viene de un dominio).
Atento a dos señales en particular: nuevos dominios desechables y picos repentinos en un único dominio. Si examplemail.co pasa de 2 registros al día a 400 en una hora, investiga antes de bloquear en bloque. Examina geografía, patrones de IP y si las direcciones son sintácticamente válidas y tienen enrutamiento de correo real.
Finalmente, retira entradas con decisión. Si un dominio no ha producido abuso en un tiempo, o sigue causando falsos bloqueos para empresas reales, elimínalo o sustituye un bloqueo duro por un control más suave como límites de tasa, verificación extra o revisión manual.
La forma más rápida de romper la confianza con usuarios reales es bloquear dominios basándote en corazonadas. Una lista de permitidos y denegados solo funciona si se basa en evidencia, se revisa con frecuencia y se aplica de la misma manera en todas partes.
Una trampa común es bloquear demasiado amplio. Los equipos a veces deniegan TLDs completos o un gran proveedor de correo por un pico temporal de malos registros. Eso casi siempre atrapa a gente legítima, especialmente contratistas, estudiantes y usuarios internacionales.
Otra trampa es etiquetar un dominio como desechable solo porque es nuevo, poco común o parece “aleatorio”. Muchas empresas reales usan dominios pequeños alojados, rebrandings o proveedores regionales. Si no tienes pruebas (tasa de fraude, rebotes, informes de abuso), trata lo “desconocido” como “no verificado”, no como “malo”.
Los patrones que más daño causan son:
Incluso un bloqueo correcto puede crear problemas si la experiencia de usuario no está clara. Si alguien se topa con un bloqueo, necesita entender qué pasó y qué hacer después. Registra la razón exacta y la regla que activó el bloqueo, muestra un mensaje claro (evita “correo inválido” vago) y mantiene una vía de excepción rápida para clientes o socios conocidos.
Antes de publicar una actualización en tu lista de permitidos y denegados para el registro, haz una pasada de seguridad. La mayoría del daño viene de pequeñas inconsistencias, contexto faltante o cambios sin marcha atrás.
Empieza con las reglas de coincidencia. Decide si haces coincidencia de dominio exacto (example.com) o incluyes subdominios (mail.example.com). Luego normaliza la entrada siempre de la misma forma: minúsculas, quitar espacios y convertir dominios internacionales a un formato consistente. Si tu sistema trata Gmail.com y gmail.com de forma diferente, perderás casos y generarás comportamiento confuso.
Asegúrate de que cada regla sea explicable. Cada entrada debe tener una razón corta, la fecha de adición y un responsable que pueda responder preguntas después. “Dominio malo” no es una razón. “Visto en 1.200 registros fraudulentos la semana pasada” sí lo es.
Mantén la vía de apelación simple pero real. Pon una revisión con límite temporal en entradas discutidas para que los errores no duren para siempre. Y no dejes que excepciones temporales se vuelvan permanentes por accidente: si permites un dominio arriesgado para un lanzamiento de socio o un evento, pon una caducidad y elimina la excepción salvo que alguien la renueve con una razón.
Tras el cambio en producción, vigila el impacto. Rastrea falsos positivos y atiéndelos rápido. Monitoriza la tasa de rebotes y cambios en entregabilidad para dominios recién permitidos. Muestrea registros recientes para confirmar que las reglas se comportan como esperabas.
Un SaaS B2B nota un pico repentino de cuentas nuevas usando dominios imitadores (como "acme-corp-support.com" en lugar de la compañía real) y una oleada de proveedores desechables. Ventas se queja de leads basura y soporte ve más intentos de chargeback. El equipo ya tiene una lista de permitidos y denegados, pero no se ha tocado en meses.
Comienzan con una respuesta medida, no con una purga masiva. Primero añaden una regla de denegación dirigida para el peor dominio desechable que aparece en los logs. También ponen un límite temporal de tasa en registros que parecen riesgosos (misma gama de IP, alta velocidad, nombres de usuario repetidos). Eso reduce el abuso mientras aprenden, en lugar de bloquear categorías enteras de dominios.
Dos días después, un cliente real queda bloqueado. Una gran empresa usa un subdominio regional para correo (por ejemplo, [email protected]). Una regla amplia que pretendía captar subdominios imitadores lo empata por error. Soporte escala con evidencia: el prospecto tiene un contrato firmado, historial de IP consistente y los mensajes rebotan porque la cuenta nunca completó el registro.
La solución no es quitar la entrada de la lista de denegados. En su lugar, añaden una excepción estrecha en la lista de permitidos para el dominio corporativo verificado, documentan por qué existe y ponen una fecha de caducidad para revisarlo más tarde.
Tras dos semanas, el equipo revisa resultados: los bloqueos suben al 6% (desde 1%), pero las apelaciones de soporte se mantienen bajas en 0.2% del total de registros. La tasa de rebote en correos de bienvenida baja de 3.4% a 1.1%, y Ventas reporta menos demos falsos. La ganancia clave es confianza: cada regla ahora tiene un responsable, una razón y un camino de reversión.
Las listas de dominios son útiles, pero son una herramienta tosca. Combínalas con validación de correo para detectar direcciones malas incluso cuando el dominio parece normal, y evita bloquear usuarios reales solo porque usan un dominio corporativo desconocido.
Empieza por escribir tu política en lenguaje claro: qué bloqueas, qué permites y qué pasa a revisión manual. Eso mantiene a soporte, producto e ingeniería alineados cuando alguien pregunta por qué se rechazó un registro.
Un flujo práctico es: comprobar sintaxis, verificar que el dominio puede recibir correo (chequeos DNS y registros MX), filtrar proveedores desechables conocidos y trampas de spam, y luego aplicar tus reglas de lista de permitidos y denegados (incluyendo excepciones). Registra el resultado para aprender y ajustar.
Si quieres mantener las reglas simples y aun así obtener señales fuertes en el registro, Verimail (verimail.co) es una opción que algunos equipos usan para validar correos con comprobaciones RFC, verificación de dominio y MX, y coincidencia con proveedores desechables en una sola llamada API. Usada así, tus listas siguen siendo una capa de política y la validación realiza el trabajo pesado de decidir si una dirección parece real y alcanzable.
