Soluciona los correos de Pardot (Account Engagement) que van a spam

Marketing Cloud Account Engagement, todavía etiquetado como Pardot en buena parte de la aplicación, es un producto distinto de Marketing Cloud Engagement y se autentica de una forma completamente diferente. Verifica tu dominio de envío con una clave de validación que demuestra la propiedad y nada más, trata DKIM como opcional y enruta cada rebote por un host de Salesforce como bounce.s7.exacttarget.com, así que SPF no se alinea con tu dirección de remitente salvo que solicites una ruta de retorno personalizada. Esta guía cubre el registro DomainKey en 200608._domainkey, el CNAME del dominio rastreador que reescribe todos los enlaces de tu correo, la ruta de retorno personalizada para la que tienes que abrir un caso, y cómo probar un envío real de Account Engagement con Unspam.

Haz una prueba antispam gratis Cómo probar tus envíos

Por qué los emails de Marketing Cloud Account Engagement acaban en spam.

Account Engagement nunca exigió DKIM, así que la mayoría de las cuentas no tiene ningún identificador alineado

Salesforce verifica un dominio de envío con un registro TXT de clave de validación, y esa clave por sí sola basta para enviar: la documentación indica que Account Engagement no exige actualmente un registro DKIM verificado en el dominio de envío de correo y solo lo recomienda encarecidamente. DKIM es el único identificador que se alinea con tu dirección de remitente de fábrica, porque la ruta de retorno se queda en un host de Salesforce salvo que abras un caso de soporte para una ruta de retorno personalizada. Sin el registro TXT DomainKey publicado en 200608._domainkey.tudominio.com, una evaluación DMARC no tiene nada alineado con lo que pasar, y una política p=quarantine o p=reject en tu propio dominio filtra entonces tus propias campañas. Domain Management sigue mostrando el dominio como verificado en cualquier caso, y por eso hay tantos dominios verificados completamente sin autenticar.

SPF pasa para Salesforce, nunca para ti

Salesforce documenta que los correos de Account Engagement pasan SPF automáticamente porque Salesforce controla la infraestructura de envío, y que no hace falta ninguna configuración SPF concreta por tu parte. El servidor receptor comprueba la ruta de retorno, que Salesforce documenta como un host del tipo bounce.s7.exacttarget.com, bounce.s10.mc.pd25.com o bounce.j.s11.pdmailservice.com, así que el pase se registra contra un dominio de Salesforce y la alineación SPF falla en cada envío. Añadir un include de Salesforce a tu registro SPF raíz no cambia nada de eso. La única forma de alinear la ruta de retorno es una ruta de retorno personalizada, que Salesforce aprovisiona mediante un caso de soporte y no desde ninguna pantalla del producto.

Todos los enlaces del correo siguen apuntando a pardot.com

Account Engagement reescribe los enlaces y las URL personalizadas a través del dominio rastreador y, cuando ningún dominio rastreador está seleccionado en un recurso, recurre al dominio rastreador principal de la cuenta. Una cuenta que nunca validó su propio CNAME sirve todo eso desde el dominio por defecto go.pardot.com, de modo que un mensaje que lleva tu marca en el remitente lleva enlaces en un dominio en el que el destinatario no tiene motivo alguno para confiar. Salesforce recomienda añadir un dominio propio y servir todo el contenido de Account Engagement desde él. Una vez que validas tu propio dominio rastreador y usas Set as Primary, Account Engagement reescribe las URL de tus recursos hacia él.

La jerarquía de remitentes envía desde dominios que nunca configuraste

En Account Engagement la dirección de correo del remitente decide qué dominio de envío se usa, así que una campaña configurada con Assigned User, Account Owner o un campo de usuario del CRM sale desde la dirección de cada comercial. En el momento del envío, Salesforce recorre la jerarquía de remitentes de arriba abajo y usa la primera dirección cuyo dominio esté verificado, y si ningún remitente de la jerarquía es válido el envío falla directamente. Una misma campaña puede salir, por tanto, con varios dominios de remitente, de los que solo algunos llevan un registro DomainKey, lo que divide tu reputación y manda la parte sin firmar a spam. Cada dominio desde el que envíen tus usuarios necesita su propia entrada en Domain Management con los dos registros publicados.

