Verificar el dominio de envío de correo
REDA funciona sobre Salesforce, y Salesforce ya no entrega correos cuyo dominio de envío no se haya demostrado que te pertenece. Si las direcciones de tu equipo terminan en @tuempresa.com, alguien debe publicar un registro DNS que demuestre que tu empresa es dueña de tuempresa.com; de lo contrario los usuarios no pueden poner una dirección corporativa como su dirección de Salesforce, y los correos que REDA envía en su nombre se descartan. Este artículo explica el requisito desde cero, te da el registro exacto que hay que publicar, responde la pregunta que hará tu equipo de TI antes de publicarlo y recorre toda la secuencia hasta dejar el dominio verificado y funcionando. Está escrito para quien configura una organización de REDA durante la implementación: no necesitas saber nada de DNS de antemano.
Ojo con el nombre parecido. Si Búsqueda rápida muestra dos entradas llamadas Dominios de correo electrónico autorizados, elige la que está directamente bajo Correo electrónico, no la que está bajo Mensajería unificada. Son funciones distintas.
Acceso que necesitas. El permiso Administración de correo electrónico para modificar los dominios de correo autorizados, y Personalizar aplicación para administrar las claves DKIM y la página de Capacidad de entrega. También necesitarás a alguien que pueda editar el DNS público de tu empresa: casi siempre es un equipo distinto del que administra Salesforce, y por eso conviene empezar este paso temprano.
Qué es un "dominio de envío de correo" y por qué Salesforce ahora lo verifica
Un dominio de envío de correo es simplemente la parte de una dirección de correo que va después del signo @. En ana.silva@tuempresa.com, el dominio de envío es tuempresa.com. Cuando Salesforce envía un correo que parece venir de esa dirección —un correo masivo que un usuario mandó desde un registro de REDA, una notificación, un estado de cuenta del propietario, una alerta automática— Salesforce está enviando correo como tu empresa.
Históricamente Salesforce solo verificaba la dirección individual: le enviaba un enlace al usuario, el usuario hacía clic y la dirección quedaba verificada. Eso demuestra que una persona puede leer ese buzón. No demuestra que la organización dueña de la organización de Salesforce tenga derecho a enviar correo como ese dominio. Como cualquiera que pueda crear usuarios en una organización de Salesforce podría, si no, crear una dirección en cualquier dominio y enviar correo como ese dominio, Salesforce agregó una segunda verificación, de nivel superior.
Así que ahora hay dos niveles de verificación independientes, y los dos importan:
| Nivel | Qué demuestra | Cómo se hace |
|---|---|---|
| A nivel de dominio (el requisito nuevo) | Que tu organización controla el dominio, así que Salesforce puede enviar correo como ese dominio | Un registro DNS en el dominio: una clave DKIM o un dominio de correo autorizado |
| A nivel de usuario (el requisito de siempre) | Que esta persona en concreto puede leer este buzón en concreto | Salesforce envía a la dirección un enlace de verificación en el que el usuario hace clic |
Salesforce lo implantó por fases como el requisito de verificación del dominio de envío de correo de Spring '26. Las organizaciones existentes recibieron una lista temporal de permitidos con los dominios desde los que ya enviaban, y ese período de gracia venció durante 2026: es un requisito vigente, no algo que vaya a llegar. Aplica también a los entornos sandbox, y es independiente para cada dominio y cada subdominio: verificar tuempresa.com no cubre correo.tuempresa.com.
Cómo se manifiesta el problema
El requisito casi nunca se anuncia solo. Aparece como alguno de estos síntomas, y ninguno menciona el DNS:
| Lo que ves | Dónde |
|---|---|
| Se cambia la dirección de un usuario a una dirección corporativa, llega el correo de verificación, el usuario hace clic en el enlace… y cae en la página de inicio de sesión. La dirección nunca se actualiza. | Registro de usuario en Configuración |
| "Not allowed to send from an unauthorized domain." (No se permite enviar desde un dominio no autorizado.) | El redactor de correo, al intentar enviar |
| "No podemos enviar tu correo porque el dominio de tu dirección no está verificado. Pide ayuda a tu administrador de Salesforce." | Mensaje mostrado al usuario |
| La dirección del propio usuario no aparece en la lista desplegable De al redactar. | Redactor de correo |
550 5.7.1 Delivery not authorized, message discarded | Configuración → Archivos de registro de correo electrónico |
| Un correo de aviso titulado "Contact Your Salesforce Admin to Verify Your Email Domain", o una notificación de fallo de entrega titulada "Salesforce Messages Not Delivered". | Enviado al usuario afectado |
| Un aviso en la página de inicio de Configuración que le dice al administrador que se descartaron correos por la verificación de dominio. | Inicio de Configuración |
550 5.7.1 en Configuración → Archivos de registro de correo electrónico en vez de confiar en que los usuarios lo reporten.
Dos formas de demostrar que el dominio es tuyo
Salesforce acepta exactamente dos pruebas, y solo necesitas una por dominio. En el fondo las dos funcionan igual: publicas en el DNS de tu dominio un registro que solo el dueño del dominio podría publicar, y Salesforce lo consulta.
| Método | En qué consiste | Elígelo cuando |
|---|---|---|
| Clave DKIM (la recomendación de Salesforce) | Salesforce genera una clave de firma; tú publicas los registros DNS correspondientes y activas la clave. A partir de ahí Salesforce firma criptográficamente el correo saliente. | Puedas involucrar como corresponde a tu equipo de correo/DNS. Además mejora la entregabilidad: el correo firmado tiene menos probabilidad de acabar filtrado como spam. |
| Dominio de correo autorizado | Salesforce genera una clave de verificación corta; tú la publicas como un único registro DNS de tipo TXT y Salesforce la lee. | Necesites desbloquear lo antes posible, o DKIM no sea viable. Cumple el requisito, pero no aporta ninguna mejora de entregabilidad. |
El resto de este artículo cubre la vía del dominio de correo autorizado, porque es un solo registro DNS y es la que usan la mayoría de las implementaciones de REDA para desbloquear la incorporación de usuarios. Si tu organización ya tiene una clave DKIM activa para el dominio, el dominio ya está verificado y no tienes nada que hacer: revisa primero Configuración → Claves DKIM antes de crear nada.
Paso 1 — Agregar el dominio y obtener su clave de verificación
@ en las direcciones de tus usuarios —tuempresa.com, sin @, sin www. y sin punto final— y Guarda.00D000000000P08=1TB00000000000B: el Id. de tu organización, un signo igual y una clave única para este dominio. Cópiala tal cual, incluido el signo igual. Toda esa cadena es el valor del registro DNS que vas a solicitar.tuempresa.com y una dirección de servicio está en notificaciones.tuempresa.com, eso son dos entradas, dos claves y dos registros DNS.
Paso 2 — Publicar un registro DNS de tipo TXT
El DNS es el directorio público que asocia los nombres de dominio con información sobre ellos. Un registro TXT es simplemente una entrada de texto libre en ese directorio, y es lo que usan universalmente las comprobaciones de propiedad de dominio: solo quien controla el dominio puede poner texto en su DNS, así que encontrar ahí el texto esperado es prueba de control. Lo crea quien administre el DNS de tu empresa: tu equipo de TI, o un registrador como Cloudflare, GoDaddy o Route 53.
Salesforce acepta el registro en tres ubicaciones válidas. El valor es idéntico en las tres; lo único que cambia es el nombre del registro.
| Opción | Nombre del registro | Cuándo usarla |
|---|---|---|
| 1 | tuempresa.com (el ápex, es decir, el dominio mismo) | Es la más simple de explicar, pero agrega un registro TXT junto a tus entradas SPF y DMARC existentes, en el punto más sensible de la zona. |
| 2 — recomendada | _sfdv.tuempresa.com | La opción menos invasiva. Vive en su propio subdominio dedicado, así que no puede interferir con la configuración de correo existente en el ápex. |
| 3 | <Id.-de-organización-de-18-dígitos>._sfdv.tuempresa.com | Cuando más de una organización de Salesforce envía correo desde el mismo dominio. Cada organización tiene un registro con nombre distinto, así que nunca pueden chocar. |
Con la opción 2, este es el registro completo: un registro TXT cuyo nombre es el subdominio _sfdv y cuyo valor es la clave de verificación del Paso 1. El TTL predeterminado está bien.
Name TTL CLASS TYPE VALUE
--------------------------------------------------------------------
_sfdv.tuempresa.com. 600 IN TXT "00D000000000P08=1TB00000000000B"Nada más cambia: no cambia el enrutamiento del correo, no cambian las entradas SPF, DKIM o DMARC existentes, y no afecta la entrega de correo actual de tu empresa. Es un solo registro que se suma.
@tuempresa.com. Una organización, un dominio → opción 2, el registro _sfdv. Ahora supón que ese mismo grupo ya tiene otra organización de Salesforce para su equipo comercial corporativo, que envía desde las mismas direcciones @tuempresa.com. Cada organización genera su propia clave de verificación, y las dos querrían el mismo nombre de registro. Ese es justamente el caso para el que existe la opción 3: cada organización publica <su propio Id. de organización de 18 dígitos>._sfdv.tuempresa.com y ninguna interfiere con la otra. Haz esta pregunta antes de crear el registro: elegir bien ahora sale más barato que cambiarlo después.
;). Las dos formas son válidas.
Qué le da —y qué no— ese registro a Salesforce
Esta es la pregunta que hace todo equipo de TI o de seguridad antes de publicarlo, y merece una respuesta directa.
La verificación es una consulta de DNS de solo lectura. Salesforce consulta el DNS público en busca del registro TXT con el nombre que elegiste, compara el texto que encuentra con la clave que generó y guarda el resultado. Ese es todo el mecanismo.
| Inquietud | Realidad |
|---|---|
| ¿Salesforce obtiene control del dominio? | No. Hace una consulta, igual que la puede hacer cualquier usuario de internet. No puede crear, modificar ni eliminar registros DNS. |
| ¿El registro es información sensible? | No. El DNS es público por diseño, y el valor es un Id. de organización más una clave opaca. No da acceso a nada ni sirve para autenticarse. |
| ¿Afecta la entrega de correo? | No. Ningún proceso de enrutamiento de correo consulta un registro TXT en _sfdv.. SPF, DKIM y DMARC quedan intactos. |
| ¿Es reversible? | Sí. Eliminar el registro quita la prueba; nada más del dominio cambia. |
| ¿REDA necesita acceso a nuestro DNS? | No. El registro lo publica tu propio equipo de TI o tu registrador. A REDA solo hay que avisarle cuando esté publicado. |
Paso 3 — Verificar la propiedad en Salesforce
Los cambios de DNS se propagan por internet con retraso. En la práctica un registro nuevo suele verse en minutos, pero la propia guía de Salesforce dice que hay que dar hasta 72 horas, y el tiempo real depende del TTL de los registros que ya estaban ahí. Planifica la solicitud con eso en mente: es la única parte de la secuencia que no puedes acelerar.
= y —para la opción 3— que el Id. de organización sea el de 18 dígitos.
Paso 4 — Decidir sobre "Requerir verificación de correo electrónico"
Cada dominio de correo autorizado tiene un segundo ajuste, Requerir verificación de correo electrónico, que está activado de forma predeterminada. Controla la verificación a nivel de usuario descrita al comienzo de este artículo: si cada persona de ese dominio debe además hacer clic en un enlace de verificación antes de que Salesforce envíe como su dirección.
Una vez verificada la propiedad, tienes una decisión real que tomar, y es una decisión de seguridad más que un detalle de configuración:
| Valor | Qué pasa | Contrapartida |
|---|---|---|
| Sí (predeterminado) | Cada usuario del dominio sigue recibiendo un enlace de verificación, y debe hacer clic en él cuando se establece o cambia su dirección. | Es lo más seguro. Pero mantiene el paso por usuario que suele atascarse en las incorporaciones masivas. |
| No | Se omite la verificación a nivel de usuario para todas las direcciones de este dominio. Las direcciones se pueden establecer sin ningún correo de verificación. | Elimina por completo la fricción de la incorporación… y elimina también una salvaguarda. Salesforce lo documenta como una opción admitida, pero no la recomienda. |
Para cambiarlo: Configuración → Dominios de correo electrónico autorizados → Modificar junto al dominio → desmarca Requerir verificación de correo electrónico → Guardar. También existe un equivalente para toda la organización, para DKIM, en la página Capacidad de entrega (Verificar la propiedad de los dominios de envío de correo electrónico mediante claves DKIM), que aplica a todos los dominios con una clave activa a la vez; el ajuste por dominio del dominio de correo autorizado es el instrumento más preciso.
Solución temporal para un usuario atascado mientras el DNS está pendiente
Si alguien necesita que le cambien la dirección antes de que el registro DNS esté publicado, el enlace de verificación suele fallar simplemente porque se abre fuera de una sesión autenticada: el navegador no tiene sesión de Salesforce, así que el enlace cae en la página de inicio de sesión y el cambio queda abandonado. Esta secuencia normalmente resuelve el caso de un usuario:
Hay otros dos ajustes de la organización que producen el mismo síntoma de la página de inicio de sesión y conviene revisar si lo anterior no funciona: Requerir verificación de identidad para los cambios de dirección de correo electrónico (Configuración → Verificación de identidad), que le pide al usuario confirmar desde su dirección anterior y deja atrapado a quien ya no tiene acceso a ella; y el inicio de sesión único (SSO), donde una cookie de página de inicio almacenada puede forzar un cierre de sesión que descarta el destino del enlace.
Solución de problemas
| Síntoma | Causa probable | Solución |
|---|---|---|
| El enlace de verificación lleva a la página de inicio de sesión; la dirección nunca se actualiza | El enlace se abrió sin sesión de Salesforce, el enlace caducó, el ajuste de verificación de identidad, o SSO | Inicia sesión primero en el mismo navegador y vuelve a hacer clic en un enlace nuevo; revisa Configuración → Verificación de identidad. A largo plazo, verifica el dominio y reconsidera Requerir verificación de correo electrónico |
| El redactor se niega a enviar: "unauthorized domain" | Falta la verificación a nivel de dominio | Completa los pasos 1 a 3 para ese dominio |
| El dominio muestra Propiedad verificada = No después de publicar el registro | El DNS todavía no se propagó, o la consulta no se volvió a ejecutar | Espera y luego vuelve a Modificar y Guardar el dominio: guardar es lo que vuelve a lanzar la comprobación |
| La verificación nunca funciona aunque el registro parece correcto | Se usó el Id. de organización de 15 dígitos en un registro de la opción 3, falta el = en el valor, o hay un error de tipeo en el nombre | Revisa nombre, valor y el Id. de 18 dígitos; el valor debe coincidir carácter por carácter con la clave que muestra Configuración |
| A algunos usuarios les funciona y a otros no, en lo que parece el mismo dominio | Los usuarios que fallan están en un subdominio | Agrega y verifica un dominio de correo autorizado aparte para cada subdominio |
| Los correos de un flujo, una alerta o una automatización nunca llegan, y no hay error en ninguna parte | Se descartaron en silencio en la comprobación de dominio | Busca 550 5.7.1 Delivery not authorized en Configuración → Archivos de registro de correo electrónico |
| El correo del sandbox dejó de funcionar después de una actualización | La verificación no se hereda al crear un sandbox | Importa el dominio de correo autorizado al sandbox, o configura uno ahí |
yahoo.com o icloud.com— Salesforce ofrece una alternativa en la página Capacidad de entrega: Usar una dirección de correo electrónico sustituta para dominios no verificados. El correo sigue saliendo, pero la dirección del campo De se reemplaza por una dirección sustituta propiedad de Salesforce. Mantiene el correo funcionando; no hace que tu dominio quede verificado. Las direcciones que terminan en @gmail.com, @hotmail.com y @outlook.com ya están exentas del requisito de dominio.
Referencias oficiales de Salesforce
La verificación de dominio es un requisito de la plataforma Salesforce, no un ajuste de REDA, así que la documentación autorizada es la de Salesforce. Las URL de la ayuda de Salesforce cambian entre versiones; si un enlace se mueve, busca en el portal de ayuda por el título o el Id. del artículo.
| Tema | Artículo | Id. |
|---|---|---|
| Por qué ahora es obligatorio | Spring '26 Email-Sending Domain Verification Requirement | 005316090 |
| Los dos niveles de verificación | Requisitos para enviar correo electrónico desde Salesforce | security_email_verification_requirements |
| Elegir entre DKIM y dominio autorizado | Determinar cómo verificar sus dominios de envío de correo electrónico | security_user_email_verification_domain_auth |
| Configurar el dominio de correo autorizado | Configurar un dominio de correo electrónico autorizado | security_email_auth_domain_setup |
| Omitir la verificación a nivel de usuario, y sus riesgos | Usar un dominio verificado para la verificación de correo electrónico a nivel de usuario | security_email_verification_user_bypass |
| Preguntas frecuentes | Email-Sending Domain Verification FAQ | 005316911 |
| Nota de versión | Verificar la propiedad de su dominio de correo electrónico | rn_general_verify_email_domain |
| El síntoma de la página de inicio de sesión al cambiar el correo | Salesforce Email Address Change Prompts Login With No Old Email Address Available | 000383887 |
Adónde ir después
- Crear usuarios y otorgar acceso a REDA: la tarea de incorporación que este requisito interrumpe.
- Configuraciones de correo masivo: donde se eligen las direcciones de envío de toda la organización, todas las cuales necesitan un dominio verificado.
- Envío de correos electrónicos desde REDA: el lado del usuario final del correo saliente.
- REDA Email Services: Descripción general: el procesamiento de correo entrante, al que este requisito no afecta.
- Protección de tu organización REDA: la configuración de seguridad más amplia en la que esto se inscribe.
Preguntas frecuentes
No. El registro lo publica quien administre el DNS de tu empresa: tu equipo de TI o tu registrador. REDA entrega el registro exacto que hay que crear y confirma después la verificación en Configuración de Salesforce.
No. Cada dominio y subdominio necesita su propia verificación: su propia entrada de dominio de correo autorizado con su propia clave y su propio registro DNS, o su propia clave DKIM activa.
No: cualquiera de los dos cumple el requisito. Salesforce recomienda DKIM porque además mejora la entregabilidad. La única razón para tener los dos son los sandbox: los dominios de correo autorizados se pueden copiar a un sandbox, las claves DKIM no.
Sí, a todos los tipos de sandbox. La verificación no se hereda al crear un sandbox, así que cada uno necesita la suya: importando un dominio de correo autorizado desde producción, configurando uno directamente, o activando la opción de dirección sustituta en la página Capacidad de entrega.
Normalmente minutos, pero la guía de Salesforce es dar hasta 72 horas. Salesforce no reintenta por su cuenta: después de esperar, vuelve a modificar y guardar el dominio autorizado para relanzar la consulta.
Es una opción admitida, pero Salesforce no la recomienda. Con ella desactivada, cualquiera que pueda crear usuarios en tu organización puede enviar correo como cualquier dirección de ese dominio, lo que supone un riesgo de suplantación. Trátalo como una decisión de seguridad de tu organización, mantén bien restringidos los permisos para crear usuarios si lo haces, y revísalo cuando termine la incorporación.
Las direcciones que terminan en @gmail.com, @hotmail.com o @outlook.com ya están exentas del requisito de dominio. Para cualquier otra que no puedas verificar, activa Usar una dirección de correo electrónico sustituta para dominios no verificados en la página Capacidad de entrega: el correo sigue saliendo, pero desde una dirección sustituta en el campo De que es propiedad de Salesforce.
¿Te resultó útil?