Enviar el correo desde tu propia dirección guía

De forma predeterminada, 2LRN4 envía todo el correo a tus alumnos desde una dirección propia. Funciona, pero los empleados no siempre reconocen al remitente. Por eso puedes configurar que el correo salga desde la dirección de tu organización e incluso que se envíe realmente desde vuestro propio entorno de correo. Desde agosto de 2026 esto es posible para cualquier organización; antes estaba reservado a los clientes con un entorno de Microsoft.

Encuentras la opción en Organizaciones → tu organización → editar, bajo el apartado Soporte, en Ruta de envío para esta organización.

Las cuatro rutas

Ruta	Quién envía	Qué necesitas para ello
Vía 2LRN4 (predeterminada)	2LRN4	nada
Desde el propio buzón de Microsoft	vuestro Microsoft 365	una conexión de Entra con permisos de envío
Desde el propio buzón de Google	vuestro Google Workspace	una cuenta de servicio con delegación en todo el dominio
Vía el servidor de correo propio de la organización (SMTP)	vuestro servidor de correo	servidor, puerto y credenciales

Cuál encaja depende de dónde funcione vuestro correo. Si estáis en Microsoft 365 o en Google Workspace, elige la ruta correspondiente. Es la que ofrece la mejor entrega, porque así el correo sale de verdad de vuestro propio entorno.

Vía 2LRN4 (predeterminada)

El correo lo enviamos nosotros. Si en Correo de soporte indicas una dirección de tu propia organización, esa aparece como remitente; si lo dejas vacío, usamos la dirección de 2LRN4.

Ten cuidado con una dirección propia en esta ruta. El correo sale entonces de tu dirección, pero lo envía nuestro servidor. Muchas organizaciones han fijado en su DNS quién puede enviar en nombre de su dominio (SPF, DKIM y DMARC). Si ese ajuste es estricto, el servidor de correo receptor puede colocar esos mensajes en la carpeta de correo no deseado o incluso rechazarlos. Si tienes dudas, coméntalo con tu administrador de TI o elige una de las tres rutas de abajo, donde esto no influye.

Desde el propio buzón de Microsoft

El correo se envía a través de Microsoft Graph desde un buzón de vuestro propio entorno de Microsoft 365. El remitente y la entrega quedan bien por sí solos, porque el correo sale sin más de vuestro propio entorno de Microsoft.

En la plataforma necesitas tres cosas:

Una conexión de Entra en esta organización. Si todavía no la tienes, la pantalla te indica dónde crearla. Consulta también Sincronizar usuarios.
El registro de aplicación de esa conexión debe poder enviar correo. Si usas una conexión existente configurada solo para la sincronización de usuarios, normalmente aún no tiene ese permiso; abajo se explica qué añade tu administrador de TI.
La dirección en Correo de soporte debe ser un buzón existente en ese entorno, con permisos de envío. Un alias, o una dirección que solo existe sobre el papel, no sirve.

Lo que tu administrador de TI configura en Azure, en el registro de aplicación de la conexión existente:

Abre el registro de aplicación y ve a Permisos de API.
Añade un permiso mediante Microsoft Graph → Application permissions y elige Mail.Send. Utiliza únicamente application permissions; las delegated permissions no funcionan aquí, porque la plataforma envía sin ningún usuario con la sesión iniciada.
Concede el consentimiento del administrador (admin consent) para el nuevo permiso.
Comprueba que la dirección del remitente es un buzón válido de Exchange Online.
Limita el permiso a ese único buzón. Es el paso más importante y a menudo se pasa por alto. De forma predeterminada, Mail.Send vale para todo el entorno: técnicamente, el registro de aplicación puede entonces enviar en nombre de cualquier dirección de vuestro tenant, mientras que nosotros solo usamos una. Con una application access policy (directiva de acceso a aplicaciones) en Exchange Online limitas eso al buzón que indicas aquí.
Tu administrador de TI lo hace con dos comandos en Exchange Online PowerShell. Coloca primero el buzón en un grupo de seguridad con dirección de correo y vincula ahí el registro de aplicación:
```
New-DistributionGroup -Name "2LRN4 buzón de envío" -Type Security `
  -PrimarySmtpAddress "2lrn4-buzon-envio@tudominio.es" `
  -Members "noreply@tudominio.es"

New-ApplicationAccessPolicy `
  -AppId "" `
  -PolicyScopeGroupId "2lrn4-buzon-envio@tudominio.es" `
  -AccessRight RestrictAccess `
  -Description "2LRN4 solo puede enviar desde el buzón de envío"
```
Comprobar si ha salido bien:
```
Test-ApplicationAccessPolicy -Identity "noreply@tudominio.es" -AppId ""
```
El resultado debe ser Granted para ese buzón y Denied para cualquier otro. Cuenta con una hora hasta que el ajuste se haya aplicado en todas partes.