Estás juzgando la entregabilidad con pruebas que no son correos reales

Salesforce documenta que la opción puntual Send to Individual Emails no produce un mensaje MIME multiparte: las versiones HTML y de texto plano salen como dos mensajes separados, y muchos sistemas de correo lo tratan como sospechoso. El mismo artículo advierte de que repetir envíos de prueba individuales puede provocar que se aplique greylisting al remitente, nombrando en particular a Microsoft, con aplazamientos de varias horas, y afirma sin rodeos que las pruebas de correo no deben usarse como medida de entregabilidad. Si tu única evidencia es una prueba enviada a tu propia dirección de trabajo, estás midiendo un artefacto de la herramienta de pruebas. Una dirección corporativa en ambos extremos añade un segundo fallo, porque el filtro clasifica como interno el correo entre dos direcciones de tu dominio y luego lo ve llegar desde un servidor externo.

Aplicaste instrucciones de Marketing Cloud Engagement a una cuenta de Pardot

Marketing Cloud Engagement y Marketing Cloud Account Engagement son productos distintos con rutas de autenticación distintas, y los nombres se parecen lo suficiente como para que los equipos sigan el manual equivocado durante meses. En Account Engagement no existen Sender Authentication Package, Private Domain ni Reply Mail Management. La autenticación vive en Account Engagement Settings y luego Domain Management: una clave de validación, un registro DomainKey y un CNAME de dominio rastreador apuntando a go.pardot.com. Comprar SAP para una organización de Marketing Cloud Engagement no hace nada por el correo que envía tu unidad de negocio de Account Engagement, así que confirma qué producto envió realmente el mensaje antes de gastar un trimestre configurando el otro.

Cómo autentica Marketing Cloud Account Engagement tu correo.

Account Engagement mantiene separados cuatro hechos de DNS que la mayoría de los equipos trata como uno. La clave de validación demuestra que eres el propietario del dominio y es el único registro necesario para enviar. El registro DomainKey es lo que firma de verdad tu correo. SPF es de Salesforce, no tuyo. DMARC es solo tuyo, porque Salesforce declara que Account Engagement no puede aportar autenticación DMARC y que el soporte no puede ayudar a configurarla. Solo dos de los cuatro salen del producto: Account Engagement Settings, luego Domain Management y luego el enlace Expected DNS Entries junto al dominio, que contiene la clave de validación y el DomainKey. Salesforce no aporta ningún valor de SPF ni de DMARC. Al margen de todo esto, el dominio rastreador es un CNAME a go.pardot.com y nunca debe ser el mismo dominio que tu dominio de envío de correo. Comprueba cada registro con los verificadores de SPF, DKIM y DMARC de Unspam antes y después del cambio.

