Teníamos un sistema de seguridad para el envío de correo del que estábamos orgullosos: un subsistema que calienta un dominio nuevo de a poco, le pone topes (cuánto, qué tan rápido, en qué horas) y, si la salud se degrada —demasiados rebotes, demasiadas quejas— pausa solo el envío. Un freno automático que nos pusimos a nosotros mismos para no quemar la reputación de un dominio de un día para otro.
Esta semana descubrimos el problema: el freno gobernaba el correo sintético de calentamiento… y nada más. Los envíos reales pasaban por un lado. El medidor que debía contar los envíos de verdad no tenía quién lo llamara; la pausa automática existía en el código y en las pruebas, pero no estaba cableada al camino por donde salía el correo real. Teníamos cinturón de seguridad —desconectado del carro.
Un control que solo vigila el caso de prueba no es un control: es una maqueta. El 'modo seguro’ no cuenta hasta que está en el camino por donde pasa lo real.
Así que lo conectamos de punta a punta. Ahora cada envío real pasa por una compuerta: si no hay dominio configurado, deja pasar (no romper por sobreproteger); si el dominio está calentando, aplica los topes y los horarios; si está pausado o suspendido, difiere —ese es el freno. Los avisos de los proveedores de correo (entregado, abierto, rebotado, marcado como queja) ahora alimentan las tasas de rebote y queja que deciden la salud del dominio, y la pausa automática se dispara sola cuando esa salud cae. Trece pruebas en verde cubriendo justo eso: que el freno frene donde tiene que frenar.
Lo publicamos porque es fácil construir la parte vistosa de un sistema de seguridad —los topes, la lógica de pausa— y no notar que nunca tocó el flujo que debía proteger. La lección encadena con las de estas semanas: el código que existe no es el código que corre. Receipts > adjectives: el recibo es una compuerta nueva en el camino del envío y trece pruebas que confirman que ahora sí, lo real pasa por el freno.