Mailchimp y DMARC: lograr una alineación completa

k1._domainkey.ejemplo.es.  CNAME  dkim.mcsv.net.
k2._domainkey.ejemplo.es.  CNAME  dkim2.mcsv.net.
k3._domainkey.ejemplo.es.  CNAME  dkim3.mcsv.net.

Por qué la alineación SPF no llegará — y por qué no es grave

El reflejo que suele seguir a la publicación de los CNAME consiste en querer «completar» el trabajo con SPF, añadiendo el include de la plataforma al registro del dominio. Ese reflejo descansa sobre una confusión. SPF se evalúa contra el dominio del sobre (el Return-Path), no contra el dominio mostrado en el From. Y en Mailchimp, el sobre permanece en los servidores de la plataforma: así es como los retornos de error —direcciones inválidas, buzones llenos— vuelven a sus sistemas de gestión de listas. No existe opción para sustituirlo por un dominio propio.

Consecuencia: SPF pasará siempre para el dominio de la plataforma y nunca se alineará con el From. Añadir el include al SPF del dominio no cambia nada: solo quema una de las diez resoluciones DNS permitidas en un mecanismo que no participará en el veredicto. La propia plataforma dejó hace tiempo de recomendar ese añadido.

Y no es grave, porque DMARC no exige ambos mecanismos: un solo resultado alineado basta para producir un pass. El DKIM alineado obtenido con los CNAME cubre la totalidad de la necesidad. Aporta incluso una ventaja de robustez: la firma DKIM viaja con el mensaje y sobrevive a la mayoría de los reenvíos automáticos, mientras que SPF se rompe en cuanto un intermediario reexpide. Para un flujo de marketing, cuyos destinatarios reenvían con gusto, la alineación DKIM es el caballo ganador.

Lo que muestran los informes RUA, antes y después

Los informes agregados cuentan esta historia con precisión. Antes de la autenticación, cada línea atribuida a las direcciones IP de la plataforma presenta la misma firma característica:

<record>
  <row>
    <source_ip>205.201.131.xx</source_ip>
    <policy_evaluated><dkim>fail</dkim><spf>fail</spf></policy_evaluated>
  </row>
  <auth_results>
    <dkim><domain>mcsv.net</domain><result>pass</result></dkim>
    <spf><domain>mail01.rsgsv.net</domain><result>pass</result></spf>
  </auth_results>
</record>

El matiz está en el contraste: en auth_results, todo pasa; en policy_evaluated, todo falla. Es la huella típica de un problema de alineación, no de un problema de autenticación: el diagnóstico más útil que un informe RUA puede entregar.

Tras la publicación de los CNAME, el mismo rango de direcciones cambia de cara: dkim=pass con ejemplo.es como dominio firmante, policy_evaluated en verde, y el SPF sigue sin alinearse — sin consecuencia alguna. Constatar ese vuelco durante un ciclo completo de campañas es la prueba que autoriza a endurecer la política. Antes hay que recolectar los informes: un registro del tipo v=DMARC1; p=none; rua=mailto:informes@ejemplo.es es el punto de entrada, y los ejemplos comentados de registros DMARC ofrecen plantillas listas para adaptar a la madurez del dominio.

La misma rejilla de lectura se aplica a las demás plataformas del parque: la lógica es parecida en SPF y DKIM en Brevo, y el caso SendGrid ilustra un cursor colocado de otra manera entre sobre personalizable y DKIM delegado. Cada plataforma hace sus elecciones; la pregunta sigue siendo la misma: ¿quién firma, y para qué dominio?

El subdominio dedicado: aislar la reputación

En lugar de hacer descansar las campañas sobre el dominio raíz, muchas organizaciones las confían a un subdominio dedicado: news.ejemplo.es, info.ejemplo.es. Los CNAME de autenticación se publican entonces sobre ese subdominio, y el From de las campañas lo muestra. Los beneficios son concretos. La reputación de envío del flujo de marketing se construye aparte: un incidente de campaña —un pico de quejas, una lista mal depurada— no erosiona la reputación del dominio raíz, del que dependen los correos transaccionales y la correspondencia individual. El inventario de fuentes también gana en legibilidad: en los informes, todo lo que emana del subdominio pertenece a un único flujo, lo que simplifica la atribución.

En el lado DMARC, la alineación relajada —el modo por defecto— acepta que un From en news.ejemplo.es se alinee tanto con una firma d=news.ejemplo.es como con una del dominio organizativo. DMARCbis, la revisión vigente del estándar, determina ese dominio organizativo mediante el DNS Tree Walk, el ascenso por el árbol DNS, y ya no mediante la Public Suffix List. La revisión aporta también la etiqueta np, que regula la suerte de los subdominios inexistentes: suficiente para blindar nominas.ejemplo.es o cualquier otro subdominio fantasma mientras news.ejemplo.es despliega sus campañas legítimas. Un subdominio dedicado puede, por fin, llevar su propia política, publicada en _dmarc.news.ejemplo.es, y endurecerla a su ritmo.

p=reject sin autenticación: la doble sanción

Queda el peor escenario: un dominio que pasa a p=reject sin haber autenticado su plataforma. Dos mecánicas se combinan. Para los flujos en los que el From conserva el dominio, las campañas no alineadas son rechazadas de plano por los receptores que aplican la política: envíos enteros evaporados, descubiertos a menudo semanas más tarde, al investigar por qué «la newsletter ya no sale». Y para los flujos atrapados por la reescritura del From, la sanción es más insidiosa: los mensajes salen y llegan, pero bajo send.mailchimpapp.com — la marca ha desaparecido del campo remitente, el reconocimiento cae, y los filtros aprenden un dominio que no pertenece a la organización.

La política estricta sigue siendo el objetivo correcto; lo innegociable es el orden de las operaciones: autenticar primero, constatar la alineación en los informes después, endurecer al final. DMARCbis proporciona además una herramienta de prueba limpia, la etiqueta t=y, que señala a los receptores que una política está en modo de prueba — el sucesor asumido del antiguo pct, desaparecido de la revisión vigente.

En resumen

Por defecto, Mailchimp autentica sus propios dominios, no el de la marca: SPF y DKIM pasan, nada se alinea, DMARC falla — y desde las exigencias de los grandes proveedores, el From se reescribe hacia un dominio de la plataforma en cuanto falta la autenticación. La corrección cabe en unos pocos CNAME bajo _domainkey, que hacen que las campañas se firmen en nombre del dominio: DKIM se alinea, y basta, porque la alineación SPF queda estructuralmente fuera de alcance con este proveedor — el sobre permanece en sus servidores. Los informes RUA aportan la prueba del vuelco, el subdominio dedicado aísla la reputación de marketing, y el endurecimiento hacia p=reject llega después de la prueba, nunca antes.

Para situar el punto de partida, un pase del dominio por el análisis DMARC gratuito muestra en segundos si las campañas ya firman en nombre del dominio o todavía en el de la plataforma. A partir de ahí, la creación de una cuenta permite seguir el vuelco en los informes, campaña tras campaña, hasta una política estricta que protege la marca sin perder una sola newsletter.