registro	por defecto	el problema	la solución
Validation key (TXT)	No se publica nada hasta que añades el dominio. Desde el 1 de julio de 2023, un dominio tiene que estar verificado con una clave de validación para que Account Engagement envíe desde él. Los dominios que ya se habían verificado mediante DKIM con el método anterior conservaron su estado sin la clave nueva.	Un dominio verificado no es un dominio autenticado. El estado verificado en Domain Management significa únicamente que demostraste la propiedad, y los equipos se detienen ahí creyendo que la autenticación está terminada. Mantén el registro TXT publicado, ya que es el registro contra el que Account Engagement comprueba la propiedad del dominio.	En Account Engagement Settings, abre Domain Management, haz clic en Add New Domain, luego en Expected DNS Entries en la columna Actions y copia la clave de validación. Publícala como registro TXT en ese dominio o en uno superior y haz clic en Check DNS Entries para verificar. Deja el registro publicado de forma permanente.
DKIM (DomainKey)	Desactivado hasta que lo publiques. Salesforce declara que Account Engagement no exige actualmente un registro DKIM verificado para enviar desde un dominio de envío de correo, y solo lo recomienda encarecidamente. La clave que emite Account Engagement es de 1024 bits por defecto.	DKIM es el único identificador que Account Engagement puede alinear con tu dominio de remitente, así que sin él una evaluación DMARC no tiene nada con lo que pasar y las expectativas de Gmail y Yahoo para remitentes masivos quedan sin cumplir. El fallo es invisible dentro del producto, porque Domain Management informa del dominio como verificado con o sin DomainKey.	En Domain Management, abre Expected DNS Entries del dominio, copia el valor DomainKey y publícalo como registro TXT en 200608._domainkey.tudominio.com. En proveedores que añaden la zona a lo que escribas, GoDaddy entre ellos, introduce solo la parte del host o el registro se propaga con tu dominio duplicado. Deja pasar hasta 24 horas para que la firma surta efecto y confirma después el valor d= en un envío real con el verificador DKIM de Unspam.
SPF	Lo configura Salesforce, no tú. La documentación dice que los correos de Account Engagement pasan SPF automáticamente y que no hace falta ninguna configuración SPF concreta por tu parte, y Domain Management refleja ese pase.	El pase se registra contra la ruta de retorno, que Salesforce documenta como bounce.s7.exacttarget.com, bounce.s10.mc.pd25.com o bounce.j.s11.pdmailservice.com según la cuenta. Ninguno de esos es tu dominio, así que la alineación SPF falla en cada envío de Account Engagement y DMARC no puede apoyarse en ella.	Mantén válido tu propio registro SPF para tus otros remitentes y confírmalo con el verificador SPF de Unspam, pero no esperes que ayude a Account Engagement. Para la alineación, abre un caso de soporte de Account Engagement y solicita una ruta de retorno personalizada. Salesforce facilita los registros DNS y te deja publicarlos, y solo puede haber un dominio de ruta de retorno personalizada por unidad de negocio, sin variación por envío.
DMARC	Ausente salvo que lo publiques. Salesforce es explícito en que Account Engagement no puede aportar autenticación DMARC, en que la configuración vive fuera del producto y en que el soporte no puede ayudar a montarla.	Con el DomainKey publicado, DMARC pasa solo con la alineación DKIM, que es a lo que se refiere Salesforce cuando dice que DMARC funciona con Account Engagement de fábrica. Sin él no se alinea ningún identificador y una política p=quarantine o p=reject en tu propio dominio pone en cuarentena tus propias campañas. Account Engagement tampoco captura ni informa de los fallos DMARC, así que nada en la aplicación te lo dirá.	Publica v=DMARC1; p=none; rua=mailto:dmarc@tudominio.com en _dmarc.tudominio.com, confirma en un envío real que DKIM se alinea con tu dominio de remitente y endurece después a quarantine y más tarde a reject cuando tus informes salgan limpios. Salesforce recomienda apoyarse en un proveedor externo para los informes DMARC porque no captura ninguno. Verifica el registro publicado con el verificador DMARC de Unspam.

Una vez actualizados estos registros, confirma que pasan con el comprobador de SPF, el comprobador de DKIM y el comprobador de DMARC gratuitos de Unspam.

Cómo probar una campaña de Marketing Cloud Account Engagement con Unspam.

Account Engagement tiene dos pruebas integradas y ninguna mide la ubicación. La pestaña Testing del editor clásico ejecuta previsualizaciones de renderizado de Litmus y un análisis antispam, y Salesforce dice que los resultados no garantizan si un correo acaba en la carpeta de spam. El envío de prueba del editor Lightning elimina los datos de los campos de combinación y, si el dominio del usuario que ha iniciado sesión no está verificado, sustituye tu dirección de remitente por test@ seguido de tu primer dominio de envío verificado. Unspam no se conecta a la API de Account Engagement ni a ninguna otra cuenta de plataforma, así que la prueba honesta es un correo de lista real enviado a una dirección semilla desde tu dominio de envío y tu dominio rastreador habituales.

