Envoyer les e-mails depuis ta propre adresse guide

Par défaut, 2LRN4 envoie tous les e-mails destinés à tes apprenants depuis une adresse qui lui est propre. Cela fonctionne, mais les collaborateurs ne reconnaissent pas toujours l'expéditeur. Tu peux donc faire en sorte que l'e-mail parte de l'adresse de ton organisation, et même qu'il soit réellement envoyé depuis votre propre environnement de messagerie. Depuis août 2026, c'est possible pour toutes les organisations ; auparavant, cela était réservé aux clients disposant d'un environnement Microsoft.

Tu trouves ce choix dans Organisations → ton organisation → modifier, sous la rubrique Assistance, à Mode d'envoi pour cette organisation.

Les quatre modes d'envoi

Mode d'envoi	Qui envoie	Ce qu'il te faut
Via 2LRN4 (par défaut)	2LRN4	rien
Depuis votre propre boîte aux lettres Microsoft	votre Microsoft 365	une connexion Entra avec des droits d'envoi
Depuis votre propre boîte aux lettres Google	votre Google Workspace	un compte de service avec délégation à l'échelle du domaine
Via le serveur de messagerie propre à l'organisation (SMTP)	votre serveur de messagerie	serveur, port et identifiants

Le mode qui convient dépend de l'endroit où tourne votre messagerie. Si vous êtes sur Microsoft 365 ou sur Google Workspace, choisis le mode correspondant. C'est ce qui donne la meilleure remise, car l'e-mail sort alors vraiment de votre propre environnement.

Via 2LRN4 (par défaut)

L'e-mail est envoyé par nos soins. Si tu indiques dans E-mail d'assistance une adresse de ta propre organisation, c'est elle qui apparaît comme expéditeur ; si tu laisses le champ vide, nous utilisons l'adresse de 2LRN4.

Attention si tu utilises ta propre adresse sur ce mode. L'e-mail vient alors de ton adresse, mais il est envoyé par notre serveur. Beaucoup d'organisations ont défini dans leur DNS qui peut envoyer au nom de leur domaine (SPF, DKIM et DMARC). Si ce réglage est strict, le serveur de messagerie destinataire peut placer ces messages dans les indésirables, voire les refuser. En cas de doute, parles-en avec ton administrateur informatique, ou choisis l'un des trois modes ci-dessous, où la question ne se pose pas.

Depuis votre propre boîte aux lettres Microsoft

L'e-mail est envoyé via Microsoft Graph depuis une boîte aux lettres de votre propre environnement Microsoft 365. L'expéditeur et la remise sont alors corrects d'eux-mêmes, puisque l'e-mail quitte tout simplement votre propre environnement Microsoft.

Dans la plateforme, tu as besoin de trois choses :

Une connexion Entra pour cette organisation. Si tu n'en as pas encore, l'écran t'indique où en créer une. Voir aussi Synchroniser les utilisateurs.
L'enregistrement d'application de cette connexion doit avoir le droit d'envoyer des e-mails. Si tu utilises une connexion existante configurée uniquement pour la synchronisation des utilisateurs, elle n'a généralement pas encore ce droit ; ci-dessous, tu trouves ce que ton administrateur informatique ajoute.
L'adresse indiquée dans E-mail d'assistance doit être une boîte aux lettres existante dans cet environnement, avec des droits d'envoi. Un alias, ou une adresse qui n'existe que sur le papier, ne fonctionne pas.

Ce que ton administrateur informatique règle dans Azure, dans l'enregistrement d'application de la connexion existante :

Ouvre l'enregistrement d'application et va dans Autorisations d'API.
Ajoute une autorisation via Microsoft Graph → Application permissions et choisis Mail.Send. Utilise exclusivement des application permissions ; les delegated permissions ne fonctionnent pas ici, car la plateforme envoie sans utilisateur connecté.
Accorde le consentement administrateur (admin consent) pour la nouvelle autorisation.
Vérifie que l'adresse d'expéditeur est une boîte aux lettres Exchange Online valide.
Limite l'autorisation à cette seule boîte aux lettres. C'est l'étape la plus importante, et elle est souvent oubliée. Par défaut, Mail.Send vaut pour tout l'environnement : techniquement, l'enregistrement d'application peut alors envoyer au nom de n'importe quelle adresse de votre tenant, alors que nous n'en utilisons qu'une. Avec une application access policy (stratégie d'accès aux applications) dans Exchange Online, tu limites cela à la boîte aux lettres que tu indiques ici.
Ton administrateur informatique le fait avec deux commandes dans Exchange Online PowerShell. Place d'abord la boîte aux lettres dans un groupe de sécurité à extension messagerie, puis rattache-lui l'enregistrement d'application :
```
New-DistributionGroup -Name "2LRN4 boîte d'envoi" -Type Security `
  -PrimarySmtpAddress "2lrn4-boite-envoi@tondomaine.fr" `
  -Members "noreply@tondomaine.fr"

New-ApplicationAccessPolicy `
  -AppId "" `
  -PolicyScopeGroupId "2lrn4-boite-envoi@tondomaine.fr" `
  -AccessRight RestrictAccess `
  -Description "2LRN4 ne peut envoyer que depuis la boîte d'envoi"
```
Vérifier que cela a fonctionné :
```
Test-ApplicationAccessPolicy -Identity "noreply@tondomaine.fr" -AppId ""
```
Le résultat doit être Granted pour cette boîte aux lettres, et Denied pour toutes les autres. Compte une heure avant que le réglage soit appliqué partout.

