El día que los correos de un cliente empezaron a caer en spam sin tocar ni una línea de código
Un cliente que gestiona una pequeña inmobiliaria me escribió un viernes por la tarde, el peor momento posible, diciendo que llevaba dos semanas sin recibir ni un solo aviso de su formulario de contacto. Nadie había tocado el formulario. Nadie había tocado el servidor. Lo único que había cambiado era el proveedor de hosting, migrado tres semanas antes por temas de precio, y ahí ya sabía yo por dónde iban a ir los tiros.
Si tus correos caen en spam sin que hayas cambiado nada visible, casi siempre es un problema de autenticación de dominio: al mover el hosting o el servidor de correo, los registros SPF, DKIM y DMARC del DNS se quedan apuntando al proveedor antiguo, y Gmail u Outlook dejan de poder verificar que ese email realmente sale de quien dice salir. El resultado no es un rebote visible, es peor: el correo se entrega, pero directo a la carpeta de spam del destinatario, así que nadie se entera de que hay un problema hasta que alguien va a buscarlo a propósito.
Y eso fue exactamente lo que encontramos. El SPF seguía listando los servidores del hosting viejo como remitentes autorizados, y el nuevo proveedor, que enviaba el correo transaccional del formulario a través de su propia infraestructura, ni aparecía en esa lista. DKIM directamente no estaba configurado: la firma criptográfica que debería acompañar cada correo para demostrar que no se ha manipulado por el camino, en blanco. Con esos dos fallando a la vez, cualquier filtro antispam medianamente decente iba a desconfiar, y Gmail en concreto lleva un par de años siendo bastante más estricto con esto que hace tiempo.
Lo que revisamos con dig y una taza de café
Entrar en el DNS de un cliente da respeto, sobre todo si el dominio lo compró él mismo hace ocho años en un registrador que ni recordaba tener. Tiramos de dig TXT sobre el dominio para ver el SPF real (no el que creíamos que había, el que había de verdad), y comparamos contra la documentación del nuevo proveedor de hosting. Faltaba el include: correcto y sobraba uno de un servicio de email marketing que el cliente había probado hacía año y medio y ya ni usaba. Trece minutos de trabajo, una vez identificado. Lo lento no fue arreglarlo: fue darnos cuenta de que el problema estaba ahí y no en el código del formulario, que fue lo primero que revisamos, como buenos desarrolladores que sospechan siempre del software antes que de la infraestructura.
DMARC, la parte que casi nadie configura bien
Añadimos DKIM desde el panel del nuevo hosting (la mayoría lo generan solos, solo hay que copiar un registro TXT) y dejamos el DMARC en modo p=none al principio, no en reject directamente. Con p=none solo se recopilan informes de qué correos fallan la verificación sin bloquear nada, y eso nos permitió confirmar durante unos días que ya no había avisos legítimos cayéndose antes de endurecer la política. Pasar a reject sin haber comprobado antes es la forma más rápida de que un correo legítimo del propio cliente, mandado desde su móvil con otra app, empiece a rebotar sin explicación.
El aviso del formulario volvió a la bandeja de entrada al día siguiente de arreglar el SPF, pero el dominio tardó casi dos semanas en recuperar del todo su reputación en Gmail, algo que no controla nadie salvo Google y que no hay manera de acelerar con configuración. Desde entonces, cada vez que migramos el hosting o el email de un cliente, la primera pregunta que hacemos no es sobre el diseño ni sobre el precio: es quién va a mandar los correos y si ese remitente está declarado donde tiene que estarlo. Lo raro es que tardáramos tantos años de incidentes en producción en convertirlo en el primer paso de cualquier migración, en vez del último.