Empezó con una alarma por la tarde: alguien estaba abusando del formulario de acceso de nuestros sitios como catapulta de spam – el envío de códigos de un solo uso podía dispararse contra cualquier dirección. La IA incorporó límites de frecuencia en una hora (por dirección de destinatario ya existían; por solicitante y en total, faltaban). Pero el daño de verdad llegó con retraso: poco después, Microsoft bloqueó mi dirección personal de remitente para el correo saliente – la dirección por la que hasta entonces salían también los códigos de acceso. Mi dirección de correo más importante, dejada fuera de juego por el abuso de mi propia página de acceso.
El plan quedó claro enseguida: el envío automático se muda a una dirección propia, noreply@carecom.de, limpiamente separada de mi buzón. La IA se sabía los pasos – buzón nuevo, permiso para la aplicación de envío, ajustes en los servidores. Y luego, a pesar de todo, nada funcionó.
Dos trampas que nadie ve
La primera trampa estaba en la letra pequeña de Microsoft 365: los buzones nuevos vienen al mundo con la vía de envío SMTP desactivada, y ese interruptor bloquea antes de cualquier comprobación de permisos – el permiso correctamente configurado caía en el vacío. En el registro de actividad estaba la verdad desnuda: «535 5.7.139 Authentication unsuccessful, SmtpClientAuthentication is disabled». Tras un solo comando de administración, el envío funcionaba – y mi dirección personal recibió el mismo interruptor en sentido contrario: explícitamente bloqueada para programas. El incidente acabó en un refuerzo de la seguridad.
La segunda trampa no se mostró hasta que llegó el primer correo de la nueva dirección – a la carpeta de spam. La IA comprobó los tres registros DNS con los que un dominio demuestra quién tiene permiso para enviar en su nombre: SPF en orden, la firma DKIM en orden, pero la política DMARC – el registro que les dice a los receptores con qué rigor deben comprobar – respondía con contenido equivocado. En lugar de una política, se devolvían los registros de texto del dominio principal.
La solución del enigma, hallada con un vistazo a la gestión del DNS: «Así que no es un registro _dmarc extraviado, sino un CNAME comodín (wildcard) – este captura todos los nombres de subdominio que no tengan registro propio». Un único registro comodín con años de antigüedad (*.carecom.de apunta al dominio principal) respondía a cada consulta sobre subdominios inexistentes – también a la de los filtros de spam por la política DMARC. Para cualquier verificador parecía que sí había una respuesta, solo que la equivocada. El arreglo fue quirúrgico: un registro explícito exactamente para _dmarc – que desbanca al comodín sin tocarlo. Y como esos registros viven hasta 24 horas en cachés, la IA comprobó el resultado directamente en el servidor de nombres autoritativo, en lugar de a través de un resolvedor público: política en vivo.
Tres dominios en verde – y los tropiezos en el acta
Al final de la tarde, tres dominios de nuestros sitios enviaban con autenticación completa – comprobado, no supuesto. Tiempo total desde la alarma de abuso hasta «todo en verde»: tres horas y media, incluidas todas las ventanas de espera.
Los tropiezos deben constar en acta. Al principio de la mudanza, la IA había declarado que no haría falta trabajo de DNS – dos horas después, el DNS era exactamente el problema. Se perdió en la maraña de IDs de objeto de Microsoft («Creo que todo eso fue innecesario», mi conclusión sobre ese rodeo). Y una vez clasificó un viejo intento fallido como si fuera una prueba nueva – «Tienes toda la razón – lo había clasificado mal». Nada de eso fue grave – pero todo habría pasado inadvertido si nadie hubiera pensado con ella.
Lo que te llevas para tu propio dominio: un «a mí me funciona» vale poco en el correo electrónico – que tus correos lleguen o no lo deciden tres registros DNS públicos que puedes hacer comprobar en cuestión de minutos. Y si en tu zona DNS vive un viejo registro comodín, también responde allí donde tú nunca habías previsto respuesta alguna.
/compact – lo esencial cuando el contexto escasea:
Un formulario de acceso del que se abusó llevó al bloqueo de la dirección personal de remitente; la mudanza a noreply@ cayó en dos trampas invisibles: el interruptor SMTP desactivado por defecto en los buzones nuevos de Microsoft 365 (bloquea antes de cualquier permiso, error 535 5.7.139) y un registro DNS comodín con años de antigüedad que respondía a la consulta DMARC con contenido equivocado – los correos acababan en spam. Arreglo: un comando de administración más un registro _dmarc explícito que desbanca al comodín; verificación directamente en el servidor de nombres autoritativo. Tres dominios en verde en tres horas y media – con los extravíos de la IA abiertamente en acta (el DNS declarado primero innecesario, confusión de IDs, una atribución temporal errónea).