O día en que os correos dun cliente empezaron a caer en spam sen tocarmos nin unha liña de código
Un cliente que leva unha pequena inmobiliaria escribiume un venres pola tarde, o peor momento posible, dicindo que levaba dúas semanas sen recibir nin un só aviso do seu formulario de contacto. Ninguén tocara o formulario. Ninguén tocara o servidor. O único que cambiara era o provedor de hosting, migrado tres semanas antes por temas de prezo, e aí xa sabía eu por onde ían ir os tiros.
Se os teus correos caen en spam sen que cambiases nada visible, case sempre é un problema de autenticación de dominio: ao mover o hosting ou o servidor de correo, os rexistros SPF, DKIM e DMARC do DNS quedan apuntando ao provedor antigo, e Gmail ou Outlook deixan de poder verificar que ese email realmente sae de quen di que sae. O resultado non é un rebote visible, é peor: o correo entrégase, pero directo á carpeta de spam do destinatario, así que ninguén se decata de que hai un problema ata que alguén vai buscalo a propósito.
E iso foi exactamente o que atopamos. O SPF seguía listando os servidores do hosting vello como remitentes autorizados, e o novo provedor, que enviaba o correo transaccional do formulario a través da súa propia infraestrutura, nin aparecía nesa lista. DKIM directamente non estaba configurado: a sinatura criptográfica que debería acompañar cada correo para demostrar que non se manipulou polo camiño, en branco. Con eses dous fallando á vez, calquera filtro antispam medianamente decente ía desconfiar, e Gmail en concreto leva un par de anos sendo bastante máis estrito con isto que hai tempo.
O que revisamos con dig e unha cunca de café
Entrar no DNS dun cliente dá respecto, sobre todo se o dominio o mercou el mesmo hai oito anos nun rexistrador que nin lembraba ter. Tiramos de dig TXT sobre o dominio para ver o SPF real (non o que cría que había, o que había de verdade), e comparámolo coa documentación do novo provedor de hosting. Faltaba o include: correcto e sobraba un dun servizo de email marketing que o cliente probara hai ano e medio e xa nin usaba. Trece minutos de traballo, unha vez identificado. O lento non foi arranxalo: foi decatarnos de que o problema estaba aí e non no código do formulario, que foi o primeiro que revisamos, como bos desenvolvedores que sospeitan sempre do software antes ca da infraestrutura.
DMARC, a parte que case ninguén configura ben
Engadimos DKIM dende o panel do novo hosting (a maioría xérano sós, só hai que copiar un rexistro TXT) e deixamos o DMARC en modo p=none ao principio, non en reject directamente. Con p=none só se recollen informes de que correos fallan a verificación sen bloquear nada, e iso permitiunos confirmar durante uns días que xa non había avisos lexítimos caendo antes de endurecer a política. Pasar a reject sen comprobar antes é a forma máis rápida de que un correo lexítimo do propio cliente, mandado dende o seu móbil con outra app, empece a rebotar sen explicación.
O aviso do formulario volveu á caixa de entrada ao día seguinte de arranxar o SPF, pero o dominio tardou case dúas semanas en recuperar de todo a súa reputación en Gmail, algo que non controla ninguén máis ca Google e que non hai xeito de acelerar con configuración. Dende entón, cada vez que migramos o hosting ou o email dun cliente, a primeira pregunta que facemos non é sobre o deseño nin sobre o prezo: é quen vai mandar os correos e se ese remitente está declarado onde ten que estar. O raro é que tardásemos tantos anos de incidentes en produción en convertelo no primeiro paso de calquera migración, en vez do último.