Comment mettre en place un relay SMTP pour Azure avec Microsoft 365
Dans l’informatique, nous avons souvent besoin d’envoyer des emails de masse. Il peut s’agir d’une plateforme de ticketing qui informe de l’évolution d’un ticket, d’une application de vente qui envoie des confirmations de commandes, factures PDF etc. Bref, les usages ne manquent pas. ✉️
Et le problème c’est que bien souvent il faut payer des solutions professionnelles comme MailGun, Brevo, etc. Et le moins que l’on puisse dire c’est que les prix sont généralement élevés pour un besoin si simple. Je prends l’exemple des prix de Brevo ci-dessous qui est une des alternatives les plus connues (et encore l’offre à 6,33 n’existait pas il y a encore quelques temps).
J’ai toujours eu du mal à comprendre que ce genre de besoins puissent être vendus si cher – en particulier lorsque vous n’avez pas besoins de fonctionnalités supplémentaires comme le tracking ou les statistiques d’ouverture. Mais pour les usages simples, vous pouvez tout à fait utiliser votre compte Gmail / Google Workspace ou Office 365 (dans la mesure où le volume d’emails reste réduit).
Comprendre les limitations de Microsoft 365
Si vous souhaitez utiliser une BAL Microsoft 365 pour envoyer des emails transactionnels, n’oubliez pas que vous devez respecter les règles suivantes :
- SMTP Auth : 10 000 destinataires par jour max / utilisateur.
- SMTP Relay (connecteur IP) : 30 messages par minute et 10 000 destinataires par jour par organisation.
- Pas de bulk / marketing, sinon risque de blocage.
- Authentification :
- SMTP AUTH doit être activé pour le compte si nous utilisons Send-MailMessage ou équivalent.
- Possibilité d’utiliser un mot de passe d’application si MFA activé.
- En-têtes & filtrage :
- L’expéditeur (From) doit être autorisé dans ton domaine vérifié (SPF/DMARC/DKIM).
- Si tu envoies avec noreply@… il faut que ce domaine soit configuré dans ton tenant.
- Risque de mise en quarantaine ou de refus si SPF/DKIM non conformes.
Je vous propose de voir comment nous pouvons faire de relay SMTP avec un compte M365 qui dispose d’une BAL partagée Exchange Online. ⬇️
Mise en place des prérequis
Déjà, il vous faut un compte utilisateur M365 (UserMailBox) qui dispose d’une licence même un Exchange Online Plan 1 suffira dans votre cas. Ensuite, nous allons créer une boîte partagée (SharedMailBox). Dans mon cas, je lui ai donné le nom de « noreply » (vous comprenez sans aucun doute pourquoi). C’est l’adresse email qui sera affichée pour les expéditions.
Au niveau des délégations, j’ai donné à mon compte utilisateur (UserMailbox) la délégation de pouvoir faire du Send on Behalf et du Send as (c’est nécessaire car je ne vais pas m’authentifier directement avec la boîte partagée mais avec mon compte utilisateur à moi). Donc dans les 2 options ci-dessous, rajoutez bien la BAL associée à votre compte utilisateur.
Une fois que c’est fait, nous devons activer l’option « SMTP AUTH« . Par défaut, cette option est désactivée sur l’ensemble de notre Tenant et c’est très bien.
Mais nous allons toutefois activer cette option pour cette seule boîte mail partagée. Pour ce faire procédez-comme suit depuis une invite d’Exchange Online :
# Connexion à Exchange Online
Connect-ExchangeOnline
# Vérifier l’état actuel
Get-CASMailbox -Identity noreply@domaine.fr | Select SmtpClientAuthenticationDisabled
# Activer si besoin
Set-CASMailbox -Identity noreply@domaine.fr -SmtpClientAuthenticationDisabled $false
Nous allons donc utiliser notre compte personnel pour nous connecter à la boîte mail partagée. Pour ce faire et considérant que notre Tenant est sécurisé avec du MFA – nous allons avoir besoin d’une application password pour notre compte utilisateur.
Pour ce faire avec votre compte, allez directement sur l’URL suivante : https://mysignins.microsoft.com/security-info et créez un nouvel application password. Attention, la génération est unique donc notez bien le mot de passe. Il vous permettra d’éviter le MFA pour ce besoin de relay SMTP.
Nous pouvons désormais tester !
Tester en Powershell
Vous pouvez utiliser le script suivant depuis votre ordinateur pour tester l’envoie d’un email :
$O365User = "prenom.nom@domaine1.fr"
$FromAddress = "noreply@domaine1.fr"
$ToAddress = "destinataire@domaine2.com"
$AppPassword = "app-password" # A remplacer
$msg = New-Object System.Net.Mail.MailMessage
$msg.From = $FromAddress
$msg.To.Add($ToAddress)
$msg.Subject = "Test local SMTP"
$msg.Body = "✅ Mail envoyé depuis mon poste (SmtpClient)."
$smtp = New-Object System.Net.Mail.SmtpClient("smtp.office365.com", 587)
$smtp.EnableSsl = $true
$smtp.Credentials = New-Object System.Net.NetworkCredential($O365User, $AppPassword)
$smtp.Send($msg)
Write-Host "✅ Mail envoyé avec succès."
Après quelques secondes, vous devriez bien recevoir l’email de test dans votre BAL.
Utilisation via Azure Automation et un Key Vault
Pour aller plus loin, nous pouvons optimiser notre configuration afin qu’elle puisse être consommée par d’autres outils comme Azure Automation tout en protégant notre Application Password dans un Azure Key Vault. 🔐
Pour ce faire, procédez comme suit. Créez un Key Vault et ajoutez un secret avec l’application password que vous avez précédemment généré.
Une fois que c’est bon, vous pouvez créer un nouveau compte Azure Automation. J’ai fait de nombreux articles sur ce service donc je ne vais pas tout reprendre en termes de configuration. Ce qui est important c’est que dans la configuration de votre Azure Automation, vous devez définir des permissions sur l’Object Principal ID afin de lui permettre de voir le contenu de votre Key Vault et d’en consommer les données.
N’oubliez donc pas de lui attribuer les permissions « Key Vault Secrets User« . Cela va nous permettre de construire un code propre dans Azure Automation sans pour autant y mettre en clair notre mot de passe. 🔐
Si tout est bon, vous pouvez maintenant créer un Runbook avec le code PowerShell exemple que je vous propose ci-dessous :
# ====== PARAMÈTRES ======
$KeyVaultName = "keyvault-name"
$SecretName = "smtp-app-password" # Nom de mon secret qui contient mon app password
$O365User = "prenom.nom@domaine1.fr" # compte O365 lié au mot de passe d’appli
$From = "noreply@domaine1.fr" # shared mailbox (Send As requis)
$To = "destinataire@domaine2.com"
$Subject = "Test SMTP via Azure Automation + Key Vault (PS 5.1)"
$Body = "Hello, mail envoyé depuis Azure Automation (SMTP AUTH O365)."
$IsBodyHtml = $false
# =========================
# 1) Auth Azure via Managed Identity de l’Automation Account
Connect-AzAccount -Identity | Out-Null
# 2) Récupération du secret dans Key Vault
$secretObj = Get-AzKeyVaultSecret -VaultName $KeyVaultName -Name $SecretName
if ($secretObj.SecretValueText) {
$pwd = $secretObj.SecretValueText
} else {
$pwd = [Runtime.InteropServices.Marshal]::PtrToStringUni(
[Runtime.InteropServices.Marshal]::SecureStringToBSTR($secretObj.SecretValue)
)
}
# 3) Construction du message
$message = New-Object System.Net.Mail.MailMessage
$message.From = $From
$To.Split(';') | ForEach-Object { if ($_ -and $_.Trim()) { $message.To.Add($_.Trim()) } }
$message.Subject = $Subject
$message.Body = $Body
$message.IsBodyHtml = $IsBodyHtml
# 4) Client SMTP Office 365
$smtp = New-Object System.Net.Mail.SmtpClient("smtp.office365.com", 587)
$smtp.EnableSsl = $true
$smtp.Credentials = New-Object System.Net.NetworkCredential($O365User, $pwd)
try {
$smtp.Send($message)
Write-Output "✅ Mail envoyé depuis $From vers $($message.To -join ', ')"
}
catch {
Write-Error "❌ Échec envoi SMTP : $($_.Exception.Message)"
}
finally {
if ($message) { $message.Dispose() }
if ($smtp) { $smtp.Dispose() }
}
Il ne vous reste plus qu’à exécuter votre runbook pour confirmer le succès et l’envoie de votre email de test.
L’email a bien été envoyé… et nous l’avons reçu ci-dessous.
Conclusion
Nous avons mis en place une solution de Relay SMTP pour faire de l’email transactionnel via une BAL partagée sur notre tenant M365. Cette BAL partagée ne nous coûte rien en termes de licences.
De plus, avec Azure Automation, nous pouvons relayer des emails sans avoir à communiquer un mot de passe en clair dans notre code. Nous pourrions même aller plus loin avec une Azure Function par exemple afin de permettre la consommation de ce relay SMTP par d’autres services / personnes de notre organisation.
