¿Tengo que agregar el include de SPF de mi plataforma?

Por lo general no, y con Mailchimp de plano no ayuda. La documentación de Mailchimp indica que agregar su include no se necesita para autenticar y no da alineación DMARC, porque el remitente del sobre se queda en un dominio de Mailchimp. Lo que produce alineación es que DKIM firme con tu propio dominio. Además, cada include gasta una de las diez consultas DNS que el RFC 7208 permite antes de que SPF devuelva permerror.

¿Por qué mi reporte muestra SPF pasando y DMARC fallando?

Porque pasar y alinear son dos pruebas distintas. Una plataforma de marketing envía desde su propia infraestructura con su propio dominio en el remitente del sobre, así que el SPF de ese dominio valida correctamente. Luego DMARC compara ese dominio con el de tu campo De, ve que no coinciden y toma SPF como no alineado. Klaviyo documenta este comportamiento de forma explícita para sus envíos. La solución es DKIM firmado con tu dominio, no más SPF.

¿Puedo usar alineación DMARC estricta con HubSpot?

Solo si tu dominio de envío es un subdominio. HubSpot indica que con alineación estricta un return path personalizado funciona para una dirección como user@mail.company.com pero no para user@company.com. HubSpot recomienda dejar adkim y aspf en r, es decir alineación relajada, que es el valor sensato para la mayoría de las pymes porque permite que los remitentes en subdominio alineen con el dominio raíz.

Mailchimp, HubSpot y Klaviyo: alineación DMARC

El rebote con el que empieza esta llamada

Un cliente nos reenvía una captura. Salió el boletín del mes y una buena parte se devolvió. El texto está bien, la lista está limpia, y esas mismas personas reciben correo del mismo dominio todos los días sin problema. Lo único que cambió es que ahora el boletín sale por una plataforma de marketing, y el dominio por fin tiene una política DMARC con dientes.

Casi siempre esto no es un problema de reputación ni de contenido. Es de alineación. La plataforma autenticó el mensaje perfectamente, usando su propio dominio, y DMARC hizo otra pregunta: ¿algo de eso coincide con la dirección que el lector ve en el campo De?

Mailchimp, HubSpot y Klaviyo rompen esto cada uno a su manera, y cada uno tiene un arreglo específico. Así lo resolvemos en un proyecto de cliente.

Alineación, en un párrafo

SPF revisa el remitente del sobre, esa dirección oculta a la que llegan los rebotes. DKIM revisa la firma y el dominio de su etiqueta d=. DMARC ignora esos dos resultados por separado y pregunta si alguno de los dos coincide con el dominio del campo De que sí se ve. El RFC 7489 llama a esto Identifier Alignment, y tiene dos modos: relajado, donde basta con que coincidan los dominios organizacionales, así que un subdominio cuenta; y estricto, donde solo sirve una coincidencia exacta de DNS. Basta con que uno de los dos, SPF o DKIM, pase y además alinee. Las guías para remitentes de Gmail dicen lo mismo para envíos masivos: el dominio del De tiene que estar alineado con el dominio de SPF o con el de DKIM.

Ahora la parte que explica las tres plataformas de una sola vez. Una plataforma de marketing envía desde su propia infraestructura, así que usa su propio dominio como remitente del sobre. SPF pasa, porque el dominio de la plataforma tiene un registro SPF válido, y luego falla la alineación, porque ese dominio no es el tuyo. DKIM es donde ganas. Todos los arreglos de abajo son en el fondo el mismo arreglo: lograr que la plataforma firme con un d= dentro de tu dominio.

Qué revisamos antes de tocar el DNS

Adivinar cuesta una semana de propagación, así que arrancamos con evidencia.

Sacar un mensaje real que haya enviado la plataforma, abrir las cabeceras completas y leer la línea Authentication-Results. El valor de d= te dice de inmediato si la firma es tuya o del proveedor. Nuestro analizador de cabeceras lo hace con un solo pegado.
Confirmar la dirección exacta del De que usan las campañas, incluyendo si está en el dominio raíz o en un subdominio. Ese detalle decide qué se puede hacer después.
Revisar dentro de la plataforma si alguna vez se configuró un dominio de envío, o si sigue con el predeterminado del proveedor.
Bajar las últimas dos semanas de reportes agregados DMARC, para ver todos los remitentes juntos y no solo el que se quejó.

Hasta ahí abrimos el panel de DNS.

