¿Por qué los correos llegan al spam? Un diagnóstico sin pánico

Enviaron un correo normal a alguien que pidió recibir novedades, y el mensaje terminó en su carpeta de spam. Quizás un cliente lo mencionó de pasada. Quizás hicieron la prueba ustedes mismos y vieron su propio correo caer en spam.

La parte tranquilizadora: esto rara vez tiene que ver con la redacción y casi siempre se puede arreglar en una tarde. Los filtros de spam no juzgan la prosa. Primero hacen una pregunta mucho más simple, y la mayoría de las veces la respuesta a esa pregunta está rota de una forma que se puede ver y reparar hoy mismo.

Lo que el filtro realmente decide

Un servidor de correo receptor evalúa el mensaje en un orden aproximado de peso:

1. Identidad. ¿Puede probar que el mensaje realmente vino del dominio de la dirección From?
2. Reputación. ¿Qué han hecho últimamente ese dominio y su infraestructura de envío?
3. Interacción. ¿Las personas que reciben este correo actúan como si lo quisieran?
4. Contenido. ¿Qué hay realmente dentro del mensaje?

El contenido va al final y es el que menos pesa de los cuatro. Ese orden importa porque, cuando el correo cae en spam, el instinto lleva a reescribir las líneas de asunto, que es la palanca que casi nunca explica el problema. En su lugar, recorran la lista en orden. La mayoría de los dominios que terminan en spam fallan en alguno de los dos primeros pasos.

Antes de tocar una sola palabra del texto, respondan las cuatro preguntas anteriores en ese orden.

Empiecen por los tres registros que prueban quiénes son

Tres registros DNS hacen el trabajo de identidad. Cada uno responde a una pregunta diferente, y los receptores quieren los tres.

SPF es una lista de los servidores autorizados a enviar correo por su dominio. Vive como un registro TXT en el propio dominio y se ve así:

v=spf1 include:_spf.google.com include:sendgrid.net ~all

Eso dice: Google Workspace y SendGrid pueden enviar por este dominio, y cualquier otra cosa es sospechosa (~all es un soft fail, -all es un hard fail). La falla más común es un dominio con dos registros SPF separados, lo cual es inválido según RFC 7208 y hace que toda la verificación falle en lugar de combinar los registros. La segunda más común es un proveedor que agregaron el año pasado y nunca listaron. Si el suyo necesita reconstruirse, el generador de SPF arma un único registro válido a partir de sus remitentes reales.

DKIM es una firma criptográfica. Su plataforma de envío firma cada mensaje con una clave privada, y la clave pública correspondiente vive en DNS bajo un selector:

s1._domainkey.example.com  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

DKIM pesa más que SPF en un caso específico: el reenvío. Cuando alguien reenvía el mensaje, SPF se rompe porque el servidor que reenvía no está en la lista, mientras que una firma DKIM sobrevive intacta. Si su proveedor les dio registros CNAME o TXT para pegar y nunca terminaron de pegarlos, ese es su error. El generador de DKIM les muestra la forma del registro que su proveedor espera.

DMARC une los dos y les dice a los receptores qué hacer cuando no coinciden. Es un registro TXT en _dmarc.yourdomain.com:

v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1

p=none significa “no cambien nada, solo reporten”. Ese es el punto de partida correcto, y rua es la dirección donde llegan los reportes agregados diarios. Publicar DMARC ya no es opcional para nadie que envíe en volumen: las directrices para remitentes de correo de Google exigen SPF, DKIM y un registro DMARC a los remitentes masivos desde febrero de 2024, y los requisitos para remitentes de Yahoo dicen lo mismo. Construyan el suyo con el generador de DMARC si el registro falta. Si ya está publicado y sigue en none, lean algunas semanas de reportes antes de pasar a quarantine, para saber a cuáles de sus propios remitentes habría bloqueado la política más estricta.

La versión de dos minutos de todo esto: pasen su dominio por el chequeo gratuito de salud del correo y lean los tres veredictos antes de hacer cualquier otra cosa.

Lean un mensaje que realmente falló

Los registros DNS les dicen qué debería pasar. Los encabezados les dicen qué pasó, en un mensaje específico, en un receptor específico. Cuando el correo cae en spam, el elemento más útil de todos es el código fuente de ese mensaje exacto.

En Gmail, abran el mensaje, usen el menú de tres puntos y elijan “Mostrar original”. En Outlook en la web, abran el mensaje, luego el menú de tres puntos y “Ver código fuente del mensaje”. En Apple Mail, usen el menú Ver, después Mensaje y después Fuente original.

Cerca del inicio encontrarán algo así:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=s1 header.b=Qn3kZ2Vd;
       spf=pass (google.com: domain of bounce@mail.example.com designates
         198.51.100.24 as permitted sender) smtp.mailfrom=bounce@mail.example.com;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.com

