¿Por qué los correos de Amazon SES caen en spam?

Amazon SES es un buen servicio de envío que entrega sin reparos un mensaje mal configurado a la carpeta de spam a una escala enorme. Es deliberadamente neutral: ustedes le entregan un mensaje, él lo pasa al receptor y no opina sobre si su dominio merece la bandeja de entrada.

Ese diseño es la razón por la que el correo de SES termina en spam por causas que no tienen nada que ver con SES. Tres causas cubren casi todos los casos y vale la pena revisarlas en orden, porque la primera es a la vez la más común y la menos obvia.

Causa uno: el MAIL FROM predeterminado rompe la alineación DMARC

Este es el fallo específico de SES y atrapa configuraciones que se ven perfectas en todo lo demás.

Cada mensaje tiene dos direcciones From. La que ve el lector, en el encabezado From:, y el remitente del sobre invisible en MAIL FROM, que es adonde van los rebotes. SPF se verifica contra el remitente del sobre, no contra el visible.

Por defecto, SES establece el remitente del sobre como un subdominio de amazonses.com. Su destinatario ve esto en los encabezados:

Return-Path: <0100018f2c@eu-west-1.amazonses.com>
From: hello@example.com
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of 0100018f2c@eu-west-1.amazonses.com
         designates 54.240.8.1 as permitted sender)
       dkim=pass header.i=@example.com
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.com

Lean con atención la línea spf=pass. SPF aprobó, para amazonses.com. Ese dominio no tiene nada que ver con example.com, así que para efectos de DMARC SPF no está alineado y no aporta nada. En ese encabezado DMARC aún aprueba, pero solo porque DKIM está haciendo todo el trabajo por su cuenta.

Eso está bien, hasta que un mensaje se reenvía, una pasarela de seguridad reescribe algo o DKIM falla por cualquier otra razón. En ese momento ya no cuentan con un segundo respaldo y el mensaje falla DMARC de forma directa.

La solución es un dominio MAIL FROM personalizado: un subdominio como mail.example.com que configuran en la identidad de SES y respaldan con los registros MX y SPF que SES les da. Después de eso, SPF aprueba para su propio subdominio, que se alinea con su dominio From, y ambos soportes se mantienen.

Hagan esto: peguen los encabezados crudos de un mensaje de SES en el analizador gratuito de encabezados de correo y vean qué dominio nombra la línea spf=pass. Si dice amazonses.com, configuren un MAIL FROM personalizado hoy.

Causa dos: la reputación de IP compartida que no controlan

A menos que hayan pagado por una IP dedicada, su correo de SES sale por un grupo compartido. Su reputación de dominio es suya. La reputación de IP se comparte con quien más esté enviando desde esa dirección hoy.

Esto produce un síntoma específico y confuso: su dominio está limpio en todas partes, todos los registros aprueban y aun así el correo cae en spam en un proveedor y en otro no. Ese patrón apunta a la IP, no a ustedes.

Vale la pena tener claro qué pueden hacer aquí, porque la respuesta honesta es “no mucho de forma directa”. No pueden limpiar una IP que comparten. Lo que sí pueden hacer es asegurarse de que el problema sea realmente la IP antes de buscarlo en su propia configuración, y de que sus señales a nivel de dominio sean lo bastante fuertes para sostener el mensaje a pesar de una IP mediocre.

Verificar esa división es rápido. Una verificación gratuita de listas de bloqueo sobre su dominio consulta el dominio y las IPs de su servidor de correo por separado contra las listas principales, así que una inclusión en una y no en la otra les dice qué problema tienen.

El instinto en este punto suele ser comprar una IP dedicada. Por debajo de unas 100,000 mensajes al mes, eso normalmente empeora las cosas en lugar de mejorarlas: una IP dedicada no tiene reputación hasta que la construyen y se degrada durante cualquier periodo de inactividad. El grupo compartido es la mejor opción por defecto para la mayoría de los remitentes, precisamente porque siempre está caliente.