¿Funciona? Al final de esa misma pantalla está el botón Enviar un mensaje de prueba. Envía un solo mensaje a tu propia dirección, por exactamente el mismo camino que el correo a tus alumnos. Guarda primero los cambios, porque la prueba usa los ajustes guardados. Encima del botón aparece el resultado de la última comprobación, que hacemos automáticamente cada mañana.

Si recibes el aviso de que la ruta propia no ha funcionado y el mensaje se ha enviado a través de 2LRN4, el mensaje de prueba sí ha llegado, pero el ajuste todavía no es correcto. El motivo se indica junto al aviso.

Mensajes de error conocidos en esta ruta y qué hacer al respecto:

Mensaje	Causa y solución
Insufficient privileges to send mail	Falta el permiso `Mail.Send`; añádelo como application permission.
Mailbox not found	La dirección del remitente no existe como buzón; usa una dirección real, no un alias.
Unauthorized / Access denied	Todavía no se ha concedido el consentimiento del administrador.
El correo no llega	Revisa con tu administrador de TI los ajustes de SPF, DKIM y DMARC de vuestro dominio.

Desde el propio buzón de Google

El correo se envía a través de la Gmail API desde un buzón de vuestro Google Workspace. El remitente y la entrega quedan bien por sí solos, porque el correo sale sencillamente de vuestro propio entorno de Google.

En la plataforma necesitas tres cosas:

Una cuenta de servicio en Google Cloud, con una clave JSON. Más abajo se explica cómo la crea tu administrador de Google.
Delegación en todo el dominio para esa cuenta de servicio en la consola de administración de Google, únicamente con el scope https://www.googleapis.com/auth/gmail.send.
La dirección en Correo de soporte debe ser un buzón existente en ese Workspace. Es el buzón desde el que envía la plataforma; un grupo o un alias no funciona.

Lo que configura tu administrador de Google, en dos partes: primero la cuenta de servicio en Google Cloud y después el permiso en la consola de administración de Google.

Parte 1: la cuenta de servicio (Google Cloud Console)

Ve a console.cloud.google.com y elige o crea un proyecto para vuestra organización, por ejemplo "2LRN4 mail".
Activa la Gmail API: ve a APIs y servicios → Biblioteca, busca "Gmail API" y elige Habilitar. Sin este paso, Google rechaza todas las solicitudes.
Crea la cuenta de servicio: IAM y administración → Cuentas de servicio → Crear cuenta de servicio. Ponle un nombre reconocible, por ejemplo "2lrn4-mail". No hacen falta roles; puedes saltarte ese paso.
Crea una clave: abre la cuenta de servicio, ve a la pestaña Claves y elige Añadir clave → Crear clave → JSON. Se descarga un archivo JSON. Guárdalo en lugar seguro, porque en la práctica es la contraseña de esta cuenta.
Anota el ID de cliente de la cuenta de servicio. Está en la página de detalles bajo "ID único" y es un número de unos 21 dígitos. Lo necesitas en la parte 2.

Parte 2: permiso para enviar en nombre del buzón (consola de administración de Google)

Ve a admin.google.com, elige Seguridad → Control de acceso y datos → Controles de API y, al final, Gestionar la delegación en todo el dominio.
Elige Añadir nueva. En ID de cliente introduce el número de la parte 1, paso 5, y en Permisos de OAuth exactamente este único scope: https://www.googleapis.com/auth/gmail.send. No hacen falta más scopes, y es mejor no concederlos.
Elige Autorizar. Cuenta con entre unos minutos y una hora hasta que el ajuste se aplique en todas partes.

¿Por qué solo el scope de envío? La delegación en todo el dominio vale para el dominio entero: con ella, técnicamente la cuenta de servicio puede enviar en nombre de cualquier dirección de vuestro Workspace, aunque la plataforma solo use una. Con únicamente gmail.send, al menos no puede leer ni gestionar nada. Si quieres restringirlo más, puedes limitar la Gmail API por unidad organizativa en la consola de administración; coméntalo con tu administrador de TI.