Tres pass. Ese mensaje no terminó en spam por razones de identidad, lo que suena a mala noticia pero en realidad es un avance: significa que pueden dejar de trabajar en DNS y bajar en la lista. Si alguno de los tres dice fail, softfail, neutral, none o permerror, ya encontraron la causa y ya saben qué registro corregir.

Un detalle que vale la pena conocer: dmarc=fail mientras SPF y DKIM pasan es un estado real y confuso. Significa que la alineación falló, así que el dominio que pasó SPF o DKIM no es el dominio que el lector ve en la línea From. Eso pasa cuando una plataforma envía desde su propio dominio de rebote sin un dominio personalizado bien configurado. La explicación completa de ese estado, incluida la línea de encabezado que nombra la ruta que falla, está en por qué DMARC falla cuando SPF pasa.

Tomen el código fuente de un mensaje que falló y péguenlo en el analizador de encabezados. Les mostrará los resultados de autenticación y la ruta salto por salto.

Si los registros están limpios, es la reputación

La reputación se adhiere primero al dominio y después a la IP de envío, y se construye con lo que pasó en los últimos envíos, no en los últimos años. Cuatro cosas la mueven.

Tasa de quejas. Es la palanca más grande que controlan. Google publica un número concreto: mantengan la tasa de spam reportada en Postmaster Tools por debajo de 0.3%, y Google recomienda quedarse por debajo de 0.1%. Ese umbral es lo bastante bajo para que unos cientos de destinatarios molestos en una lista de cien mil puedan cruzarlo. Si envían cualquier volumen y nunca abrieron Google Postmaster Tools, configúrenlo hoy. Es gratis y es la única vista que existe de cómo Gmail los ve en realidad.

Listas de bloqueo. Aparecer en una lista de bloqueo importante es un instrumento contundente, y explica mejor que cualquier otra cosa una llegada a spam repentina y generalizada. Las que importan son pocas: Spamhaus sobre todo, luego SpamCop y Barracuda. Las otras cientos casi no afectan la llegada real a la bandeja de entrada. Verifiquen con el buscador propio de Spamhaus, que es gratuito, y usen el proceso gratuito de remoción si aparecen listados. Nunca paguen a nadie por una remoción express.

Antigüedad e historial del dominio. Un dominio registrado la semana pasada y sin historial de envío se trata con sospecha, lo cual es normal y temporal, no un defecto por corregir. Lo mismo aplica a un dominio que solía enviar y luego quedó en silencio un año.

Consistencia de volumen. Los proveedores leen un salto repentino como un banco lee una transferencia súbita. Pasar de 200 mensajes por día a 20,000 parece una cuenta comprometida, no un negocio en crecimiento. Enviar con un patrón estable y predecible es una práctica, no un producto.

Revisen primero las listas de bloqueo, porque es la causa que produce un cambio de un día para otro, y luego miren su tasa de quejas en Postmaster Tools.

El contenido y la interacción van al final

Si la identidad está limpia y la reputación está saludable, entonces y solo entonces vale la pena mirar el mensaje.

La interacción pesa más que la redacción aquí. Una lista de personas que se suscribieron el mes pasado y los leen cada semana los protege. Una lista que importaron de un CRM viejo, compraron o extrajeron los va a perjudicar sin importar cómo esté escrito el texto, porque los destinatarios sin interacción diluyen la señal y las direcciones viejas se convierten en trampas de spam. Los filtros también personalizan: su historial con un destinatario específico influye en dónde cae el correo para esa persona, y por eso el mismo mensaje puede llegar a la bandeja de entrada de una persona y al spam de otra.

Sobre el contenido en sí, lo que realmente se correlaciona con problemas es estructural, no léxico: un correo de solo imagen con casi nada de texto, un acortador de enlaces, un dominio recién creado dentro de los enlaces, un desajuste entre el nombre del remitente y el dominio, o una plantilla HTML con marcado roto. El folclore sobre palabras gatillo es, en su mayoría, folclore. Escribir “gratis” no los manda al spam.

Antes de reescribir nada, revisen cuándo interactuaron por última vez los destinatarios de este envío, y eliminen a los que no lo hacen desde hace seis meses.

Del síntoma a la causa

El patrón de la falla acorta la búsqueda de la causa más rápido que cualquier prueba aislada:

