Salesforce: DKIM y alineación DMARC de los distintos clouds

<selector1>._domainkey.ejemplo.es.  CNAME  <selector1>.<clave>.dkim.sfdc.net.
<selector2>._domainkey.ejemplo.es.  CNAME  <selector2>.<clave>.dkim.sfdc.net.

La alineación DMARC reposa sobre DKIM

DMARC solo valida un mensaje si SPF o DKIM pasa y se alinea con el dominio del From. Para cada cloud de Salesforce correctamente configurado, es DKIM el que porta la alineación: la firma d=ejemplo.es (Sales/Service) o la del subdominio SAP (Marketing Cloud) se alinea con el dominio del From, en modo relajado para un subdominio, en estricto para el dominio mismo.

SPF es más delicado. Según la configuración de gestión de rebotes, el sobre de los mensajes de Salesforce puede permanecer en un dominio de la plataforma, en cuyo caso SPF pasa sin alinearse — y no cuenta. Apoyarse en DKIM es, pues, la opción fiable y recomendada para Salesforce. Los ejemplos de registros DMARC comentados muestran cómo fijar la consigna _dmarc una vez autenticados los clouds. Bajo DMARCbis, el dominio organizativo de referencia se determina mediante el DNS Tree Walk, sin cambio para este razonamiento.

El presupuesto de diez consultas DNS de SPF

Una trampa específica de Salesforce merece su propia sección. Muchas guías recomiendan añadir include:_spf.salesforce.com al registro SPF raíz del dominio. Ahora bien, ese include es pesado: anida otros, y consume por sí solo varias de las diez consultas DNS que SPF autoriza antes de pasar a permerror. Combinado con otros servicios (una suite ofimática, un ESP), supera pronto el techo — y un permerror invalida SPF para todo el dominio, incluido el correo que se alineaba.

Dos consecuencias prácticas. Primero, añadir este include no alinea SPF de todos modos si el sobre permanece en un dominio de Salesforce: se paga el coste sin el beneficio. Segundo, cuando SPF no es el mecanismo de alineación elegido (y no lo es, aquí, en favor de DKIM), el include de Salesforce es a menudo superfluo. Vigilar el límite de diez consultas DNS de SPF es tanto más útil en un entorno Salesforce cuanto que la tentación de apilar include es grande allí.

El subdominio del Marketing Cloud

El Sender Authentication Package del Marketing Cloud merece una pausa, pues es la configuración más completa de los clouds de Salesforce. El SAP pone en marcha un subdominio de envío dedicado — a menudo de la forma mkt.ejemplo.es — que se convierte en el dominio de envío de las campañas: SPF, firma DKIM y el dominio de seguimiento de enlaces están todos vinculados a él. La alineación es allí, pues, doble, SPF y DKIM, en modo relajado hacia ejemplo.es, lo que aporta la redundancia que protege en caso de redirección.

Esta completitud tiene una contrapartida: el SAP se configura una vez, y su subdominio dedicado debe permanecer reservado al Marketing Cloud. Mezclarlo con otros usos, o cambiar de subdominio sin rehacer la configuración, rompe el conjunto. Para una organización que difunde a gran escala, es no obstante la base más sólida — y la más legible en los informes, donde el subdominio aparece como una fuente limpia y alineada, fácil de distinguir del tráfico Sales/Service.

Relé de correo y gestión de rebotes

Dos ajustes de Salesforce tocan la autenticación de forma indirecta y conviene conocer. El primero, el Email Relay, hace transitar el correo de Salesforce por el servidor SMTP de la organización antes de la entrega: en ese montaje, el correo sale de la infraestructura interna, hereda su SPF y su reputación, y la alineación se razona entonces como para cualquier servidor propio — un caso distinto del envío directo por Salesforce. El segundo, la gestión de rebotes, determina el dominio de sobre de los mensajes: según esté activada o no, el Return-Path se inclina hacia un dominio de Salesforce o hacia el de la organización, lo que cambia la alineación SPF.

Estos ajustes no reemplazan a DKIM — que sigue siendo el mecanismo de alineación fiable — pero explican por qué dos organizaciones bajo Salesforce pueden ver resultados SPF diferentes en sus informes. Entender cuál está en marcha evita buscar un defecto de alineación SPF donde solo hay una elección de configuración de rebotes.

Los errores de configuración habituales

Varias trampas reaparecen en el corpus de informes que el analizador DMARC gratuito procesa a diario.

Autenticar solo un cloud. El más frecuente: DKIM puesto para el Sales Cloud, Marketing Cloud o Pardot olvidados — estos fallan a DMARC bajo una política estricta.

Generar la clave sin activarla. En Setup, una clave DKIM creada pero dejada inactiva no firma nada; el dominio parece configurado, los mensajes no están firmados.

Apilar el include SPF de Salesforce sin necesidad. Descrito más arriba: coste en consultas, riesgo de permerror, sin beneficio de alineación cuando es DKIM el que alinea.

Endurecer antes de cubrirlo todo. Pasar a p=reject creyendo Salesforce autenticado mientras un cloud aún emite sin firma alineada equivale a rechazar una parte del propio tráfico de negocio.

La contraprueba: los informes RUA

La única prueba de que una configuración aguanta no es la pantalla de Setup, sino lo que reportan los destinatarios. Una vez publicado un registro _dmarc con una dirección rua=, los informes agregados llegan en unos días y detallan, fuente por fuente, qué se alinea y qué falla. La lectura de los informes DMARC agregados es aquí particularmente valiosa, porque revela cada cloud de Salesforce como una fuente distinta: se ve de un vistazo si el Sales Cloud, el Marketing Cloud y Account Engagement se alinean todos, o si uno de ellos aún falla.

Basta una cadencia sencilla: una primera lectura unos días después de la configuración, una vez que varios destinatarios han reportado, luego un vistazo semanal mientras la política siga en p=none. Es la confirmación de que todos los clouds emisores se alinean la que autoriza a endurecer — un solo cloud no alineado basta para justificar la espera. Una vez observada esa cobertura completa durante varios días, el paso a p=reject se hace sin riesgo. El analizador en línea recompone este estado a partir de los registros publicados y de los informes recibidos, y sitúa el dominio en el camino que lleva a p=reject.