Categoría: Técnico
Subcategoría: Seguridad
Nivel: Intermedio
Tiempo de lectura: 15 minutos
Como vimos en el artículo introductorio de esta serie, la seguridad de Salesforce está organizada en capas, y la primera de todas responde una pregunta que ninguna de las otras contesta: si este usuario puede entrar a la organización.
Ahí cerramos diciendo que esa puerta de entrada tiene un nombre.
Este artículo es sobre ese nombre. O más bien, sobre por qué no es solamente un nombre.
Una prueba simple
Hay una forma rápida de saber si My Domain es una función de branding.
Cambiá el nombre de tu dominio en producción y mirá qué se rompe.
Dejan de funcionar dos métodos de verificación de MFA: los autenticadores integrados y las llaves de seguridad. La razón es que esas credenciales quedan atadas a la URL contra la que fueron registradas. Cuando la URL cambia, quedan invalidadas y hay que volver a registrarlas. Si un usuario dependía sólo de esos métodos, no puede entrar hasta que eso ocurra.
Y no hace falta renombrar el dominio para provocarlo. Cambiar el sufijo cuenta. Activar Extended Domain en una sandbox cuenta. Y habilitar la partición del dominio en una Developer Edition, una scratch org, una patch org, una organización gratuita o un Trailhead Playground, también.
Se rompe el SSO, porque el proveedor de identidad estaba configurado contra la URL anterior. Y esa configuración recién se puede corregir después de desplegar el cambio, no antes.
Se rompen las named credentials que apuntaban a esa URL.
Y todas las conexiones a Salesforce se reinician: las sesiones activas se cierran y los tokens de seguridad quedan revocados.
La documentación es explícita sobre el riesgo. Si no preservás el acceso antes de desplegar el cambio, podés quedar bloqueado afuera de tu propia organización.
La salida se puede nombrar en una línea: registrar otro método de verificación antes del cambio, desconectar y volver a registrar las llaves después, y si alguien igual quedó afuera, un administrador le desconecta el método para que pueda entrar por otro.
Nada de eso es cosmético.
Si cambiar una URL desarma la autenticación de una organización entera, esa URL no es una dirección. Es la identidad contra la que está anclado el perímetro.
Qué es My Domain
Un dominio es el nombre que identifica a un servicio en internet. Un subdominio es un nombre que vive dentro de otro: en mycompany.my.salesforce.com, el dominio es my.salesforce.com y mycompany es el subdominio.
My Domain es eso: un subdominio propio dentro del dominio de Salesforce, usado como nombre de tu organización en las URLs de login y de aplicación.
Todas las organizaciones tienen uno por defecto. Si no te gusta el nombre, se puede cambiar.
Con enhanced domains, que es la versión actual de la función, ese nombre aparece en todas las URLs de la organización: páginas Lightning, Visualforce, archivos de contenido, sitios de Experience Cloud, Salesforce Sites y páginas de Setup.
Un detalle que ayuda a entender el lugar que ocupa: en la API de metadatos, el nombre del dominio es un campo de sólo lectura. No se cambia como una configuración cualquiera. Se cambia desde la página de My Domain en Setup, con un proceso propio.
Por qué es un cimiento y no una preferencia
Salesforce exige tener un My Domain para varias cosas que un admin da por sentadas.
Para configurar single sign-on con proveedores de identidad externos.
Para habilitar auth providers como Google o Facebook, y que los usuarios entren con una cuenta social.
Para personalizar la página de login con la marca de la empresa.
Para trabajar en varias organizaciones de Salesforce en el mismo navegador al mismo tiempo.
Y para preservar los deep links —los enlaces directos a un registro o una página— cuando la organización se mueve de instancia o migra de infraestructura.
Con My Domain, además, Salesforce queda habilitado como proveedor de identidad de la organización, y a partir de ahí se puede cambiar por otro.
Por eso este es el primer artículo de la serie. Los mecanismos que vienen después —tipos de autenticación, MFA, connected apps— asumen que esta pieza ya está resuelta.
El control de seguridad concreto: la política de login
Acá está el único mecanismo de My Domain que reduce superficie de ataque de forma directa.
Son dos controles separados, y la API de metadatos los expone con nombres que dicen exactamente lo que hacen.
canOnlyLoginWithMyDomainUrl. Si está en true, los usuarios tienen que usar la URL de login de My Domain. Si está en false, también pueden entrar por la URL con instancia de la organización y por login.salesforce.com.
doesApiLoginRequireOrgDomain. Lo mismo, pero para el acceso por API. Si está en true, las llamadas tienen que autenticarse contra la URL de la organización. Si está en false, sirve la página genérica de Salesforce.
El valor por defecto de los dos es false.
Eso merece un segundo de atención. La puerta propia existe desde el día uno, pero la puerta genérica sigue abierta hasta que alguien decide cerrarla. Tener My Domain desplegado no significa tener la política de login aplicada. Son dos cosas distintas, y sólo la segunda cambia quién puede intentar entrar.
¿Qué cambia cuando se cierra? Que la dirección genérica deja de abrir tu organización. Como el nombre de un My Domain es único, la documentación lo describe como una capa extra de seguridad: quien quiera intentar un acceso necesita saber primero cómo se llama tu dominio.
También hay un costo operativo, y conviene conocerlo antes y no después. En una sandbox, un admin sólo puede usar la acción Log In de la página de Sandboxes cuando canOnlyLoginWithMyDomainUrl está en false en esa sandbox. Endurecer la política ahí te saca el atajo desde producción.
Del lado de la API el efecto es simétrico: con la política activa, las URLs de login genéricas dejan de funcionar en llamadas SOAP.
La política de login no bloquea todo
Activar la opción que impide el login desde login.salesforce.com no apaga ese host por completo. El endpoint de login.salesforce.com sigue funcionando para solicitudes SAML y OAuth aunque la opción esté seleccionada.
Es una distinción que se pasa por alto seguido. La política gobierna el login interactivo de usuarios y el login por SOAP API. No gobierna el flujo entrante de un proveedor de identidad.
Navegar no es entrar
Hay un segundo control que se parece pero no lo es. instancedUrlRedirectHandling determina qué pasa cuando alguien visita una página de tu organización usando la URL con instancia: puede redirigirlo, redirigirlo con una advertencia, o no redirigirlo y exigir la URL de My Domain.
La documentación aclara el punto sin rodeos: ese campo no tiene ningún efecto sobre la capacidad del usuario de hacer login por la URL con instancia. Para eso está canOnlyLoginWithMyDomainUrl.
Uno gobierna la navegación. El otro gobierna el acceso.
My Domain no es un custom domain
Un My Domain usa sufijos de Salesforce: my.salesforce.com, my.site.com, my.salesforce-sites.com. El nombre de tu empresa aparece como subdominio, pero el dominio sigue siendo de Salesforce.
Un custom domain es un dominio propio, tipo www.example.com, que sirve contenido de tus sitios. El contenido vive en Salesforce, pero se entrega desde tu dominio.
En Salesforce, la palabra «custom» aplicada a dominios tiene ese significado específico. Vale la pena no mezclarlas, porque la elección entre una y otra tiene consecuencias: si usás un custom domain para autenticar contra tus sitios, un cambio de My Domain no afecta esa configuración de SSO ni esos métodos de verificación de MFA.
Enhanced domains: por qué el dominio tuvo que unificarse
Antes de enhanced domains, el contenido de una organización se servía desde varios dominios distintos. Una página que terminaba en lightning.force.com cargaba contenido almacenado en la organización desde una URL que terminaba en otro dominio.
Para el navegador, eso es una cookie de terceros: una cookie guardada bajo un dominio distinto del que estás visitando.
Los navegadores empezaron a bloquear ese tipo de cookies por defecto, empujados por regulación de privacidad y por presión de los usuarios. Y cuando el bloqueo se activaba, parte de Salesforce simplemente dejaba de cargar. El error solía mencionar cookies cross-domain o cross-site.
Enhanced domains resolvió eso con un cambio estructural: todo el contenido pasó a compartir un dominio común, así las cookies dejan de ser de terceros y se pueden compartir aunque el navegador bloquee las cross-site.
La función se forzó en Winter ’24 y ya no se puede desactivar en ninguna organización.
La API de metadatos muestra hasta dónde llegó esa línea. Hay un campo, isFirstPartyCookieUseRequired, que indica si se remueve el atributo SameSite=None de las cookies de Salesforce. En organizaciones creadas en Summer ’24 o después, viene activado por defecto.
Esto suele leerse como un tema de compatibilidad, y lo es. Pero también es perímetro. Que el navegador pueda distinguir con claridad qué contenido pertenece a tu organización y cuál no es una propiedad de seguridad, no sólo de funcionamiento.
Partitioned domains: el tipo de organización a la vista
En las organizaciones que no son de producción, el hostname incluye una palabra que indica de qué tipo son.
develop para Developer Edition. sandbox para sandboxes. scratch, patch, demo, y trailblaze para los Trailhead Playgrounds.
Las organizaciones de producción nunca llevan partición.
Las particiones requieren enhanced domains. Las sandboxes con enhanced domains están siempre particionadas, aunque la opción ni siquiera aparezca en Setup. Y las organizaciones nuevas que califican vienen particionadas por defecto, sin posibilidad de desactivarlo.
La razón declarada por Salesforce es de disponibilidad: las particiones le permiten desplegar cambios de servicio de forma escalonada por tipo de organización, así una Developer Edition puede recibir una actualización sin que la reciba producción al mismo tiempo.
El efecto secundario es más cotidiano. La URL te dice dónde estás parado. Para un admin que trabaja con varias organizaciones abiertas, esa información en la barra de direcciones vale más de lo que parece.
Salesforce Edge Network: el dominio como punto de entrada del tráfico
Hasta acá el dominio fue identidad. Acá se vuelve infraestructura.
Salesforce Edge Network enruta la solicitud de cada usuario a la ubicación de red más cercana, eligiendo el destino según la dirección IP de origen.
Lo que aporta en seguridad y rendimiento: conexiones TLS persistentes con cifrado de extremo a extremo, configuraciones de TCP optimizadas que reducen el tiempo de conexión, caché de contenido marcado como cacheable, enrutamiento al centro de datos más conveniente según condiciones reales de red, y protección contra ataques de denegación de servicio distribuido mediante un firewall de aplicaciones web integrado.
Salesforce requiere que las URLs de My Domain se enruten a través de Edge Network.
Y es una decisión de un solo sentido. En la API de metadatos, el campo useEdge es de sólo lectura, viene en true por defecto, y una vez que se activa desde Setup ya no se puede volver a poner en false.
El método de enrutamiento sí se elige. global es el valor por defecto y manda cada solicitud a la ubicación más cercana al origen. regional limita el enrutamiento a una región, lo que puede ayudar con requisitos de residencia de datos a costa de rendimiento y de recuperación ante desastres. gsr existe para un caso puntual: esquivar nodos de red en Medio Oriente donde los usuarios enfrentan bloqueos de firewall.
No todo el tráfico pasa por ahí. Quedan afuera, entre otras, las URLs que contienen el nombre de instancia, los sitios con dominios terminados en .force.com, y las organizaciones alojadas en centros de datos de arquitectura aislada gubernamental.
Cambiar el dominio es un evento de identidad
Volvamos al principio, ahora con el mecanismo a la vista.
Cambiar un My Domain tiene tres pasos: guardar el cambio, que Salesforce provisione los nuevos dominios, y desplegarlos. Hasta que no se despliega, todos los usuarios siguen usando el dominio anterior.
Y hay algo que falta en esa lista: probar.
No es un olvido. Por la naturaleza del proceso, los dos juegos de dominios no pueden estar vivos al mismo tiempo. No se puede probar un cambio provisionado pero no desplegado. Sólo se puede probar después de desplegarlo.
Por eso la recomendación no es una formalidad: el cambio se despliega y se prueba primero en una sandbox, y recién después en producción. Si no lo probás antes, tus usuarios van a encontrar el problema antes que vos.
Las redirecciones desde las URLs anteriores existen y están habilitadas por defecto después de un despliegue. Pero la propia documentación advierte que no son una solución permanente. No todos los servicios saben procesar una redirección, y cada redirección agrega un paso a la carga de la página.
Hay una regla que conviene tener presente: Salesforce sólo redirige el último juego de URLs anteriores. Si cambiás el dominio dos veces, las URLs del primero dejan de redirigirse, y ese nombre queda disponible para que lo tome otro cliente.
Para encontrar dónde quedaron referencias viejas, existe un registro. Activando el log de redirecciones, Salesforce genera un archivo del tipo de evento Hostname Redirects que incluye el referrer y el origin de cada solicitud redirigida. Ese dato es lo que te permite descubrir las URLs tuyas que viven fuera de Salesforce: en tu sitio web, en firmas de correo, en materiales de marketing.
Lo que está pasando ahora con las URLs con instancia
Las organizaciones creadas antes de Winter ’20 no tenían My Domain por defecto. Sus usuarios entraban por hostnames que contenían el nombre de instancia, del estilo na42.salesforce.com, y el código y las llamadas a la API usaban esas mismas URLs.
Ese camino se está cerrando, y el cronograma ya está en curso.
En Spring ’26 se cortaron las redirecciones para los hostnames legacy en organizaciones de producción y demo. Con esa aplicación, no se pueden volver a habilitar en ninguna organización.
Desde Summer ’26 se puede probar el bloqueo del tráfico de API que usa una URL de instancia incorrecta, mediante una opción en la sección de redirecciones de la página de My Domain. La documentación recomienda hacer esa prueba después del 18 de junio de 2026, por un problema conocido que podía devolver errores en logins SOAP desde páginas Visualforce.
Y con Winter ’27 termina el soporte para ese tráfico, de forma escalonada, poco después de que cada organización reciba la release. El despliegue de Winter ’27 arrancó en agosto de 2026 para sandboxes y en septiembre de 2026 para producción.
La alternativa está documentada y es sencilla de aplicar. En código Apex, el método getOrgMyDomainHostname() de la clase System.DomainCreator devuelve el hostname correcto y sigue funcionando después de un cambio de dominio. En integraciones por API, los valores serverUrl o metadataServerUrl que devuelve la solicitud de login cumplen la misma función.
La lógica de fondo es la misma de todo el artículo. El nombre de instancia puede cambiar en un mantenimiento de rutina o en una migración de infraestructura. El nombre de tu dominio, no.
La puerta ya tiene nombre
My Domain no es la función que le pone tu marca a la URL. Es la que hace que tu organización tenga una identidad propia en la red, y que esa identidad sea el punto contra el que se anclan la autenticación, las sesiones, las integraciones y el tráfico.
Todo lo que viene en esta serie se apoya acá.
Pero saber cómo se llama la puerta no alcanza. Falta la pregunta siguiente, y es la que abre el próximo artículo: la autenticación.
¿Cómo demostrás que sos quien decís ser cuando llegás a ella?
Para seguir profundizando
Si querés profundizar en este tema, podés consultar la documentación oficial de Salesforce.