• Todos los proveedores los mandan a spam a la vez, a partir de un día específico. Presencia en una lista de bloqueo o un registro DNS roto. Revisen ambos, y revisen cuándo cambió su DNS por última vez.
• Solo Gmail los manda a spam. Reputación o tasa de quejas. Abran Postmaster Tools.
• Solo Outlook los manda a spam. Microsoft pesa la IP de envío más que Gmail, y sus datos de quejas quedan invisibles hasta que se registren para acceder a ellos. Consulten correos que llegan a spam en Outlook pero no en Gmail.
• Solo el sistema de correo de una empresa los manda a spam. Su filtro, sus reglas, muchas veces una allowlist interna. Pídanle a su contacto que los marque como no spam.
• Un dominio recién creado cae en spam en todas partes. Historial, no culpa. Sigan enviando con constancia a las personas que lo pidieron.
• Un dominio que llegaba a la bandeja de entrada deja de hacerlo de repente. Algo cambió: una plataforma de envío nueva, una clave DKIM vencida, una importación de lista o una campaña que generó quejas.
• Algunos destinatarios lo reciben en la bandeja de entrada y otros en spam, con el mismo mensaje. Historial de interacción por destinatario. Nada está roto.
• Gmail muestra “vía” y otro dominio debajo de su nombre. El correo salió por una infraestructura que no pertenece al dominio del From, así que ambas rutas de alineación fallan. Gmail lo documenta como sender mismatch.
• Los encabezados muestran spf=pass pero dmarc=fail. SPF pasó para un dominio que no es suyo: el sobre no se alinea con la dirección From. Consulten por qué DMARC falla cuando SPF pasa.
• Las campañas de Mailchimp u otro ESP caen en spam. Huecos de autenticación de la plataforma. Consulten correos de Mailchimp que llegan a spam.
• Los envíos masivos caen en Promociones en lugar de Principal. Ordenamiento por pestañas, no un veredicto de spam. Consulten correos que llegan a Promociones y no a la bandeja de entrada.
• Los rebotes muestran 550 5.7.1 en la respuesta SMTP. Rechazo permanente, pero el texto después del código les dice si es política de autenticación o permiso de relay. Consulten 550 5.7.1 message rejected.
• Los rebotes muestran 550 5.7.515. El rechazo de autenticación de alto volumen de Microsoft en Outlook.com, Hotmail y Live. Falta SPF en pass, DKIM en pass o DMARC alineado en el dominio From. Consulten 550 5.7.515 en Outlook.
• Un cliente dice que un correo nunca llegó y su registro dice entregado. Aceptado no es entregado en bandeja: el servidor receptor recibió el mensaje y un filtro decidió su destino después. Consulten por qué los clientes no reciben los correos.

Emparejen su síntoma con esa lista y ejecuten solo la revisión que este indica.

El problema de revisar a mano

Todo lo anterior es una fotografía. El problema es que todo se desvía mientras nadie está mirando. Un colega edita el DNS y elimina un include: del registro SPF. Una clave DKIM vence. Alguien importa una lista vieja un martes y la tasa de quejas cruza 0.3% para el jueves. Una IP compartida termina en una lista de Spamhaus que no tiene nada que ver con ustedes. Nada de eso avisa por sí solo. Se enteran semanas después, cuando un cliente comenta que sus facturas siguen cayendo en spam.

Ese vacío es el que cierra LitInboxes. Ejecuta estas mismas revisiones en un calendario para cada dominio que agreguen, guarda el historial para que vean el día exacto en que cambió un registro, vigila las listas de bloqueo y sus señales de reputación, y les escribe por correo o por Slack cuando algo se mueve. Es la diferencia entre diagnosticar un problema en una tarde y enterarse de que existía.

Ejecuten primero la lista de verificación manual de abajo, porque les toma diez minutos y responde la pregunta de hoy. Después decidan si quieren ejecutarla ustedes mismos cada semana o que la ejecuten por ustedes. Si quieren ver cómo es la parte de monitoreo antes de registrarse en nada, hay un recorrido corto aquí.

Qué revisar primero, en orden

1. Pasen el dominio por el chequeo de salud del correo y confirmen que SPF, DKIM y DMARC resuelven y pasan los tres.
2. Extraigan el código fuente de un mensaje que cayó en spam y lean su línea Authentication-Results.
3. Corrijan el registro que falló y luego envíen una prueba nueva, porque los cambios de DNS necesitan un mensaje nuevo para demostrar que funcionan.
4. Verifiquen en Spamhaus si su dominio y su IP de envío aparecen listados.
5. Abran Google Postmaster Tools y comparen la tasa de spam con la línea de 0.3%.
6. Miren cuándo abrieron o hicieron clic por última vez los destinatarios del envío que falla, y dejen de escribirles a los que nunca lo hacen.
7. Solo ahora, miren el mensaje: proporción entre imagen y texto, dominios de los enlaces, nombre del remitente.

Nada en esa lista toma más de unos minutos, y los dos primeros puntos resuelven la mayoría de los casos. Recórranla en orden y sabrán cuál de las cuatro preguntas está fallando en su correo, que es todo el trabajo.

Si envían por Amazon SES, hay una causa más por encima de todas estas: el remitente del sobre por defecto es una dirección amazonses.com, así que SPF autentica a Amazon en lugar de a ustedes y la alineación de DMARC falla hasta que configuren un dominio MAIL FROM personalizado.

Después pongan los pasos 1, 4 y 5 en repetición, semanal si lo hacen a mano, diario si dejan que LitInboxes los vigile por ustedes. La versión señal por señal, incluido el punto donde una pasada semanal deja de alcanzar, está en la revisión semanal de entregabilidad. La llegada a spam es mucho más barata de detectar el día en que empieza que el día en que un cliente se los dice.