Est-ce que cela fonctionne ? En bas du même écran se trouve le bouton Envoyer un message de test. Il envoie un seul message à ta propre adresse, exactement par le même chemin que l'e-mail destiné à tes apprenants. Enregistre d'abord tes modifications, car le test utilise les réglages enregistrés. Au-dessus du bouton figure le résultat du dernier contrôle, que nous effectuons automatiquement chaque matin.

Si tu reçois le message indiquant que votre propre mode d'envoi n'a pas fonctionné et que le message est parti via 2LRN4, c'est que le message de test est bien arrivé mais que le réglage n'est pas encore correct. La raison y est alors indiquée.

Messages d'erreur connus sur ce mode et ce qu'il faut faire :

Message	Cause et solution
Insufficient privileges to send mail	L'autorisation `Mail.Send` est absente ; ajoute-la en tant qu'application permission.
Mailbox not found	L'adresse d'expéditeur n'existe pas comme boîte aux lettres ; utilise une vraie adresse, pas un alias.
Unauthorized / Access denied	Le consentement administrateur n'a pas encore été accordé.
L'e-mail n'arrive pas	Vérifie avec ton administrateur informatique les réglages SPF, DKIM et DMARC de votre domaine.

Depuis votre propre boîte aux lettres Google

L'e-mail est envoyé via la Gmail API depuis une boîte aux lettres de votre Google Workspace.

Ce qu'il te faut :

Un compte de service dans Google Cloud, avec une clé JSON.
La délégation à l'échelle du domaine pour ce compte de service dans la console d'administration Google, avec uniquement le scope https://www.googleapis.com/auth/gmail.send.
L'adresse indiquée dans E-mail d'assistance doit être une boîte aux lettres existante dans ce Workspace.

Tu colles la clé JSON dans le champ Clé du compte de service (JSON). Elle est conservée chiffrée et n'est plus affichée après l'enregistrement ; tu vois seulement à quel compte de service elle appartient. Si tu veux la retirer plus tard, tu peux le faire avec la case Supprimer cette clé.

Bon à savoir : la délégation à l'échelle du domaine vaut pour tout le domaine. Techniquement, le compte de service peut donc envoyer au nom de n'importe quelle adresse de votre Workspace, même si nous n'en utilisons qu'une. Discutes-en avec ton administrateur informatique avant de la mettre en place.

Via votre propre serveur de messagerie (SMTP)

Si vous n'utilisez ni Microsoft ni Google, tu peux indiquer votre propre serveur de messagerie : serveur, port, chiffrement, nom d'utilisateur et mot de passe. Le mot de passe est conservé chiffré et n'est plus affiché après l'enregistrement ; si tu laisses le champ vide lors d'une modification ultérieure, le mot de passe existant reste en place.

Vérifie avec ton administrateur informatique si ce serveur a le droit d'envoyer au nom de votre domaine, faute de quoi l'e-mail pourrait tout de même être refusé.

Ce qui se passe en cas de problème

Si l'envoi par votre propre mode échoue, par exemple parce qu'un mot de passe a expiré, qu'une autorisation a été retirée ou qu'une boîte aux lettres a été déplacée, le message part malgré tout via 2LRN4. Ton apprenant reçoit donc bien sa réinitialisation de mot de passe ou son invitation ; simplement, c'est notre adresse qui figure alors comme expéditeur, avec votre adresse comme adresse de réponse. C'est voulu : un message portant votre domaine comme expéditeur mais partant de notre serveur entre en conflit avec les réglages SPF et DMARC de votre domaine, et finirait dans les indésirables.

En même temps, l'organisation est signalée. Tu le vois sur l'écran du mode d'envoi, et nous le voyons dans un contrôle quotidien qui détermine, pour chaque organisation, si l'envoi est encore possible. En cas de problème persistant, nous prenons contact avec toi.

Questions fréquentes

Est-ce que quelque chose change pour nos apprenants ?

Seulement l'expéditeur. Le contenu, la mise en forme et le moment de l'envoi restent identiques.

Nous utilisions l'ancien réglage « Enable azure mailing ». Devons-nous faire quelque chose ?

Non. Les organisations qui envoyaient via Microsoft ont été basculées automatiquement vers le mode Depuis votre propre boîte aux lettres Microsoft ; tout continue à fonctionner comme avant.

Pouvons-nous revenir au mode par défaut ?

Oui, à tout moment. Remets le choix sur Via 2LRN4 ; l'e-mail repart alors de notre adresse. Les identifiants enregistrés sont conservés jusqu'à ce que tu les supprimes toi-même, pour que tu puisses rebasculer plus tard.

Cela vaut-il aussi pour les simulations de phishing ?

Non. Elles sont envoyées via un environnement distinct et disposent de leurs propres réglages d'expéditeur.

Et le formulaire d'assistance dans la plateforme ?

Il suit le même mode d'envoi que le reste de tes e-mails.