01
Consigue tu dirección semilla de Unspam y el Test ID

Inicia una prueba antispam gratuita o una prueba de ubicación en bandeja de entrada en Unspam y copia la dirección semilla que genera. Una prueba de ubicación entrega en buzones semilla de Gmail, Outlook, Yahoo, Zoho, ProtonMail, AOL, GMX y Amazon WorkMail para que veas dónde aterrizó cada copia. También emite un Test ID, y tienes que pegar ese ID en el asunto o en el cuerpo antes de enviar. Si lo omites, el mensaje llega igualmente a los buzones semilla, pero nunca queda vinculado a tu prueba.
02
Añade la semilla como prospect en una lista normal

No recurras a una Email Test List. Account Engagement las construye a partir de tus propios usuarios, creando un prospect de prueba por cada uno, hasta 100 destinatarios, así que una dirección semilla externa no puede entrar en una. Crea la semilla como prospect y añádela a una lista de segmentación con un nombre del tipo Deliverability Seed, para que el mensaje siga exactamente el camino que sigue una campaña.
03
Envíalo como correo de lista real, no como prueba

Envía el correo de verdad a esa lista desde Account Engagement Email, con tu remitente de producción y el mismo dominio rastreador que usan tus campañas. Evita la opción Send to Individual Emails de la pestaña Testing: Salesforce documenta que divide el HTML y el texto plano en dos mensajes separados en lugar de un único mensaje MIME multiparte, y dice que las pruebas de correo no deben usarse como medida de entregabilidad.
04
Comprueba qué salió realmente de Account Engagement

En Unspam, confirma que el valor d= de DKIM es tu dominio de envío y no un host de Salesforce, que la ruta de retorno es la que esperas (un host del estilo bounce.s7.exacttarget.com salvo que tengas ruta de retorno personalizada) y que todos los enlaces resuelven en tu dominio rastreador y no en pardot.com. Este es el primer punto del flujo en el que ves las mismas cabeceras que ve un proveedor de correo.
05
Lee los resultados y corrige antes de la siguiente campaña

Revisa la puntuación antispam, los veredictos de SPF, DKIM y DMARC medidos en el envío real, las comprobaciones de listas negras y de HTML, la ubicación por proveedor en Bandeja de entrada, Promociones, Spam o Perdido, las vistas previas por cliente incluido el modo oscuro, y el mapa de calor de seguimiento ocular con IA. Cambia una sola cosa, envía otra vez y podrás atribuir la diferencia en lugar de adivinarla.

La misma prueba renderiza tu campaña en más de 50 clientes de correo reales, entre ellos Gmail, Outlook, Apple Mail, iPhone y Android, cada uno en modo claro y oscuro, mediante vistas previas en clientes de correo, para que confirmes la llegada a la bandeja de entrada y el renderizado de una sola vez.

Funciones de Marketing Cloud Account Engagement que afectan a la entrega sin que lo notes.

Verificado no es autenticado

Domain Management marca un dominio como verificado en cuanto resuelve el registro TXT de la clave de validación, y ese es el único registro que Account Engagement necesita para enviar. DKIM está en la misma pantalla Expected DNS Entries y solo se recomienda. Hay cuentas que funcionan durante años en ese estado, verificadas y sin firmar jamás un mensaje con su propio dominio. Abre Expected DNS Entries y busca la línea DomainKey en concreto en lugar de fiarte de la etiqueta verificado.

Los envíos de prueba individuales no son MIME multiparte

Salesforce documenta que la opción Send to Individual Emails entrega el HTML y el texto plano como dos mensajes separados en lugar de un único mensaje MIME multiparte, que muchos sistemas de correo lo tratan como sospechoso y que su uso repetido puede provocar greylisting del remitente, con Microsoft nombrado específicamente y aplazamientos de horas. Si tu evidencia de entregabilidad salió de ese botón, es evidencia sobre el botón. Salesforce recomienda listas de prueba en su lugar, y un envío real a una semilla externa supera a las dos cosas.

El dominio rastreador y el dominio de envío de correo tienen que ser distintos

