La misma persona recibió la misma campaña tres veces y luego nos marcó como spam
Cuando tu Subscriber Key es un CRM Contact ID en lugar de la dirección de email, una misma dirección puede existir bajo varias keys y SFMC trata cada una como un contacto distinto. Los envíos a Data Extension no deduplican por email a menos que lo actives, y los triggered sends nunca deduplican, así que una persona recibe la misma campaña una vez por cada registro, pulsa el botón de spam y el pico de quejas hace que Gmail y Yahoo te filtren.
La solución
Para los envíos a Data Extension, activa la opción Remove Duplicates en la selección de audiencia; viene desactivada por defecto y deduplica por dirección de email, cazando una misma dirección que aparece bajo varias SubscriberKeys dentro de ese envío. Los envíos a listas siempre deduplican de forma automática en el momento del envío, pero esta casilla no hace nada para las actividades de email de Journey Builder ni para los triggered sends, que no tienen deduplicación. El arreglo duradero está aguas arriba: estandariza en una única ContactKey/SubscriberKey estable, normaliza los duplicados en tu CRM o CDP para que cada persona sea un único registro maestro y audita la lista All Subscribers en busca del mismo email bajo varias keys.
Gmail empezó a filtrarnos en masa y resultó que nuestra promo estaba marcada como Transactional
Una Transactional Send Classification elimina por defecto el enlace visible de baja, el bloque con la dirección física y la cabecera de un clic List-Unsubscribe, lo cual es correcto para un recibo, pero un incumplimiento de normativa en cuanto el mensaje lleva contenido promocional. Los equipos clasifican mal el correo comercial como transaccional por un clic erróneo o para suprimir las bajas, y desde febrero de 2024 esa cabecera de un clic ausente activa las reglas de remitentes masivos de Gmail y Yahoo para quien supera los 5.000 mensajes al día.
La solución
Audita tus Send Classifications frente a lo que cada email contiene de verdad y envía todo lo promocional con una Commercial Send Classification. Una clasificación Commercial es lo que hace que Marketing Cloud añada el enlace visible de baja e inyecte las cabeceras List-Unsubscribe y de un clic List-Unsubscribe-Post, que van en todos los envíos comerciales y no se pueden desactivar. Por separado, confirma que el Delivery Profile usado en el envío tiene el contenido de cabecera/pie configurado con tu dirección física CAN-SPAM, ya que ese bloque viene del Delivery Profile, no de la clasificación. Restringe quién puede elegir la Send Classification y editar los Sender y Delivery Profiles, y reserva Transactional estrictamente para recibos genuinos, restablecimientos de contraseña y confirmaciones de pedido.
Nuestra entrega se desplomó y no tocamos nada: fue un desconocido en nuestra IP compartida
En el pool de IP compartida de SFMC tu reputación está fusionada con la de todos los demás inquilinos, así que un vecino ruidoso que dispara spam o rebotes provoca bloqueos B2C en Yahoo, AOL y Microsoft, y aplazamientos en Gmail incluso con una autenticación perfecta. El soporte confirmará que Deliverability y Abuse están trabajando en ello, pero no te dirá qué remitente es el culpable ni qué remediación está en marcha, y eso hace que parezca que no tiene solución.
La solución
Abre un caso y adjunta pruebas que separen tu envío del colapso del pool: registros de rebotes, códigos SMTP de aplazamiento y bloqueo, tu tasa de quejas y el estado en lista negra que demuestre que todo el rango se movió a la vez mientras tus métricas se mantenían estables. Escala a través del soporte y de tu equipo de cuenta, y pídeles que te muevan a un pool compartido más sano (algo que Salesforce concede a su discreción, así que trátalo como una petición) o que inicien tu migración a una IP dedicada a través de tu Account Executive. En el clásico Email Studio, calienta la nueva IP manualmente durante 4 a 6 semanas, empezando por unos 500 mensajes al día a tus suscriptores más comprometidos y subiendo el volumen de forma gradual mientras vigilas las quejas. En Marketing Cloud Next, Salesforce automatiza el calentamiento de la IP dedicada durante aproximadamente los primeros 35 días.
Tras migrar a Marketing Cloud, la entrega en Gmail pasó de ser instantánea a llegar con horas de retraso
Tras la migración, los remitentes en el pool compartido de SFMC informan de correo que se queda en cola o que Gmail aplaza una y otra vez, así que los mensajes llegan con horas de retraso aunque SPF, DKIM y DMARC pasen todos. Gmail somete a un escrutinio extra el gran volumen de marketing de la IP compartida, y el correo transaccional urgente encolado detrás de las campañas masivas se ralentiza con él.
La solución
Extrae las cabeceras completas del email y lee las marcas de tiempo Received de abajo arriba para demostrar dónde está el retraso, en SFMC antes del traspaso o en Gmail aplazando una y otra vez con un 4xx, en lugar de adivinar. Confirma un aplazamiento del lado de Gmail contra la reputación de tu dominio y tu IP en Google Postmaster Tools, ya que Marketing Cloud no muestra los motivos de aplazamiento. Si el correo transaccional es la víctima, sepáralo en su propio subdominio y enrutamiento, un Sender Profile distinto y una Send Classification transaccional, y con volumen suficiente una IP dedicada o la Transactional Messaging API, para que no quede atascado detrás de las colas de campañas. Si es el propio pool compartido el que aplaza, escala a Salesforce para un cambio de pool o una IP dedicada, y confirma que no estás calentando una IP nueva hacia el volumen completo demasiado rápido.
Los User-Initiated Sends de Marketing Cloud van a spam mientras que los emails de Journey llegan casi siempre a la bandeja de entrada
Los remitentes con SPF, DKIM y DMARC todos configurados siguen viendo cómo los User-Initiated Sends caen en spam, y algunos emails de Journey van detrás. Los User-Initiated Sends suelen dirigirse a destinatarios inactivos o molestos, lo que arrastra rápido la reputación del dominio, y ese daño se contagia a los Journeys que comparten el mismo dominio e IP de envío.
La solución
Esto no es un problema de configuración de autenticación, es un problema de reputación y de audiencia. Comprueba la alineación, no solo la configuración: SPF y DKIM pueden pasar mientras el dominio From visible, el Return-Path y el dominio de firma están desalineados, algo que los proveedores siguen tratando como de mayor riesgo. Suprime a los destinatarios no comprometidos en los User-Initiated Sends y elimina los contactos que se registraron hace meses y nunca abrieron, para que esos envíos dejen de generar quejas que se filtran a tus Journeys. Mantén el contenido de las plantillas breve y con un propósito claro, y si estás en una IP dedicada envía de forma constante, ya que los huecos de volumen reinician la reputación de tu remitente.
