Brancher Odoo 19 sur un relais SMTP transactionnel se résume toujours aux mêmes cinq champs d'un ir.mail_server. Mais d'un fournisseur à l'autre, ce sont les credentials, le format des enregistrements DKIM et le mode d'authentification qui changent — parfois radicalement. Après Brevo, cet article compare trois autres voies : Mailjet (transactionnel pur), Amazon SES (brique AWS au coût marginal) et Microsoft 365 — ce dernier étant devenu, depuis le retrait de l'authentification basique en avril 2026, un cas à part qui n'accepte plus que l'OAuth.
L'objectif n'est pas de re-démontrer la mécanique du pivot from_filter ni la chaîne d'alignement DMARC — l'article HUB sur les 4 couches mail et l'article DKIM/SPF/DMARC les couvrent en détail. L'objectif est le différentiel par fournisseur : ce qu'il faut saisir dans Odoo, et ce qu'il faut poser dans la zone DNS, pour chacun des trois.
ir.mail_server que cet article décline.
1. Trois relais, trois philosophies
Mailjet, Amazon SES et Microsoft 365 ne se positionnent pas sur le même terrain. Le premier est un relais transactionnel clé en main, le deuxième une brique d'infrastructure facturée à l'unité, le troisième une messagerie d'entreprise détournée — avec des limites de débit serrées. Le tableau ci-dessous résume les positionnements vérifiés en juin 2026.
| Critère | Mailjet | Amazon SES | Microsoft 365 |
|---|---|---|---|
| Nature | Relais transactionnel | Brique cloud (AWS) | Messagerie d'entreprise |
| Authentification Odoo | Login / mot de passe | Login / mot de passe | OAuth 2.0 uniquement |
| Free tier 2026 | 200/jour (~6k/mois) | Crédits 200 $ / 6 mois | Inclus à l'abonnement |
| Tarif au volume | Forfaits mensuels | 0,10 $ / 1 000 emails | Sans surcoût (sous quota) |
| DKIM | 1 TXT (sélecteur mailjet) | 3 CNAME (Easy DKIM) | 2 CNAME (selector1/2) |
| Adapté au transactionnel externe | Oui | Oui (hors sandbox) | Non (quotas serrés) |
Trois enseignements se dégagent. Mailjet est le plus proche de Brevo : un setup SMTP standard, login/mot de passe. SES demande de la rigueur (identifiants dédiés, sortie de sandbox) mais offre le coût le plus bas à fort volume. Microsoft 365 n'est pas un relais transactionnel : il convient à des notifications internes à faible débit, et impose désormais l'OAuth.
2. Le socle commun en Odoo 19
Quel que soit le fournisseur, le serveur sortant se crée au même endroit : Settings → Technical (mode debug actif) → Email → Outgoing Mail Servers → New. Deux champs de l'ir.mail_server déterminent tout le comportement.
Le champ smtp_authentication propose en Odoo 19 trois valeurs de base — login (identifiant + mot de passe), certificate (certificat SSL client) et cli (paramètres de odoo.conf) — auxquelles les modules d'intégration ajoutent gmail et outlook (OAuth). Mailjet et SES utilisent login ; Microsoft 365 impose outlook.
Le champ smtp_encryption accepte cinq valeurs : none, starttls, starttls_strict, ssl, ssl_strict. Le suffixe _strict active la validation du certificat serveur — recommandée en production. Pour un port 587, starttls_strict est le bon choix… sauf pour Microsoft 365, dont le module impose starttls simple (voir section 5).
Le pivot reste le from_filter : il décide quel serveur traite un message selon le domaine du From:, et un réglage incorrect fait encapsuler l'expéditeur par Odoo (From: utilisateur via Notifications <notifications@…>), ce qui casse l'alignement DKIM. Ce mécanisme est identique à celui décrit pour Brevo — l'article précédent en détaille l'algorithme _find_mail_server(). Ce qui change d'un relais à l'autre tient donc en trois points : les credentials, le DKIM et l'endpoint. La figure ci-dessous les met en regard.
ir.mail_server décliné pour trois relais — seuls l'endpoint, les credentials et le format DKIM changent. Microsoft 365 se distingue par l'authentification OAuth et un mot de passe laissé vide.
3. Mailjet — le plus proche du gabarit standard
Mailjet (groupe Sinch) se configure exactement comme Brevo : un serveur SMTP standard en login/mot de passe. Les paramètres vérifiés en 2026 :
- SMTP host :
in-v3.mailjet.com - Port 587 : STARTTLS — recommandé
- Port 465 : SSL/TLS — alternative
- Port 2525 : fallback si 587 bloqué par l'hébergeur
- Authentification : login = API Key (clé publique), password = Secret Key
Côté DNS, la validation du domaine (« sender domain authentication ») dans l'interface Mailjet expose un enregistrement TXT DKIM à publier, généralement sous le sélecteur mailjet :
mailjet._domainkey.example.com TXT "k=rsa; p=MIGfMA0GCSq...<cle-publique-fournie-par-mailjet>"
# SPF recommandé par Mailjet (n'aligne PAS DMARC, voir section 6) :
example.com TXT "v=spf1 include:spf.mailjet.com ~all"
Toujours copier la valeur exacte affichée dans l'écran de validation : certains comptes Mailjet utilisent un sélecteur dédié distinct de mailjet. La configuration Odoo correspondante :
# À exécuter dans odoo-bin shell (mode debug), ou depuis une migration de module.
server = env['ir.mail_server'].create({
'name': 'Mailjet — example.com',
'from_filter': 'example.com', # domaine validé côté Mailjet
'smtp_host': 'in-v3.mailjet.com',
'smtp_port': 587,
'smtp_encryption': 'starttls_strict', # validation certificat en prod
'smtp_authentication': 'login',
'smtp_user': '<votre-api-key-mailjet>', # clé publique = identifiant
'smtp_pass': '<votre-secret-key-mailjet>', # secret = mot de passe
'sequence': 10,
})
server.test_smtp_connection() # équivalent du bouton "Test Connection"
env.cr.commit()Le free tier Mailjet 2026 plafonne à 200 emails/jour (6 000/mois) — utile pour valider l'intégration, mais à remplacer par un forfait payant dès la mise en production.
4. Amazon SES — la rigueur AWS
SES offre le coût le plus bas à fort volume (0,10 $ / 1 000 emails, sans paliers), mais impose deux étapes que les relais clé en main n'ont pas : la génération d'identifiants SMTP dédiés et la sortie de la sandbox.
L'endpoint suit le format régional email-smtp.<region>.amazonaws.com. Pour une PME francophone, eu-west-1 (Irlande) ou eu-central-1 (Francfort) gardent les données en Europe :
- SMTP host :
email-smtp.eu-west-1.amazonaws.com - Ports STARTTLS : 587, 2587 (et 25, souvent bridé)
- Ports TLS Wrapper : 465, 2465
Côté DNS, l'Easy DKIM génère trois enregistrements CNAME délégués à AWS, qui gère ensuite les clés et leur rotation :
# Le domaine cible peut être régional selon la zone SES : copier les valeurs exactes de la console.
<token1>._domainkey.example.com CNAME <token1>.dkim.amazonses.com
<token2>._domainkey.example.com CNAME <token2>.dkim.amazonses.com
<token3>._domainkey.example.com CNAME <token3>.dkim.amazonses.com
Selon la région, le domaine cible peut différer de dkim.amazonses.com : copier les valeurs exactes fournies par la console. Une alternative, BYODKIM (Bring Your Own DKIM), permet de publier sa propre clé en un seul TXT.
La configuration Odoo est identique à Mailjet, en login, avec les identifiants SMTP SES :
server = env['ir.mail_server'].create({
'name': 'Amazon SES — eu-west-1',
'from_filter': 'example.com',
'smtp_host': 'email-smtp.eu-west-1.amazonaws.com',
'smtp_port': 587,
'smtp_encryption': 'starttls_strict',
'smtp_authentication': 'login',
'smtp_user': '<ses-smtp-username>', # généré par "Create SMTP Credentials"
'smtp_pass': '<ses-smtp-password>', # dérivé, PAS la secret access key IAM
'sequence': 10,
})
server.test_smtp_connection()
env.cr.commit()
Par défaut, l'Envelope From d'un message SES appartient à un sous-domaine d'amazonses.com : l'alignement DMARC repose donc sur DKIM. Pour aligner aussi SPF, configurer un custom MAIL FROM (un sous-domaine du domaine d'envoi) et publier son enregistrement SPF — étape facultative mais recommandée pour une politique DMARC stricte.
5. Microsoft 365 / Outlook — le cas OAuth
Microsoft 365 est le fournisseur le plus particulier de cette série, pour une raison de calendrier : l'authentification basique (Basic Auth) du Client Submission SMTP a été retirée d'Exchange Online en avril 2026. Concrètement, smtp.office365.com en login/mot de passe (y compris via un App Password) renvoie désormais :
550 5.7.30 Basic authentication is not supported for Client Submission.
La seule voie pérenne pour le Client Submission est donc OAuth 2.0 (XOAUTH2) — et c'est précisément ce que propose le module d'intégration Outlook natif d'Odoo. Activé, il ajoute la valeur outlook au champ smtp_authentication et applique automatiquement une configuration verrouillée :
- Host forcé à
smtp.outlook.com, port 587, chiffrementstarttls(la variante_strictn'est pas requise ici). - Mot de passe laissé vide : l'OAuth ne l'utilise pas. Renseigner un mot de passe lève une erreur de validation.
- Username = adresse email du compte Microsoft 365, qui doit correspondre au compte ayant autorisé le jeton OAuth.
from_filterforcé à l'adresse de l'utilisateur : un serveur Outlook ne sert, par défaut, que sa propre adresse d'envoi.
Le flux côté Odoo : cocher « Outlook OAuth Authentication » sur le serveur sortant, renseigner le Client ID / Client Secret d'une application enregistrée dans Azure Active Directory (portail Azure → App registrations, avec le scope https://outlook.office.com/SMTP.Send), puis cliquer « Connect your Outlook account ». Un badge vert « Outlook Token Valid » confirme l'obtention du jeton. La documentation Odoo 19 détaille l'enregistrement de l'application Azure pas à pas.
Microsoft 365 applique par ailleurs des limites strictes : 30 messages par minute et 10 000 destinataires par jour et par boîte (ce sont les destinataires qui sont comptés, pas les messages). Odoo en tient compte : le module Outlook abaisse volontairement le débit interne à 10 messages/minute pour ce type de serveur, Microsoft classant plus vite en spam les rafales. Côté DKIM, le domaine custom se signe via deux CNAME (selector1._domainkey et selector2._domainkey, les deux sélecteurs permettant la rotation), activés depuis le portail de sécurité Microsoft.
6. L'alignement DMARC selon le relais
Un constat traverse les trois fournisseurs : dès qu'on passe par un relais, l'Envelope From (Return-Path) appartient au domaine du relais, pas au domaine visible dans le From:. Le SPF valide alors pour le relais mais n'aligne pas avec le domaine d'envoi. C'est donc la signature DKIM (d=example.com) qui porte l'alignement DMARC. La figure ci-dessous illustre ce déséquilibre, commun aux trois relais.
From:. L'Envelope From appartenant au relais, c'est la signature DKIM portée par le domaine d'envoi qui fait passer DMARC.
| Fournisseur | Envelope From par défaut | Levier d'alignement | SPF alignable ? |
|---|---|---|---|
| Mailjet | domaine Mailjet | DKIM (sélecteur mailjet) | Non nativement |
| Amazon SES | sous-domaine amazonses.com | DKIM (Easy DKIM) | Oui, via custom MAIL FROM |
| Microsoft 365 | domaine de l'expéditeur | DKIM (selector1/2) | Oui (SPF M365 standard) |
Microsoft 365 fait exception : comme l'envoi part de l'infrastructure du tenant et non d'un relais tiers en IPs partagées, le SPF Microsoft (include:spf.protection.outlook.com) peut aligner. Dans tous les cas, valider la signature DKIM reste le levier le plus fiable. Le détail de la chaîne d'alignement (relaxed vs strict, tags aspf/adkim) est traité dans l'article DKIM/SPF/DMARC.
7. Tester et diagnostiquer par fournisseur
La séquence de test est la même que pour Brevo : bouton Test Connection sur la fiche ir.mail_server, puis envoi réel via Send & Print sur un enregistrement (par exemple une commande de vente), et inspection de l'en-tête source du mail reçu :
Authentication-Results: mx.google.com;
dkim=pass header.i=@example.com header.s=<selecteur>;
dmarc=pass action=none header.from=example.com
La ligne dkim=pass doit porter sur le domaine d'envoi (@example.com), pas sur celui du relais. Les erreurs typiques diffèrent selon le fournisseur :
| Symptôme | Fournisseur | Cause probable |
|---|---|---|
554 Message rejected … not verified | SES | Compte encore en sandbox / destinataire non vérifié |
535 Authentication credentials invalid | Mailjet / SES | Secret Key ou identifiants SMTP erronés (clé IAM confondue) |
550 5.7.30 Basic authentication is not supported | Microsoft 365 | Tentative en login/mot de passe au lieu d'OAuth |
Emails bloqués en outgoing | Tous | Cron Email Queue Manager arrêté |
Le diagnostic fin se fait sur deux tables, comme pour tout relais : mail.mail (état outgoing / sent / exception, champ failure_reason contenant le retour SMTP brut) et mail.notification (statut par destinataire). Un email resté indéfiniment en outgoing trahit un cron Email Queue Manager arrêté plutôt qu'un problème de relais.
8. Pièges fréquents par fournisseur
- SES — sandbox oubliée. Le piège n°1 : une instance branchée sur un compte SES jamais sorti de sandbox n'écrit qu'aux adresses vérifiées. Demander le production access avant toute mise en service.
- SES — IAM ≠ SMTP. Utiliser une clé d'accès IAM comme mot de passe SMTP échoue. Passer par « Create SMTP Credentials » et conserver le couple username/password généré, par région.
- Microsoft 365 — Basic Auth coupé. Toute documentation conseillant
smtp.office365.comen login/mot de passe est périmée depuis avril 2026. Utiliser l'authentificationoutlook(OAuth) et réactiver « Authenticated SMTP » sur la boîte. - Mailjet — API REST vs SMTP. La paire API Key / Secret Key sert au relais SMTP ; ne pas la confondre avec une clé d'API marketing utilisée pour l'envoi en masse via l'API REST.
- Port 25 bloqué. La plupart des hébergeurs et clouds (dont EC2) bridgent le port 25 sortant. Utiliser 587 (STARTTLS) ou 2525/2587 selon le fournisseur.
from_filtervide en multi-domaines. Avec plusieurs serveurs sortants, unfrom_filtervide ou*route tous les emails vers le premier serveur parsequence, indépendamment du domaine duFrom:— et casse la signature DKIM attendue.
À retenir : un seul gabarit ir.mail_server couvre les trois fournisseurs. Mailjet calque le modèle Brevo, SES exige de la rigueur (identifiants dédiés, sortie de sandbox) en échange du coût le plus bas, et Microsoft 365 impose l'OAuth tout en restant cantonné aux faibles volumes. Dans les trois cas, l'alignement DMARC se joue sur la signature DKIM du domaine d'envoi.
L'article suivant de la série quittera le terrain des relais pour celui de la configuration interne : le modèle mail.alias.domain et la cohérence multi-société des adresses de bounce, catchall et notification.
Voir aussi dans ce parcours Infrastructure
Configurer Brevo SMTP en Odoo 19
Le gabarit ir.mail_server de référence : endpoint, DKIM par CNAME, from_filter et cinq pièges Brevo.
DKIM, SPF, DMARC pour Odoo
Détail cryptographique des records DNS, pivot from_filter, et alignement relaxed vs strict.
Série Tech-Email — Article 3/14 — Parcours Infrastructure emailing Odoo 19.
Articles complémentaires
Architecture mail Odoo — les 4 couches
HUB de la série : transport / message / template / mass et flux message_post → SMTP.
Actions serveur, cron et automations
ir.cron et base.automation — le moteur qui processe la queue mail.mail.
Sources officielles : Mailjet — SMTP relay configuration · AWS SES — SMTP credentials · Odoo 19 — Outlook 365 via Azure OAuth.