Mailchimp: dos CNAME, y el include de SPF que no sirve de nada

La autenticación de dominio en Mailchimp son dos registros CNAME para DKIM más un registro TXT para DMARC. En la aplicación te da un Name (Host) y un Value para CNAME 1 y CNAME 2. Cópialos desde ahí en lugar de escribir a mano un selector que viste en un artículo, porque ese par se genera para tu dominio.

La trampa es SPF. Mailchimp publica un include, include:servers.mcsv.net, y medio internet sigue diciendo que hay que agregarlo. La documentación de Mailchimp es directa: agregar ese include no se necesita para autenticar con Mailchimp y no da alineación DMARC, porque Mailchimp envía desde sus propios servidores, así que el remitente del sobre no coincide con tu dirección del De. Los CNAME son los que te dan la alineación. El include solo gasta una de tus diez consultas DNS.

La falla que más encontramos en dominios de clientes: alguien agregó el include de SPF hace años, dio el tema por resuelto y nunca agregó los CNAME de DKIM. SPF pasa, nada alinea, y el día que DMARC sale de p=none el boletín empieza a rebotar.

Vale la pena separar una cosa más. Mailchimp Transactional, el producto que antes era Mandrill, se configura aparte, con sus propios dominios de envío y su propia opción de return path. Arreglar el lado de marketing no arregla los recibos ni los restablecimientos de contraseña que salen por el lado transaccional. Revisamos los dos.

HubSpot: conecta el dominio de envío y lee la nota del modo estricto

HubSpot pide que conectes un dominio de envío de correo, lo que configura DKIM con dos registros CNAME, un TXT de SPF, un TXT de DMARC y un subdominio que carga el return path. La documentación de HubSpot explica por qué importa lo último: los rebotes llegan al subdominio que conectas como return path, y eso es lo que permite alineación de SPF y no solamente un SPF que pasa.

Aquí hay una nota al pie que cuesta un día entero si se te pasa. HubSpot indica que con alineación DMARC estricta, un return path personalizado solo funciona si tu dominio de envío es un subdominio. Enviar como user@mail.company.com sirve. Enviar como user@company.com no. La recomendación de HubSpot es dejar las dos banderas de alineación en relajado:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; adkim=r; aspf=r; rua=mailto:dmarc@example.com"

Relajado es el valor correcto para casi cualquier pyme, porque deja que un remitente en subdominio alinee con el dominio raíz. El modo estricto es algo a lo que llegas después, cuando ya conoces a cada remitente por nombre.

Hay además una falla estética que se ve poco profesional mucho antes de que DMARC entre en el tema. Si envías desde un dominio que nunca se conectó, HubSpot reescribe la dirección hacia uno de sus dominios administrados, así que el destinatario ve algo con la forma user=yourcompany.com@hs-domain.com. Nadie le responde a eso. Si un cliente nos muestra esa dirección en el De, ya sabemos que el dominio de envío nunca se conectó y empezamos por ahí.

Klaviyo: salte del dominio de envío compartido

Las cuentas de Klaviyo arrancan enviando desde un dominio compartido de Klaviyo, que ya trae registros SPF y DKIM válidos. Los mensajes están bien autenticados. Están autenticados como Klaviyo. Tu dirección del De no participa en esa firma, así que en cuanto tu dominio aplique DMARC, esas campañas fallan.

El arreglo es un dominio de envío de marca, que Klaviyo también llama dominio de envío dedicado. Eliges un subdominio sin usar, algo como send para marketing o updates para transaccional, y Klaviyo genera los registros. Hay dos opciones de enrutamiento y dan trabajo de DNS distinto:

Enrutamiento dinámico con registros NS. Delegas el subdominio a Klaviyo, que administra los registros dentro de él. Klaviyo recomienda esta opción por rendimiento de envío.
Enrutamiento estático con registros CNAME, que es la opción cuando tu proveedor de DNS no puede alojar registros NS para un subdominio.

Klaviyo describe el conjunto como hasta tres registros CNAME o cuatro registros NS, más un TXT para verificar la propiedad del dominio. En cualquiera de los dos casos los registros cubren DKIM y SPF para ese subdominio, y la propagación DNS puede tardar hasta 48 horas, así que no juzgues la configuración veinte minutos después de guardar.