En la plataforma

Elige la ruta Desde el propio buzón de Google de la organización. Abre el archivo JSON descargado en un editor de texto sencillo (no un procesador de textos) y pega el contenido completo, desde la primera { hasta la última }, en el campo Clave de la cuenta de servicio (JSON). En Correo de soporte indica el buzón desde el que se envía, y guarda.

La clave se guarda cifrada y ya no se muestra después de guardar; solo ves de qué cuenta de servicio es. Si más adelante quieres quitarla, puedes hacerlo con la casilla Eliminar esta clave; elige antes otra ruta, porque mientras esté seleccionada la ruta de Google la clave sigue siendo necesaria.

Mensajes de error conocidos en esta ruta y qué hacer al respecto (la línea con el motivo aparece en neerlandés):

Mensaje	Causa y solución
Esto no parece una clave de cuenta de servicio de Google: se requieren client_email y private_key	El texto pegado no es el archivo JSON completo. Abre el archivo en un editor de texto y pega todo, desde la primera `{` hasta la última `}`.
Geen Google-token … unauthorized_client	Falta la delegación en todo el dominio, está en otro ID de cliente, o el scope `gmail.send` no está incluido. Repasa la parte 2. ¿Lo acabas de configurar? Espera un poco, puede tardar hasta una hora.
Gmail weigerde het bericht … (HTTP 403)	Normalmente la Gmail API no está habilitada en el proyecto de Cloud (parte 1, paso 2), o la dirección de soporte no es un buzón real de este Workspace.
Gmail weigerde het bericht … (HTTP 400)	La dirección de soporte no existe, o es un grupo o un alias. Usa un buzón real.
Kon de JWT niet ondertekenen; is de private key geldig?	La clave está dañada, por ejemplo porque un procesador de textos cambió comillas o saltos de línea. Crea una nueva clave JSON en Google Cloud y pégala de nuevo.
El correo no llega	Comprueba con tu administrador de TI los ajustes SPF, DKIM y DMARC de vuestro dominio. Con Google Workspace normalmente ya están bien.

Vía el propio servidor de correo (SMTP)

Si no usáis Microsoft ni Google, puedes indicar vuestro propio servidor de correo: servidor, puerto, cifrado, nombre de usuario y contraseña. La contraseña se guarda cifrada y ya no se muestra después de guardar; si dejas el campo vacío en un cambio posterior, se mantiene la contraseña existente.

Comprueba con tu administrador de TI si ese servidor puede enviar en nombre de vuestro dominio, porque de lo contrario el correo puede acabar siendo rechazado igualmente.

Qué pasa si algo sale mal

Si el envío por vuestra propia ruta no funciona, por ejemplo porque una contraseña ha caducado, se ha retirado un permiso o se ha movido un buzón, el mensaje sale igualmente a través de 2LRN4. Así que tu alumno recibe su restablecimiento de contraseña o su invitación sin más; lo único es que entonces figura nuestra dirección como remitente, con vuestra dirección como dirección de respuesta. Es intencionado: un mensaje con vuestro dominio como remitente enviado desde nuestro servidor choca con los ajustes de SPF y DMARC de vuestro dominio, y acabaría en la carpeta de correo no deseado.

Al mismo tiempo, la organización queda marcada. Lo ves en la pantalla de la ruta de envío, y nosotros lo vemos en una comprobación diaria que determina, por organización, si todavía se puede enviar. Si el problema persiste, nos ponemos en contacto contigo.

Preguntas frecuentes

¿Cambia algo para nuestros alumnos?

Solo el remitente. El contenido, el formato y el momento del envío siguen siendo los mismos.

Usábamos el ajuste antiguo «Enable azure mailing». ¿Tenemos que hacer algo?

No. Las organizaciones que enviaban a través de Microsoft se han pasado automáticamente a la ruta Desde el propio buzón de Microsoft; todo sigue funcionando como antes.

¿Podemos volver a la ruta predeterminada?

Sí, siempre. Vuelve a poner la opción en Vía 2LRN4; el correo saldrá de nuevo desde nuestra dirección. Las credenciales guardadas se conservan hasta que las borres tú mismo, para que puedas volver a cambiar más adelante.

¿Vale esto también para las simulaciones de phishing?

No. Esas se envían a través de un entorno aparte y tienen sus propios ajustes de remitente.

¿Y el formulario de soporte de la plataforma?

Sigue la misma ruta que el resto de tu correo.