Verificar correos tras un gateway de seguridad
Si alguna vez exportaste un informe de verificación y notaste que un número sospechoso de tus mejores contactos enterprise volvió como desconocido, es bastante probable que hubiera un secure email gateway en medio. No un dominio catch-all, aunque el síntoma es idéntico. Un gateway.
La distinción importa porque la solución es distinta, y porque los contactos detrás de gateways suelen ser justo los que querías. Las empresas pequeñas rara vez usan uno. Bancos, aseguradoras, hospitales, universidades y la mayoría de las Fortune 500 sí.
Qué hace el verificador cuando falla
Una verificación estándar es una conversación corta. Tu verificador se conecta al servidor de correo que figura en los registros MX del dominio, saluda, indica un remitente, luego indica el destinatario y espera. Un servidor que mantiene una lista real de sus buzones responde con honestidad. Dice sí a una dirección que existe y no a una que no, y tu verificador anota la respuesta.
Un secure email gateway es una capa de filtrado que se sitúa delante del servidor de correo real. Todo mensaje para el dominio llega primero al gateway, se analiza en busca de malware, phishing e infracciones de políticas, y solo después pasa al interior. Proofpoint, Mimecast, Barracuda, Cisco y una docena de proveedores más pequeños funcionan así.
El gateway no tiene por qué saber qué buzones existen. Su trabajo es filtrar, no consultar un directorio. Así que cuando tu verificador pregunta por un destinatario concreto, el gateway acepta. Acepta direcciones reales, acepta errores de escritura, acepta nombres de personas que se fueron en 2019. La aceptación ocurre en el perímetro, y la decisión sobre si un buzón existe ocurre en algún lugar detrás, al que tu verificador nunca llega.
Desde fuera, ese comportamiento no se distingue de un dominio catch-all. Misma conversación, misma respuesta, mismo resultado inútil.
Por qué "arriesgado" es el lugar equivocado para detenerse
La mayoría de los verificadores responde a esto etiquetando la dirección. La etiqueta varía según el proveedor. Verás risky, unknown, accept-all, catch-all u ok_for_all según qué exportación estés leyendo. El significado es el mismo en todos los casos: no pudimos saberlo.
Como respuesta es honesta. El problema es lo que pasa después. Las herramientas de envío suelen tratar esas etiquetas como un no suave, y casi todo el mundo hace lo mismo, porque nadie quiere apostar su reputación de remitente a un quizá. Así que las direcciones se filtran de la campaña y se olvidan en silencio.
En una lista B2B eso es aproximadamente el 30% de tus contactos. En una lista orientada a enterprise es más. Pagaste por conseguir esos contactos y volviste a pagar por verificarlos, y el resultado fue un encogimiento de hombros.
Qué hace distinto una comprobación que entiende los gateways
En resumen: dejas de hacerle al gateway una pregunta que no puede responder y buscas otra pregunta que sí puede.
Los gateways no son mudos. Se comportan según patrones que dependen del producto, la configuración y la dirección concreta. Los tiempos de respuesta difieren entre una dirección que el gateway acabará enrutando y otra que acabará rechazando. Los códigos de error y su redacción exacta difieren entre proveedores y entre versiones. Algunos gateways muestran un rechazo más tarde en la transacción, después del punto en que la mayoría de los verificadores deja de escuchar. Algunos se comportan de forma distinta con un buzón real que con una cadena aleatoria en el mismo dominio, si sabes qué comparar.
Leer esas señales implica primero identificar el gateway y luego aplicar una comprobación hecha para ese producto concreto en lugar de la genérica. Por eso la cobertura de gateways suele darse como un número. Giggal.ai detecta quince, entre ellos Proofpoint, Mimecast y Barracuda. Otras herramientas que lo intentan nombran tres o cinco. Un verificador que no nombra ninguno casi seguro devuelve el resultado genérico y lo etiqueta como arriesgado.
Conviene ser claro con los límites. Es una inferencia a partir del comportamiento observado, no una consulta de directorio, así que no es infalible y ningún proveedor honesto te dirá lo contrario. Lo que hace de forma fiable es convertir un segmento grande e inutilizable en uno mayormente utilizable, que es una afirmación distinta y más modesta que la perfección.
Cuánto de tu lista está afectado
No necesitas una herramienta para comprobar si los gateways son tu problema. Necesitas los registros MX de los dominios de tu lista.
Toma la parte de dominio de cada dirección, quita duplicados y consulta los registros MX de cada uno. Un dominio detrás de Proofpoint apunta a nombres de host que contienen pphosted o ppe-hosted. Los dominios de Mimecast apuntan a hosts de mimecast.com, normalmente con un código de región. Barracuda aparece como barracudanetworks.com. Cisco aparece como iphmx.com. Los dominios de Microsoft 365 y Google Workspace apuntan a hosts de outlook.com y google.com respectivamente, y esos no son gateways, aunque pueden estar configurados como catch-all.
Cruza esa lista con las direcciones en las que tu verificador se rindió. Si la coincidencia es grande, el gateway es la explicación, y volver a pasar la misma herramienta no cambiará el resultado.
Elegir una herramienta para esto
Tres preguntas separan un verificador que resuelve esto de uno que no.
¿Nombra los gateways que detecta? Un proveedor que hace trabajo real aquí publica una lista o al menos una cifra, porque eso es lo que vende. Un lenguaje vago sobre detección avanzada sin productos nombrados suele significar detección, no resolución: la herramienta puede decirte que hay un gateway y aun así no puede decirte si el buzón es real.
¿Devuelve válido o no válido, o devuelve una etiqueta? Pregunta concretamente cómo es la salida para una dirección detrás de Mimecast. Si la respuesta es una marca de arriesgado con una puntuación de confianza, has comprado una etiqueta algo mejor.
¿Cuánto cuesta en las direcciones que requieren el trabajo? Resolver gateways y catch-all le cuesta más al proveedor, así que la mayoría le pone otro precio. Algunos cobran un múltiplo del crédito estándar. Otros lo descuentan de una asignación aparte y más pequeña que se agota antes que la estándar. Ninguna de las dos cosas es irrazonable, pero conviene saberlo antes de subir una lista con un 40% de dominios enterprise. Giggal.ai cobra todas las verificaciones a 1 crédito fijo por dirección, del mismo saldo que todo lo demás.
La secuencia práctica
Pasa tu lista por lo que uses ahora y guarda la exportación. Saca cada fila que volvió como arriesgada, desconocida o accept-all. Revisa los registros MX de esos dominios para ver cuántos son gateways y no simples catch-all. Después pasa solo ese segmento por una herramienta hecha para ello y compara las dos exportaciones lado a lado.
La comparación es lo importante. Todos los proveedores, nosotros incluidos, hacen afirmaciones de precisión que suenan parecidas en una página de precios. La única cifra que significa algo es cuántos de tus propios contactos dados por muertos vuelven a estar vivos, y si los marcados como válidos aceptaron de verdad el correo cuando les enviaste.
Si quieres probarlo, Giggal.ai da 1.000 créditos gratis sin tarjeta, y funcionan con una carga en bloque en lugar de una dirección cada vez, que es la única forma en que esta prueba te dice algo. Para una sola dirección puedes validar el correo. También puedes leer más sobre cómo verificamos los dominios catch-all y accept-all, o sobre el enfoque de verificación SEG (en inglés) con más detalle.