Dos notas prácticas del trabajo con clientes. Primero, algunos proveedores de DNS no aceptan guiones bajos en el nombre de un CNAME, y los registros de Klaviyo los necesitan; la guía de solución de problemas de Klaviyo dice que le pidas a tu proveedor que cree el registro. Segundo, delegar un subdominio por NS es una decisión real, no un trámite. Está bien para un subdominio que existe solo para enviar campañas. Merece una conversación si ese subdominio hace algo más. Cuando un cliente no se siente cómodo con la delegación, el enrutamiento estático llega al mismo resultado de alineación.

Klaviyo además es bastante claro con la confusión de SPF: el SPF del return path siempre va a pasar con Klaviyo, y tus reportes igual pueden mostrarlo fallando la alineación, porque el dominio del return path no coincide con el dominio de tu De. Ese es el artículo completo en una sola frase, dicho por el proveedor.

Ver las tres en tu reporte DMARC

Los reportes agregados son donde esto deja de ser adivinanza. Cada fila agrupa mensajes por origen y te dice el resultado de SPF, el de DKIM y, por separado, si cada uno alineó. El patrón a buscar es una fila con SPF pass, DKIM fail y un volumen parecido al tamaño de tu campaña. Eso es una plataforma sin alinear, siempre.

Compara el valor de header_from contra el dominio de DKIM en esa misma fila. Si el dominio de DKIM es el del proveedor, la configuración del dominio de envío nunca se terminó. Si el dominio de DKIM es el tuyo y la fila igual falla, revisa si pusiste alineación estricta con una dirección del De en el dominio raíz, que es justo la nota de HubSpot de más arriba.

Si el XML te resulta nuevo, escribimos un recorrido línea por línea en cómo leer un reporte DMARC agregado.

Tu presupuesto de consultas SPF después de todo esto

Aquí va la buena noticia silenciosa. Ninguno de estos tres arreglos te obliga a agregar un include a tu registro SPF raíz. Mailchimp dice que su include ni se necesita ni sirve para alinear. Los registros del dominio de marca de Klaviyo resuelven SPF para ese subdominio. El registro SPF de HubSpot pertenece al dominio de envío que conectas.

Eso importa porque el RFC 7208, sección 4.6.4, limita la evaluación de SPF a diez términos que provocan consultas DNS, y exige devolver permerror al pasarse. La mayoría de los receptores tratan un permerror igual que si no tuvieras SPF. Un dominio que apiló tres includes de plataformas más el host de correo más la herramienta de facturación normalmente ya está del otro lado de la línea. Explicamos el conteo y las salidas en la guía de SPF con demasiadas consultas DNS.

Entonces la postura que buscamos en el dominio de un cliente es sencilla: alineación por DKIM configurada en cada plataforma, y un registro SPF raíz que solo describa el correo que tu gente escribe a mano.

Qué vigilamos después de poner los registros

Arreglar la alineación es un día de trabajo. Mantenerla es un hábito.

Envía una campaña real a una dirección de prueba y vuelve a leer las cabeceras. No confíes en la palomita verde de la plataforma, que por lo general solo verifica que el registro DNS resuelva.
Dale dos semanas de reportes agregados antes de endurecer la política. Marketing envía con ritmo mensual, así que una sola semana puede esconder un remitente entero.
Vigila los registros que quedan huérfanos. Cuando una empresa cambia de plataforma, los CNAME viejos suelen quedarse en el DNS apuntando a un proveedor que ya no le sirve. Elimínalos.
Sube la política por escalones y no de un salto. Dejamos la escalera escrita en cómo pasar DMARC de p=none a p=reject.

Cómo ayuda Guanacos Tech

Hacemos esto para empresas pequeñas y medianas en Norteamérica y Latinoamérica, en inglés y en español. Normalmente empieza con un boletín que rebota y termina siendo un inventario completo: cada sistema que envía como tu dominio, cuáles alinean, cuáles solo lo aparentan, y una política que de verdad puedas aplicar sin romper las facturas. Si quieres revisar tu dominio por tu cuenta primero, el analizador DMARC y el diagnóstico de correo son gratis y no piden cuenta. Si prefieres delegarlo, mira cómo trabajamos la entregabilidad y cómo trabajamos, o agenda una llamada y trae el mensaje de rebote contigo.

Documentación de Mailchimp, HubSpot y Klaviyo consultada el 10 de septiembre de 2026.

Por qué Mailchimp, HubSpot y Klaviyo fallan la alineación DMARC (y cómo arreglar cada uno)