Salesforce declara que usar el mismo dominio para ambas funciones provocará probablemente errores de autenticación y problemas de entregabilidad. Si go.empresa.com es tu dominio rastreador, no puede ser además tu dominio de envío de correo. Los dominios rastreadores también tienen que ser únicos entre unidades de negocio, así que una segunda unidad necesita algo como go2.empresa.com y no un duplicado del primero.

La historia de la clave DKIM de 2048 bits es contradictoria

Account Engagement emite un DomainKey de 1024 bits por defecto. La guía de configuración de DNS dice que puedes abrir un caso de soporte para pedir una clave de 2048 bits y califica de muy recomendable una IP de envío dedicada antes de hacerlo. Salesforce describe después el resultado de dos formas distintas. Un artículo dice que una clave de 2048 bits produce una advertencia Custom DKIM Entry en la tabla Email Sending Domain y que no hace falta nada más mientras tus entradas de DNS sigan publicadas. Otro dice que quienes usen una clave de 2048 bits no verán su dominio de envío con DKIM verificado en Account Engagement aunque el registro esté presente en DNS. Trata el indicador de verificación de la aplicación como poco fiable a 2048 bits y confirma la firma en un envío real.

Con qué se encuentran los remitentes reales de Marketing Cloud Account Engagement.

Los problemas de entregabilidad que más sufren los remitentes de Marketing Cloud Account Engagement, cada uno con la solución que lo resuelve.

Nuestros correos de prueba acaban una y otra vez en no deseados, pero el soporte de Salesforce dice que la cuenta no tiene nada mal

Si probaste con Send to Individual Emails desde la pestaña Testing, la propia documentación de Salesforce dice que esas pruebas no son mensajes MIME multiparte: el HTML y el texto plano salen como dos mensajes separados, y muchos sistemas de correo lo tratan como sospechoso. Usar una dirección corporativa en ambos extremos apila un segundo fallo encima, porque el filtro clasifica como interno el correo entre dos direcciones de tu dominio y luego lo ve llegar desde un servidor de terceros fuera de tu red. Salesforce afirma abiertamente que las pruebas de correo no deben usarse como medida de entregabilidad.

La solución Deja de probar con pruebas individuales. Pide a IT que incluya en la lista blanca tu IP de envío de Account Engagement, que encuentras en Account Engagement Settings, en Account Information, en el campo Sending IPs, para que las pruebas internas dejen de activar la regla de red interna. Mide después la ubicación con un correo de lista real a una dirección semilla externa en lugar de a un compañero de tu propio dominio, y lee las cabeceras de ese envío. Ten en cuenta que una tanda de pruebas individuales puede provocarte greylisting, sobre todo en Microsoft, lo que hace que el siguiente envío real parezca peor de lo que es.

La newsletter llega a la bandeja de entrada, pero cualquier cosa enviada desde un comercial va directa a spam

Las campañas configuradas con Assigned User, Account Owner o un campo personalizado de usuario del CRM toman la dirección de remitente del registro de usuario, así que el dominio de envío cambia de prospect a prospect. Salesforce evalúa la jerarquía de remitentes de arriba abajo en el momento del envío y usa la primera dirección cuyo dominio esté verificado, lo que significa que un dominio de comercial sin verificar cae en silencio hacia lo siguiente, y si nada de la jerarquía es válido el envío falla. Los dominios que nunca añadiste en Domain Management no tienen registro DomainKey, así que esos mensajes salen sin firmar mientras tu dominio de marketing sí lo está.

La solución Enumera todos los dominios desde los que envían tus usuarios y añade cada uno en Account Engagement Settings, Domain Management, con la clave de validación y el registro DomainKey publicados. Donde los comerciales estén en un dominio que no puedas autenticar, pon como última entrada de la jerarquía de remitentes un General User o un Specific User de un dominio verificado, y lleva el toque humano a la dirección de respuesta en lugar de al remitente. Envía después desde cada dominio a una dirección semilla y confirma que el valor d= de DKIM coincide antes de fiarte.