Hagan esto: ejecuten la verificación de listas de bloqueo y anoten si la inclusión, si la hay, está en el dominio o en la IP del servidor de correo. Solo la primera es suya para corregir.

Causa tres: la lista y los dos números que AWS vigila

SES publica un panel de reputación en la consola con dos números que importan: la tasa de rebotes y la tasa de quejas. AWS pide a los remitentes masivos mantener la tasa de rebotes por debajo del 5 por ciento y la de quejas por debajo del 0.1 por ciento.

Esos son los umbrales en los que AWS empieza a prestar atención a su cuenta. Los proveedores de buzones empiezan a prestar atención considerablemente antes. Una tasa de rebotes del 3 por ciento no provocará una revisión de su cuenta de SES, y sin duda afectará dónde Gmail coloca su correo.

Ambos números dependen de una sola cosa: quién está en su lista y cómo llegó hasta ahí. Una lista comprada, una exportación vieja o un formulario de registro sin paso de confirmación producirán rebotes y quejas que ninguna cantidad de configuración DNS puede compensar.

Hagan esto: abran el panel de la cuenta de SES, anoten las tasas de rebotes y quejas de hoy y eliminen cada rebote duro de su lista antes del próximo envío.

Cómo verificar la solución

Después de cambiar MAIL FROM o DKIM, esperen a que el TTL de DNS expire, luego envíense un mensaje y vuelvan a leer los encabezados. La línea spf=pass debe nombrar ahora su propio subdominio, y dmarc=pass debe estar respaldado por SPF y DKIM en lugar de solo por DKIM.

La verificación gratuita de salud del correo lee sus registros publicados de SPF, DKIM, DMARC y MTA-STS directamente desde DNS junto con su estado de listas de bloqueo, que es la forma más rápida de confirmar que los registros que configuraron en la consola de SES llegaron realmente a su zona.

Eso responde por un dominio, en el momento en que lo preguntan. Y ahí está la verdadera brecha.

La configuración de SES no es algo que se mantenga fijo. Un MAIL FROM personalizado depende de un registro MX que una migración de DNS puede eliminar en silencio. DKIM depende de tres CNAME que una limpieza bien intencionada puede borrar. La reputación de IP del grupo compartido cambia por el envío de otra persona, en un día en que no estaban mirando. Nada en SES se lo dirá: la llamada a la API sigue devolviendo un ID de mensaje, el envío sigue siendo exitoso y el correo empieza a caer en spam en silencio.

Cerrar esa brecha es lo que hace LitInboxes. Cada dominio monitoreado se revisa cada 6 horas en registros DNS, 8 listas de bloqueo de alta señal en todos los planes y 24 en Pro, reportes agregados de DMARC y reputación de Google Postmaster, con un historial con fechas para que vean exactamente cuándo cambió algo y una alerta por el cambio y no por calendario. Las alertas por correo están en todos los planes; las alertas por Slack, Discord y webhook están en Pro. Hay una demostración en vivo si quieren ver la vista primero.

Si resulta que SES no es el problema, el diagnóstico completo de spam recorre las otras causas en orden de probabilidad.

La lista de verificación

1. Lean los encabezados de un mensaje real de SES y revisen qué dominio nombra spf=pass.
2. Si nombra amazonses.com, configuren un subdominio MAIL FROM personalizado y publiquen los registros MX y SPF que SES les da.
3. Confirmen que Easy DKIM esté verificado y que los tres CNAME resuelvan.
4. Publiquen un registro DMARC con p=none y una dirección rua y empiecen a leer los reportes.
5. Verifiquen el dominio y las IPs de envío contra las listas de bloqueo por separado.
6. Anoten las tasas de rebotes y quejas de hoy desde el panel de SES.
7. Eliminen cada rebote duro y cada dirección sin interacción durante meses.
8. Vuelvan a leer los encabezados cuando expire el TTL y confirmen que SPF ahora se alinea.