← Volver al soporte

Enviar el correo desde tu propia dirección

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

RutaQuién envíaQué necesitas para ello
Vía 2LRN4 (predeterminada)2LRN4nada
Desde el propio buzón de Microsoftvuestro Microsoft 365una conexión de Entra con permisos de envío
Desde el propio buzón de Googlevuestro Google Workspaceuna 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 correoservidor, 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:

  1. 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.
  2. 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.
  3. 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:

  1. Abre el registro de aplicación y ve a Permisos de API.
  2. 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.
  3. Concede el consentimiento del administrador (admin consent) para el nuevo permiso.
  4. Comprueba que la dirección del remitente es un buzón válido de Exchange Online.
  5. 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:

MensajeCausa y solución
Insufficient privileges to send mailFalta el permiso Mail.Send; añádelo como application permission.
Mailbox not foundLa dirección del remitente no existe como buzón; usa una dirección real, no un alias.
Unauthorized / Access deniedTodavía no se ha concedido el consentimiento del administrador.
El correo no llegaRevisa 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.

Lo que necesitas:

  1. Una cuenta de servicio en Google Cloud, con una clave JSON.
  2. 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.
  3. La dirección en Correo de soporte debe ser un buzón existente en ese Workspace.

La clave JSON la pegas en el campo Clave de la cuenta de servicio (JSON). 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.

Conviene saber: 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 nosotros solo usemos una. Coméntalo con tu administrador de TI antes de configurarlo.

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.

¿Atascado?

Haga su pregunta o reserve una breve demo. Le ayudamos a avanzar.