Añadí el DomainKey hace una semana y Account Engagement sigue sin mostrar DKIM como verificado

El registro DomainKey tiene que vivir en 200608._domainkey.tudominio.com, y los proveedores de DNS que añaden la zona a lo que escribes convierten eso en un nombre de host duplicado que no resuelve en ninguna parte. Salesforce menciona a GoDaddy por su nombre por este comportamiento. La firma tampoco empieza en el momento en que el registro resuelve: la documentación pide hasta 24 horas desde que el registro está publicado. Y si alguien pidió una clave de 2048 bits, Salesforce advierte de que el dominio no mostrará DKIM como verificado en la aplicación en absoluto, incluso con un registro correcto en DNS.

La solución Consulta el registro directamente en lugar de fiarte de la aplicación: busca 200608._domainkey.tudominio.com y comprueba que recibes un único registro TXT que coincide con el valor de Expected DNS Entries, sin dominio duplicado y sin entradas repetidas. Si tu proveedor añade la zona, introduce solo la parte del host. Da a la firma 24 horas completas, envía después a una dirección semilla y lee el valor d= del mensaje entregado, que es la única comprobación que refleja lo que ven los proveedores de correo.

Nuestro propio equipo de IT marcó la campaña como phishing porque todos los enlaces iban a pardot.com

Account Engagement reescribe los enlaces y las URL personalizadas a través del dominio rastreador y, cuando no se elige ningún dominio rastreador en el recurso, usa el dominio rastreador principal de la cuenta. Una cuenta que nunca validó su propio CNAME sirve todo eso desde el dominio por defecto go.pardot.com, así que el remitente dice tu marca y cada href dice otra cosa, que es exactamente la forma con la que se entrena a un filtro de phishing. Salesforce recomienda añadir un dominio propio y servir todo el contenido de Account Engagement desde él.

La solución Añade un dominio rastreador en Domain Management, apunta el CNAME a go.pardot.com en producción o a go.demo.pardot.com en un sandbox, publica la clave de validación como registro TXT en tu dominio raíz o sube el archivo de validación pardot_XXXXXX.txt a la raíz de tu web, y valídalo después y elige Set as Primary. Eso reescribe las URL de tus recursos de Account Engagement hacia el nuevo dominio. Elige un subdominio que no sea tu dominio de envío de correo, ya que Salesforce advierte de que reutilizar un mismo dominio para ambas cosas causa errores de autenticación, y confirma en un envío semilla que no sobrevive ningún enlace a pardot.com.

Una parte de nuestra lista dejó de recibir correos sin más y nadie se dio de baja

Account Engagement marca un prospect como Undeliverable tras un único rebote duro, o tras cinco rebotes blandos, y lo suprime de todos los envíos posteriores. La trampa está dentro de la propia definición de rebote duro de Salesforce: algunos servidores de correo devuelven un rebote duro cuando sospechan que el mensaje es spam. Así que una temporada con la autenticación rota no solo te empuja a la carpeta de spam, sino que convierte a destinatarios filtrados en prospects suprimidos de forma permanente, y la lista sigue encogiendo mucho después de que el problema de fondo esté resuelto.

La solución Arregla primero la autenticación y trabaja después hacia atrás sobre los registros de rebote: Account Engagement te deja restablecer el contador de rebotes duros o blandos en el registro del prospect una vez resuelta la causa. Alinea el pico de rebotes con las fechas en las que cambiaste el DNS o los ajustes de remitente para separar una dirección realmente mala de una filtrada. De cara al futuro, mantén las tasas de rebote muy por debajo del 10% por envío que, según advierte Salesforce, puede dañar tu entregabilidad, y las quejas por debajo del 0,3% que aplica Gmail, y reconstruye el volumen de forma gradual si has pausado los envíos más de una semana.

La entregabilidad en Marketing Cloud Account Engagement, tus dudas resueltas.

¿Marketing Cloud Account Engagement es lo mismo que Marketing Cloud Engagement?

