SPF, DKIM y DMARC para Salesforce.
Salesforce (Sales, Service y Platform Cloud) autentica tu dominio mediante tres piezas móviles y, desde Spring '26, se niega a enviar correo desde un dominio que no hayas verificado. El SPF es un include compartido real (include:_spf.salesforce.com) que fusionas en tu único registro SPF raíz. El DKIM es un par de registros CNAME de «selector» que generas en Configuración - Claves DKIM y luego Activas, y crear una clave DKIM activa es además la forma recomendada de satisfacer la nueva verificación del dominio de envío de correo de Salesforce. El DMARC es un cuarto registro independiente que Salesforce nunca crea por ti. El detalle que hace tropezar a casi todo el mundo: Salesforce envía los rebotes desde su propio dominio de return-path, de modo que el SPF no alinea con tu dirección De (From) - el DKIM es el mecanismo que realmente sostiene el DMARC.
¿Por qué autenticar Salesforce?
Autenticar el correo de Salesforce ya no es una tarea de mantenimiento opcional: desde Spring '26 (la aplicación comenzó el 9 de marzo de 2026 y se desplegó hasta finales de abril de 2026) Salesforce bloquea cualquier correo redactado por un usuario o automatizado que se envíe desde un dominio no verificado. Los envíos manuales fallan en el Compositor de correo con «Not allowed to send from an unauthorized domain», y los flujos automatizados fallan de forma silenciosa, mostrando «550 5.7.1 Delivery not authorized, message discarded» solo en tus Registros de correo (Email Logs). Además, desde febrero de 2024 Gmail y Yahoo exigen que todo remitente masivo (aproximadamente más de 5.000 mensajes al día) supere SPF, DKIM y DMARC con alineación, y Microsoft empezó a aplicar lo mismo al correo de gran volumen dirigido a Outlook.com en 2025. El comportamiento por defecto de Salesforce rompe el DMARC de forma discreta: estampa un return-path en su propio dominio de rebotes, de modo que el SPF autentica pero no alinea con tu dirección De (From), y de fábrica no hay ninguna firma DKIM sobre tu dominio - lo que significa que un correo de Salesforce que parece correcto puede seguir fallando el DMARC en todas partes. Configurar una clave DKIM resuelve ambos problemas a la vez: satisface el requisito de verificación de dominio y te proporciona una firma alineada que hace pasar el DMARC, de modo que la reputación que construyes se acumula en tu propio dominio en lugar de rebotar contra la infraestructura compartida de Salesforce.
La realidad del SPF con Salesforce
Salesforce core es un verdadero proveedor de tipo «include»: hay un mecanismo compartido real, include:_spf.salesforce.com, que añades al único registro SPF TXT de tu dominio raíz, p. ej. v=spf1 include:_spf.salesforce.com ~all. Pero ten claro lo que hace. El include se resuelve en v=spf1 exists:%{i}._spf.mta.salesforce.com -all - un registro con macro exists que autoriza las IPs de envío actuales de Salesforce - y consume DOS de tus 10 consultas DNS de SPF (una por el propio include, otra por el mecanismo exists anidado). El matiz importante: añadir este include autoriza a Salesforce para el SPF pero NO hace que el SPF alinee. Por defecto, Salesforce usa su propio dominio como envelope-from / Return-Path (su dominio de gestión de rebotes), de modo que la comprobación de SPF se ejecuta contra el dominio de Salesforce, no el tuyo - lo que significa que el SPF pasa pero no alinea con tu dirección De (From) visible, y el DMARC no obtiene nada de él. Por eso el DKIM no es opcional aquí: el DMARC necesita al menos un mecanismo alineado, y en Salesforce ese mecanismo es el DKIM. Publica el include de todos modos (es la recomendación documentada de Salesforce y autoriza las IPs de envío de forma limpia), pero trata el DKIM - no el SPF - como lo que sostiene tu aprobado de DMARC.
Dos formas de configurarlo
Clave DKIM (recomendado)
- Delegada por CNAME a custdkim.salesforce.com para que Salesforce guarde y rote las claves privadas
- Te proporciona una firma DKIM alineada - el mecanismo que realmente hace pasar el DMARC
- Una clave DKIM activa también satisface el requisito de verificación del dominio de envío de correo de Spring '26
- Una sola clave puede cubrir varios dominios de dirección De (From) mediante su Patrón de coincidencia de dominio
Dominios de correo autorizados - TXT (solo verificación)
- Un único registro TXT en _sfdv.yourdomain.com (o en el apex) demuestra que eres el propietario del dominio
- Satisface el requisito de verificación de Spring '26 para que los envíos no se bloqueen
- NO firma tu correo - sin firma DKIM, sin alineación DMARC a partir de él
- Úsalo solo como solución provisional; sigues necesitando una clave DKIM para la entregabilidad
Paso a paso
- 1
Configura tu nivel de acceso de Entregabilidad
Desde Configuración, usa la Búsqueda rápida para abrir Correo electrónico - Entregabilidad (Deliverability). Pon «Acceso para enviar correo» (nivel de acceso) en «Todo el correo» para que Salesforce envíe realmente el correo saliente - los sandbox y algunas organizaciones tienen por defecto «Solo correo del sistema» o «Sin acceso», lo que descarta silenciosamente tus mensajes de prueba antes de que la autenticación siquiera importe.
- 2
Crea una clave DKIM
Desde Configuración, busca «Claves DKIM» en la Búsqueda rápida y haz clic en Crear nueva clave. Elige 2048 bits para el tamaño de la clave RSA. Introduce un Selector único (p. ej. example-sf-a) y un Selector alternativo único (p. ej. example-sf-b). Introduce el Dominio desde el que envías y un Patrón de coincidencia de dominio (p. ej. example.com para cubrir ese dominio, o un patrón más amplio para subdominios) y luego Guarda. Nota: el campo Dominio es permanente una vez guardado.
- 3
Publica los dos registros CNAME de DKIM
Abre la página de Detalles de la clave DKIM - Salesforce muestra un CNAME y un CNAME alternativo. En tu proveedor de DNS, crea ambos como registros CNAME: el host example-sf-a._domainkey.yourdomain.com apuntando al destino que muestra Salesforce, como example-sf-a.k4tyd2.custdkim.salesforce.com (y el selector -b a su propio destino custdkim.salesforce.com). Copia los destinos exactos - un solo carácter erróneo rompe la firma. Si tu DNS está detrás de Cloudflare, ponlos en solo DNS (nube gris).
- 4
Activa la clave DKIM
Después de que los CNAMEs se propaguen (minutos, hasta 48-72 horas), vuelve a Configuración - Claves DKIM, abre la clave y haz clic en Activar. Salesforce no te dejará activar hasta que ambos CNAMEs se resuelvan en el DNS público. Una vez activa, Salesforce firma el correo saliente con d=yourdomain.com y tu dominio cuenta como verificado para el requisito de Spring '26.
- 5
Añade o fusiona el include de SPF
En tu proveedor de DNS, publica UN registro SPF TXT en la raíz (host @): v=spf1 include:_spf.salesforce.com ~all. Si ya envías a través de Google Workspace, Microsoft 365, una herramienta de marketing, etc., fusiona include:_spf.salesforce.com en esa única línea v=spf1 existente - nunca crees un segundo registro SPF. Esto autoriza las IPs de Salesforce (cuesta 2 consultas) pero recuerda que no alineará por sí solo.
- 6
Verifica el dominio si aún no usas DKIM
Si necesitas desbloquear el envío antes de que el DKIM esté activo, usa la alternativa TXT: Configuración - Búsqueda rápida «Dominios de correo autorizados» - Añadir, introduce tu dominio y Salesforce genera una clave de verificación. Publícala como registro TXT (host _sfdv.yourdomain.com o el apex), espera a la propagación, luego Edita el dominio y activa «Verificar propiedad del dominio». Esto demuestra la propiedad pero no firma el correo - una clave DKIM sigue siendo el objetivo.
- 7
Apunta tu Dirección de toda la organización al dominio verificado
Toda dirección De (From) debe estar en un dominio verificado. Desde Configuración, abre Búsqueda rápida - «Direcciones de toda la organización» (Organization-Wide Addresses) y asegúrate de que las direcciones desde las que envían tus usuarios, flujos y alertas por correo (p. ej. no-reply@yourdomain.com) estén en el dominio que acabas de autenticar. Las Direcciones de toda la organización no verificadas son la causa más común de envíos automatizados bloqueados.
- 8
Publica tu registro DMARC
Salesforce nunca crea el DMARC. Añade un registro TXT en _dmarc.yourdomain.com: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none es solo de monitorización - no cambia nada en la entrega mientras confirmas que el correo de Salesforce pasa el DKIM alineado con tu dominio. Mantén exactamente un registro _dmarc para todo el dominio.
- 9
Envía una prueba y lee las cabeceras
Envía un mensaje real desde una Dirección de toda la organización de Salesforce a un buzón de Gmail, ábrelo y elige el menú de tres puntos - Mostrar original. Buscas DKIM: PASS con signed-by / d=yourdomain.com (no salesforce.com) y DMARC: PASS. El SPF normalmente mostrará el dominio de return-path de Salesforce - eso es lo esperado; el DKIM es lo que debe sostener el aprobado de DMARC.
Registros que añadir
Salesforce genera los valores exactos en su asistente de configuración; estos muestran la forma de lo que añadirás en tu proveedor de DNS.
| Tipo | Host | Valor |
|---|---|---|
| TXT | @ | v=spf1 include:_spf.salesforce.com ~allSPF raíz - mantén exactamente UN registro SPF; fusiona este include en tu línea v=spf1 existente si tienes una. Cuesta ~2 consultas DNS (include + exists anidado). Autoriza a Salesforce pero no alinea. |
| CNAME | example-sf-a._domainkey | example-sf-a.k4tyd2.custdkim.salesforce.comSelector DKIM 1 - ilustrativo. Copia el destino exacto de tu página de Detalles de la clave DKIM; la cadena de partición k4tyd2 es única de tu clave. |
| CNAME | example-sf-b._domainkey | example-sf-b.e6mxu6.custdkim.salesforce.comSelector DKIM alternativo - ilustrativo. El segundo selector permite a Salesforce rotar claves sin que vuelvas a tocar el DNS. Usa el valor exacto que muestra Salesforce. |
| TXT | _sfdv | 00D000000000P18=1AB00000000000BClave de verificación de Dominios de correo autorizados - ilustrativa y por organización. Solo necesaria si usas el método de propiedad por TXT en lugar de (o antes de) una clave DKIM activa; el apex también funciona como host. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comLo añades tú mismo - Salesforce nunca lo crea. Uno por dominio; empieza en p=none y endurece más tarde. |
Mantén exactamente un registro TXT de SPF (v=spf1) en tu dominio raíz: fusiona en él todos los remitentes. Tener dos registros SPF es en sí mismo un error.
El presupuesto de 10 consultas
El SPF tiene un límite estricto de 10 consultas DNS: si lo superas, devuelve un permerror y deja de validar en todas partes. Esto es lo que la configuración de Salesforce consume de ese presupuesto.
Salesforce añade 2 de tus 10 consultas; los mecanismos ip4: e ip6: no cuentan.
DKIM
El DKIM es la pieza central de la autenticación de Salesforce, porque es el único mecanismo que alinea con tu dominio - y, desde Spring '26, una clave DKIM activa es la forma recomendada por Salesforce de verificar la propiedad del dominio para que tus envíos no se bloqueen. Créala en Configuración - Búsqueda rápida - «Claves DKIM» - Crear nueva clave: elige 2048 bits, introduce un Selector único y un Selector alternativo único (Salesforce usa dos selectores para poder rotar claves), especifica el Dominio y define un Patrón de coincidencia de dominio que controla qué dominios de dirección De (From) firma esta clave. Tras Guardar, la página de Detalles de la clave DKIM muestra un CNAME y un CNAME alternativo - por ejemplo example-sf-a._domainkey.yourdomain.com hacia example-sf-a.k4tyd2.custdkim.salesforce.com y example-sf-b._domainkey.yourdomain.com hacia example-sf-b.e6mxu6.custdkim.salesforce.com. Como se trata de CNAMEs delegados a custdkim.salesforce.com (no registros TXT que pegas), Salesforce guarda las claves privadas y rota las claves publicadas tras los dos selectores sin que tú tengas que reeditar nunca el DNS. Dos cosas que la gente pasa por alto: el campo Dominio es permanente una vez guardado (tendrías que crear una clave nueva para cambiarlo), y no puedes hacer clic en Activar hasta que ambos CNAMEs se resuelvan realmente en el DNS público. Publica ambos registros, espera a la propagación, luego vuelve a Claves DKIM y haz clic en Activar - solo entonces empieza Salesforce a firmar el correo saliente con d=yourdomain.com. Las claves DKIM más antiguas de Salesforce eran claves TXT autogestionadas que generabas y pegabas; la clave DKIM «segura» moderna es la versión delegada por CNAME descrita aquí y es la que deberías usar.
DMARC
El DMARC es un registro TXT de política independiente en tu dominio que Salesforce no crea - lo publicas tú en _dmarc.yourdomain.com, empezando con v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none es solo de monitorización: no cambia nada en la entrega mientras observas los informes agregados (rua) para confirmar que el correo de Salesforce pasa el DKIM alineado con tu dominio. Este es el paso donde más importa la peculiaridad de alineación de Salesforce: como Salesforce envía los rebotes desde su propio dominio de return-path, el SPF autentica pero no alinea, de modo que en el correo de Salesforce el DMARC pasa únicamente por la alineación DKIM. Eso está bien - el DMARC solo requiere un mecanismo alineado - pero significa que tu clave DKIM debe estar activa y firmando antes de que endurezcas la política, o el correo legítimo de Salesforce fallará. Vigila los informes durante una o dos semanas, asegúrate de que Salesforce (y todos los demás remitentes - Google Workspace, Microsoft 365, herramientas de marketing) muestre un aprobado alineado, luego sube a p=quarantine y finalmente a p=reject. Mantén exactamente un registro _dmarc para todo el dominio organizativo; nunca añadas un segundo solo para Salesforce.
Comprueba que de verdad funcionó
No te fíes únicamente del estado de la página de Claves DKIM de Salesforce - confírmalo en un mensaje real. Envía desde una de tus Direcciones de toda la organización (Org-Wide Addresses) a un buzón de Gmail, abre el mensaje y elige el menú de tres puntos - Mostrar original. Buscas DKIM: PASS con signed-by / d=yourdomain.com (si muestra salesforce.com, tu clave no está activa o tu Dirección de toda la organización está en el dominio equivocado) y DMARC: PASS. El SPF normalmente listará un dominio de return-path de Salesforce en lugar del tuyo - eso es lo esperado, porque el DKIM, no el SPF, es el que hace la alineación. En Salesforce, la página de Detalles de la clave DKIM debería indicar Activa. Luego pasa tu dominio por el chequeo de salud de dominio de Qualisend para confirmar que el registro SPF, ambos CNAMEs de selector DKIM y el registro DMARC se resuelven todos limpiamente y que el SPF se mantiene por debajo del límite de 10 consultas; una vez que empiecen a llegar los informes agregados de DMARC, mete uno en el analizador de informes DMARC para confirmar que Salesforce aparece como una fuente alineada y aprobada.
Errores habituales
- Cobertura
Aplicación de Spring '26: Salesforce ahora bloquea el correo de dominios no verificados - los envíos manuales fallan con «Not allowed to send from an unauthorized domain» y los flujos automatizados fallan silenciosamente, registrando «550 5.7.1 Delivery not authorized, message discarded» en los Registros de correo. Activa una clave DKIM (o verifica mediante Dominios de correo autorizados) para cada dominio que usen tus Direcciones de toda la organización.
- Cobertura
El SPF no alinea en Salesforce. Envía los rebotes desde su propio dominio de return-path, de modo que el include de SPF autoriza pero nunca alinea con tu dirección De (From) - el DMARC se apoya por completo en el DKIM. Añadir el include sin una clave DKIM activa NO te dará un aprobado de DMARC.
- Cobertura
El campo Dominio de la clave DKIM es permanente. Una vez que Guardas, no puedes editar el dominio (ni los selectores) - tendrías que crear una clave nueva. Acierta a la primera y usa el Patrón de coincidencia de dominio para cubrir los dominios desde los que realmente envías.
- Configuración de DNS
No puedes Activar el DKIM hasta que ambos CNAMEs se resuelvan. El botón Activar no funcionará mientras el DNS aún se esté propagando; espera (hasta 48-72 horas) y vuelve a comprobarlo con una consulta DNS antes de intentarlo de nuevo.
- Cobertura
El nivel de acceso de Entregabilidad bloquea envíos silenciosamente. Si «Acceso para enviar correo» está en «Solo correo del sistema» o «Sin acceso» (común en sandbox), Salesforce descarta tu correo saliente independientemente del DNS - ponlo en «Todo el correo» en Configuración - Entregabilidad.
- Cobertura
El Relay de correo (Email Relay) evita la firma DKIM de Salesforce. Si enrutas el correo saliente a través de tu propio servidor SMTP mediante Configuración - Relay de correo, Salesforce no firma el correo - tu relay es responsable del SPF y el DKIM, y estos registros de Salesforce no se aplicarán a esa ruta.
- Configuración de DNS
Esto cubre Salesforce core (Sales/Service/Platform), no Marketing Cloud ni Pardot. Marketing Cloud Engagement usa su propio Sender Authentication Package (SAP) con CNAMEs distintos, y Account Engagement (Pardot) tiene su propia configuración - cada familia de productos se autentica por separado.
- Rompe la autenticación
Mantén un solo registro SPF. Fusiona include:_spf.salesforce.com en tu única línea v=spf1 - dos registros SPF TXT en el mismo dominio son un PermError que rompe el SPF para todos los remitentes.
Crea tu registro SPF
Salesforce ya viene preseleccionado abajo. Añade cualquier otra plataforma desde la que envíes y luego publica el registro fusionado único.
This domain's own servers
Authorize the domain itself, if it sends mail directly (not through a platform above).
Other senders & IPs
Anything not in the list — another provider's SPF host, or specific IP addresses.
We add the include: prefix — enter the hostname your provider documents.
Policy for everyone else
What receivers should do with mail from any server not listed above (the all mechanism).
- Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
- Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
- Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.
Authentication published? The next step is sending to a clean, verified list.
Verify a listSPF de Salesforce — Preguntas frecuentes
Lecturas relacionadas
Una vez publicado, confirma que todo se resuelve con el chequeo de salud del dominio y luego averigua quién envía en tu nombre con el analizador de informes DMARC. Explora todas las fuentes de envío en el generador. Eso sí, la autenticación es solo la mitad de la entregabilidad: una IP o un dominio de envío incluidos en una lista negra te llevan igualmente a spam por muy limpio que esté tu SPF, así que conviene vigilar las listas negras con monitorización de listas negras.
Autenticado: ahora mantén la lista limpia
Pasar SPF, DKIM y DMARC te lleva a la bandeja de entrada; una lista limpia te mantiene ahí. Verifica la tuya: empieza gratis con 100 créditos, sin tarjeta.