¿Por qué los correos de Mailchimp llegan al spam?

Crearon la campaña en Mailchimp, la enviaron a personas que se suscribieron, y la tasa de apertura volvió a la mitad de lo habitual. Alguien responde que la encontró en spam. Nada en la campaña se ve distinto de la anterior que funcionó.

Mailchimp opera la infraestructura de envío: los grupos de IP, los bucles de retroalimentación con los proveedores de buzón, los encabezados de baja, el manejo de rebotes. Lo que no puede hacer es demostrar a un receptor que el correo es suyo. Esa prueba vive en registros DNS de su dominio, y falta mucho más seguido de lo que cualquiera esperaría.

Tres causas cubren casi todo.

Causa uno: el dominio nunca se autenticó

Es la causa más común, y se esconde bien, porque Mailchimp envía sin ninguna objeción una campaña para un dominio que nunca completó la autenticación.

Cada mensaje lleva dos direcciones de remitente: la que el lector ve en el encabezado From:, y el remitente del sobre, invisible, al que regresan los rebotes. Los receptores verifican la segunda para SPF y la firma DKIM por separado. DMARC entonces pregunta si alguna de esas verificaciones aprobadas pertenece al mismo dominio que el From: visible. Esa última pregunta se llama alineación, y ahí se decide todo.

Así se ve en los encabezados de un mensaje entregado en Gmail. El dominio tiene publicado un registro DMARC con un p=none simple, por eso Gmail hace eco de una política en su verificación, y no tiene ninguna autenticación de Mailchimp detrás:

Return-Path: <bounce-mc.us18_41205839.4913722-a1b2c3d4@mail105.suw11.rsgsv.net>
From: Ana <ana@example.com>
Authentication-Results: mx.google.com;
       spf=pass (google.com: domain of bounce-mc.us18_41205839@mail105.suw11.rsgsv.net
         designates 198.2.128.1 as permitted sender)
       dkim=pass header.i=@mailchimpapp.net
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=example.com

Dos verificaciones pasaron y DMARC igual falló. SPF pasó para rsgsv.net, DKIM pasó para mailchimpapp.net, y ninguno de los dos es example.com. Para el receptor, una plataforma de envíos masivos mandó correo diciendo venir de un dominio que nunca lo respaldó. Eso es también lo que produce la línea “via mailchimpapp.net” que Gmail coloca debajo del nombre del remitente, y que Mailchimp documenta como la señal de una dirección From sin autenticar.

La autenticación cambia la línea DKIM, y solo la línea DKIM. Mailchimp mantiene el remitente del sobre en sus propios dominios, así que la alineación por SPF no está disponible. Los registros que Mailchimp entrega son dos CNAME y un TXT de DMARC:

k2._domainkey.example.com.  CNAME  dkim2.mcsv.net.
k3._domainkey.example.com.  CNAME  dkim3.mcsv.net.
_dmarc.example.com.         TXT    "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

Cuando los registros resuelven, dkim=pass header.i=@example.com reemplaza al dominio de Mailchimp, DMARC pasa solo por la vía DKIM, y la línea “via” desaparece. El procedimiento para publicar los registros en una zona, incluidos los proveedores que agregan el dominio al nombre de host automáticamente, está en la guía de configuración del registro DKIM y en la guía de configuración del registro DMARC.

Hagan esto: envíense una campaña, peguen los encabezados crudos en el analizador de encabezados de correo gratuito y vean qué dominio nombra la línea dkim=pass. Si nombra a Mailchimp, ahí está el problema.

Causa dos: la dirección From está en un buzón que no les pertenece

Creadores y negocios pequeños suelen enviar campañas desde la dirección con la que responden correo, que con frecuencia es una dirección de Gmail o Yahoo.

Mailchimp es directo en esto: los servicios de correo públicos no se pueden autenticar. No existe ningún CNAME que puedan publicar bajo gmail.com, porque no es su dominio. La firma siempre nombrará a Mailchimp, DMARC nunca se alineará, y el mensaje no lleva nada que lo conecte con ustedes.

Qué tan mal termina depende de cuál servicio gratuito sea. Estas son las políticas que publican los dos más grandes, leídas el 10 de agosto de 2026:

_dmarc.gmail.com.  TXT  "v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com"
_dmarc.yahoo.com.  TXT  "v=DMARC1; p=reject; pct=100; rua=mailto:d@rua.agari.com; ..."

Una campaña con dirección From de yahoo.com les está pidiendo a los receptores aplicar p=reject, que es un rechazo y no una carpeta de spam. gmail.com está hoy en p=none, así que el correo no se rechaza por política, y aun así llega sin ninguna autenticación alineada justo cuando las propias reglas de Gmail para remitentes masivos piden exactamente eso. Ninguna de las dos es una posición desde la que enviar.

