Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Se aplica a: 
Inquilinos de workforce (más información)
Los correos electrónicos de invitación son clave para recibir asociados como usuarios de colaboración de Microsoft Entra B2B. Aunque no es obligatorio, estos correos electrónicos proporcionan información esencial para ayudar a los destinatarios a decidir si aceptar su invitación. Incluyen un vínculo para obtener acceso rápido a los recursos más adelante.
Explicación del correo electrónico
Vamos a revisar algunos elementos del correo electrónico para que comprenda cómo usar sus funcionalidades. Estos elementos pueden parecer ligeramente diferentes en algunos clientes de correo electrónico.
Asunto
La línea de asunto del correo electrónico sigue este patrón: username te invitó a colaborar con primary domain.
Por ejemplo, si Megan Bowen te ha invitado desde el dominio Contoso, el asunto es: "Megan Bowen te ha invitado a colaborar con Contoso".
Dirección del remitente
La dirección From sigue este patrón: Invitaciones de Microsoft en nombre de primary domain<invites@<primary domain>.onmicrosoft.com>.
Por ejemplo, si Megan Bowen le invita desde Contoso, la dirección From es: "Invitaciones de Microsoft en nombre de Contoso [email protected]".
Antes de diciembre de 2025, las invitaciones de Microsoft se originan a partir de invites@microsoft.
Nota:
Para el servicio de Azure operado por 21Vianet en China, la dirección del remitente es <primary domain>.partner.onmschina.cn.
Para Microsoft Entra ID para la administración pública, la dirección del remitente es <primary domain>.onmicrosoft.us.
Responder a
En la respuesta al correo electrónico se indica el correo electrónico del invitador si está disponible, para que al responder al correo electrónico se vuelva a enviar un correo al invitador.
Advertencia de suplantación de identidad (phishing)
El correo electrónico comienza con una breve advertencia de suplantación de identidad (phishing), lo que aconseja a los usuarios que acepten solo las invitaciones esperadas. Es recomendable informar a los asociados con antelación de esperar su invitación.
Información del invitador y mensaje de invitación
El correo electrónico incluye el nombre y el dominio principal asociados a la organización que envía la invitación. Esta información debe ayudar al invitado a tomar una decisión fundamentada sobre la aceptación de la invitación. El invitador puede incluir un mensaje como parte de su invitación al directorio, grupo o aplicación, o cuando usan la API de invitación. El mensaje se resalta en la sección principal del correo electrónico. Si está disponible, se incluyen el nombre y la imagen de perfil del invitador. El mensaje mismo es un área de texto por lo que, por motivos de seguridad, no procesa etiquetas HTML.
Botón o enlace para aceptar la invitación y URL de redirección
La siguiente sección del correo electrónico muestra dónde se redirige el invitado después de aceptar la invitación, junto con un botón o vínculo para continuar. En el futuro, el invitado siempre podrá usar este vínculo para volver directamente a los recursos.
Sección de pie de página
El pie de página proporciona detalles adicionales sobre la invitación. Si la organización configuró una declaración de privacidad, el vínculo a la declaración se muestra aquí. De lo contrario, una nota indica que la declaración de privacidad de la organización no está disponible.
Cómo se determina el idioma
La siguiente configuración determina el idioma presentado al usuario invitado en el correo electrónico de invitación. La configuración se muestra en orden de prioridad. Si no configura una configuración, la siguiente de la lista determina el idioma.
- La propiedad messageLanguage del objeto inviteUserMessageInfo de la API Create invitation
- La propiedad preferredLanguage especificada en el objeto de usuario del invitado.
- Idioma de notificación establecido en las propiedades del inquilino de origen del usuario invitado (solo para inquilinos de Microsoft Entra).
- El idioma de notificación configurado en las propiedades del arrendatario de recursos
Si no establece ninguna de estas opciones, el idioma tiene como valor predeterminado inglés (EE. UU.).
Requisitos de correo electrónico de dominio personalizado
Cuando se envían correos electrónicos de invitación desde el dominio personalizado de su organización (en lugar del dominio MOERA predeterminado), se deben cumplir los siguientes requisitos para la entrega correcta.
Inquilino con correo habilitado
Su inquilino debe estar habilitado para correo y contar con una licencia de Exchange Online (EXO). Sin esto, los correos electrónicos de invitación no se pueden enviar desde un dominio personalizado.
Evitar los dominios MOERA (dirección de enrutamiento de correo electrónico en línea de Microsoft)
Los dominios MOERA (.onmicrosoft.com) no son muy recomendables para enviar correos electrónicos de invitación porque:
- Los dominios MOERA están sujetos a límites de limitación.
- Los correos electrónicos enviados desde dominios MOERA tienen una alta probabilidad de filtrarse como correo no deseado.
Para evitar estos problemas, establezca un dominio personalizado comprobado como dominio predeterminado para el inquilino.
Configuración de DNS (SPF, DKIM, DMARC)
Los registros de autenticación de correo electrónico deben configurarse en DNS en función de cómo la organización enruta el correo electrónico saliente. Ser propietario de un dominio personalizado en Microsoft Entra ID y verificarlo no es suficiente por sí solo: los registros DNS también deben estar configurados.
Correo saliente pasa directamente por Exchange Online: configure SPF, DKIM y DMARC en función de la configuración de Microsoft 365:
Rutas de correo saliente a través de una puerta de enlace de terceros (por ejemplo, Proofpoint o Mimecast): configure SPF, DKIM y DMARC en función de los requisitos de su proveedor de terceros, no Microsoft 365. El registro SPF debe autorizar las direcciones IP de envío del proveedor y la infraestructura de su proveedor controla la firma DKIM.
Importante
Si su organización no envía correo electrónico saliente directamente desde Exchange Online, no agregue los registros SPF/DKIM de Microsoft 365 a su DNS. En su lugar, alinee los registros de autenticación DNS con el servicio de terceros que controla el correo saliente.