50 correos, 12 rebotes: el 250 OK de SMTP no prueba que el buzón exista

Cincuenta direcciones que habían pasado una verificación por handshake SMTP devolvieron 250 OK. Tres horas después, doce de ellas rebotaron: un 24% de fallos en 38 minutos sobre una lista que en los logs parecía sana. El autor del experimento ha publicado el código que reproduce el caso, y la conclusión es incómoda: que el servidor responda 250 no prueba que el buzón exista.

La misma lista pasó después por un validador que mira comportamiento de MX, historial de filtraciones, cuentas de rol e identidad del proveedor. Para una dirección de Gmail, la respuesta trae valid: true, syntax_valid: true y mx_found: true, pero deja smtp_verified: null. Ese nulo es la pista.

El validador se detuvo antes del paso que importa

El campo stage vale mx: la comprobación se quedó en la resolución del registro MX y nunca lanzó la sonda SMTP. smtp_verified: null no es un handshake fallido, es un handshake que no llegó a producirse. Las doce direcciones que rebotaron no tenían la sintaxis mal ni les faltaba MX, y su servidor aceptaba la conversación. Simplemente, el buzón no estaba en ninguna parte.

El score de 75 sobre 100 es lo que más engaña. Setenta y cinco suena a aprobado, pero es una mezcla de factores, y un smtp_verified nulo debería pesar mucho más de lo que pesa. El validador es honesto dentro de su lógica: no puede demostrar que el buzón sea real, pero tampoco que no lo sea, así que lo deja en una zona intermedia donde el número no dice gran cosa.

Aparece además is_role: true con role_type: test. Las cuentas de rol no son buzones personales: nadie las lee y suelen apuntar a un departamento o a un script. Y hay una cifra que no cuadra: el validador informa de breach_count: 579 mientras nombra 19 filtraciones concretas, de Adobe a Yahoo. La mayoría de índices cuentan incidentes distintos por dirección, no registros sueltos, así que 579 para un único Gmail no se sostiene. Conviene leerlo como aviso direccional, no como un total.

Para quien manda correo a escala, la lección es que la higiene de listas no admite atajos. Un validador que se para en el MX es rápido y barato y devuelve un aprobado donde debería devolver una duda, y eso se paga en rebotes a las tres horas. La otra mitad de la historia es menos técnica: el autor de la prueba es el autor de la API que recomienda, y las cifras son suyas, sin medición independiente que las respalde.