La misma trampa atrapa a quien usa un dominio que autenticó en una herramienta y olvidó en otra. La autenticación es por plataforma. Un dominio autenticado para Mailchimp no queda autenticado para el correo transaccional que sale por un servicio aparte, y esa es la razón por la que los recibos caen en spam mientras el boletín llega bien. La entrada sobre Amazon SES cubre la mitad transaccional de esa división.

Hagan esto: muevan la dirección From de la campaña a un dominio que controlen, y hagan la lista de todas las demás herramientas que envían bajo ese mismo dominio. Cada una necesita su propia firma.

Causa tres: la audiencia, y los números que de verdad influyen

Cuando la autenticación está en su lugar, las reacciones de los destinatarios deciden dónde cae el correo. Dos números llevan la mayor parte del peso: cuántas personas marcan el correo como spam, y cuántas direcciones rebotan.

Mailchimp no publica un umbral. Sus páginas de abuso y de suspensiones mencionan “umbrales de la industria” y avisos de advertencia sin dar una cifra, así que no hay una línea por debajo de la cual quedarse. Google sí publica uno. Las directrices para remitentes de Gmail esperan que la tasa de spam reportada en Postmaster Tools se mantenga por debajo del 0.1 por ciento y nunca llegue al 0.3 por ciento, y exigen SPF y DKIM, un registro DMARC alineado y baja en un clic de parte de quien envíe más de unos 5,000 mensajes por día a cuentas personales de Gmail. Mailchimp aporta el encabezado de baja. El resto depende de su dominio, y lo que Gmail y Yahoo realmente exigen merece una lectura si la audiencia es grande.

Los dos números vienen del mismo lugar: cómo se recolectó la audiencia. Una hoja de cálculo importada, una lista comprada a cualquiera, o un formulario de registro sin paso de confirmación generan quejas de personas que no los recuerdan, y esas quejas persiguen a su dominio en cada campaña futura. La reputación se recupera lento, y se recupera con el comportamiento de envío, no con disculpas.

Hagan esto: antes de la próxima campaña, eliminen cada rebote duro, archiven los contactos sin aperturas ni clics en los últimos seis meses, y verifiquen de dónde salió el segmento más antiguo de la audiencia.

Cómo verificar la corrección

Esperen a que el TTL del DNS expire, envíense una campaña y lean los encabezados otra vez. La línea dkim=pass debe nombrar su dominio y dmarc=pass debería seguirle. La línea spf=pass seguirá nombrando un dominio de Mailchimp, y aquí eso es lo esperado, no una falla.

Después lean los registros desde el DNS público en lugar del panel de Mailchimp. El chequeo de salud del correo gratuito resuelve sus registros SPF, DKIM, DMARC y MTA-STS como lo haría un receptor y revisa su dominio contra las listas de bloqueo en la misma pasada, lo que detecta el caso en que un registro se pegó con un error de tipeo al final y el panel reporta un éxito en caché.

Eso responde por un dominio, en el momento en que se hace la pregunta. Y ahí está la brecha real.

Nada en esta configuración avisa cuando se rompe. Una migración de DNS tira los dos CNAME y Mailchimp sigue enviando, sin firma, sin ningún error. El asistente de configuración de otra herramienta reemplaza el registro DMARC. Una campaña a un segmento viejo genera quejas un martes que les cuestan en silencio la bandeja de entrada por semanas. Los reportes de campaña siguen mostrando entrega, porque “entregado” significa que el receptor aceptó el mensaje, no que alguien lo vio.

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 fechado para rastrear una caída hasta el día en que empezó, y una alerta cuando algo cambia en lugar de un recordatorio para ir a mirar. 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 por si quieren ver el panel primero.

Si resulta que Mailchimp no es el problema, sigan con el diagnóstico completo de spam, que recorre las demás causas en orden de probabilidad. Creadores y negocios de cursos suelen topar con esto en un dominio que también corre una plataforma de cursos, un agendador y un procesador de pagos, cada uno firmando correo por su cuenta.

La lista de verificación

1. Envíense una campaña y lean los encabezados crudos.
2. Verifiquen qué dominio nombra la línea dkim=pass. Que nombre a Mailchimp significa que el dominio no está autenticado.
3. Inicien la autenticación en Mailchimp y publiquen los dos registros CNAME que entrega.
4. Publiquen un registro DMARC en p=none con una dirección rua y lean lo que llega.
5. Muevan la dirección From a un dominio que controlen si está en un servicio de buzón gratuito.
6. Hagan la lista de todas las demás plataformas que envían bajo ese dominio y autentiquen cada una.
7. Eliminen los rebotes duros y los contactos sin interacción en seis meses.
8. Vuelvan a leer los encabezados cuando el TTL expire y confirmen que la firma ahora nombra su dominio.