No. Son productos distintos con rutas de autenticación distintas, y esa es la razón más común de que un arreglo de Pardot no lleve a ninguna parte. Account Engagement es el producto que antes se llamaba Pardot, y Salesforce sigue mostrando el nombre antiguo en partes de la aplicación. Su autenticación vive en Account Engagement Settings y luego Domain Management: una clave de validación, un registro TXT DomainKey y un CNAME de dominio rastreador a go.pardot.com. Marketing Cloud Engagement usa el Sender Authentication Package y Private Domain, y aquí no existe ninguno de los dos.

¿Tengo que añadir Salesforce a mi registro SPF para Account Engagement?

No. Salesforce documenta que el correo de Account Engagement pasa SPF automáticamente porque Salesforce controla la infraestructura de envío, y que no hace falta ninguna configuración SPF concreta por tu parte. Un include tampoco ayudaría, porque la comprobación se hace contra la ruta de retorno de Salesforce y no contra tu dominio de remitente. Mantén tu propio registro SPF correcto para tus otros remitentes y apóyate en DKIM para la alineación DMARC.

¿Por qué parece que mi correo de Account Engagement viene de un dominio de Salesforce?

La ruta de retorno en los envíos de Account Engagement es un host de Salesforce. Salesforce documenta ejemplos como bounce.s7.exacttarget.com, bounce.s10.mc.pd25.com y bounce.j.s11.pdmailservice.com, y dice que la información de la ruta de retorno no se puede eliminar. Gmail muestra la discrepancia como una línea via. Publicar el registro DomainKey hace que DKIM firme con tu propio dominio, que es lo que DMARC necesita y lo que suele quitar la línea via, y una ruta de retorno personalizada solicitada por soporte alinea el propio sobre.

¿Cómo consigo alineación SPF en Account Engagement?

Abre un caso de soporte de Account Engagement y pide una ruta de retorno personalizada. Salesforce trabaja con su equipo de entregabilidad para darte los registros DNS que tienes que publicar y no configura tu DNS por ti. Solo puede haber un dominio de ruta de retorno personalizada por unidad de negocio y no varía por envío. Salesforce deja claro que esto añade alineación de dominio SPF para reforzar una política DMARC existente, no para sustituir a DKIM, así que publica primero el DomainKey.

¿El análisis antispam de la pestaña Testing me dice si voy a llegar a la bandeja de entrada?

No, y Salesforce lo dice. Las pruebas de renderizado y el análisis antispam de la pestaña Testing del editor clásico funcionan con Litmus, y Salesforce declara que los resultados no garantizan si los correos acaban en la carpeta de spam, porque la reputación del remitente no es algo que un análisis de contenido pueda ver. La función llega con el paquete Advanced Email Analytics, en las ediciones Plus, Advanced y Premium y con coste adicional en Growth, y cada renderizado se guarda 90 días. Úsalo para el renderizado y el contenido, y mide la ubicación con un envío real.

¿Puede Unspam conectarse a mi cuenta de Account Engagement y probar los envíos automáticamente?

No. Unspam no se integra con la API de Account Engagement ni con la API de ninguna otra plataforma, y nunca se conecta a tu cuenta. Los dos puntos de integración son una dirección semilla a la que envías y, para las pruebas automatizadas, unas credenciales SMTP que aportas tú. Para Account Engagement eso significa añadir la semilla como prospect y lanzar un correo de lista real, que es la única manera de ver las cabeceras, los enlaces reescritos del dominio rastreador y la ubicación que reciben de verdad tus prospects.

Los detalles de la plataforma Marketing Cloud Account Engagement se verificaron con la documentación disponible públicamente en agosto de 2026 y pueden haber cambiado desde entonces. Marketing Cloud Account Engagement es una marca comercial de su respectivo propietario. Unspam no está afiliada a Marketing Cloud Account Engagement ni cuenta con su respaldo.

Prueba tu próxima campaña de Marketing Cloud Account Engagement antes de que lo hagan tus suscriptores.

Empieza una prueba antispam gratis Prueba de Inbox Placement