1. Pourquoi trois protocoles complémentaires ?

SMTP a été conçu en 1982 sans aucune notion d'authentification. N'importe quel serveur peut prétendre envoyer du courrier au nom de n'importe quel domaine. Trois RFC successives ont rebouché ce trou : RFC 7208 pour SPF, RFC 6376 pour DKIM, RFC 7489 pour DMARC. Aucune ne suffit seule. Combinées, elles offrent une chaîne d'identité solide.

L'analogie qui aide à les retenir : imagine un envoi recommandé à la frontière.

• SPF = la liste des transporteurs autorisés à présenter un colis au nom de l'expéditeur. Le douanier vérifie que le camion qui se présente figure bien sur la liste publique.
• DKIM = un cachet cryptographique apposé sur l'enveloppe au départ. Le destinataire vérifie que le cachet est intact et que la clé publique correspond au domaine annoncé.
• DMARC = l'instruction laissée au guichet : « si ni la liste ni le cachet ne sont alignés avec le nom du domaine sur le colis, alors mets-le en quarantaine ou rejette-le, et envoie-moi un rapport quotidien. »

3. DKIM — signature cryptographique du message

DKIM (DomainKeys Identified Mail, RFC 6376) ajoute un header DKIM-Signature au message au moment de l'envoi. Cette signature est calculée par le relais SMTP sortant à partir d'une clé privée. La clé publique correspondante est publiée dans le DNS sous un sélecteur (par exemple brevo._domainkey.example.com). Le serveur destinataire récupère la clé publique, vérifie la signature, et obtient deux informations critiques : le message n'a pas été altéré en transit, et il a bien été émis avec l'autorisation du propriétaire de la clé privée associée au domaine annoncé dans d=.

Exemple de header généré par un relais transactionnel :

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com;
    s=brevo; t=1748241600; h=from:to:subject:date:message-id;
    bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
    b=ZjC3rW7w9Yc... (signature base64 tronquée)

Les champs qui comptent côté setup :

• d=example.com — domaine signataire. C'est ce domaine qui doit être aligné avec le header From pour que DMARC valide.
• s=brevo — sélecteur. Pointe vers l'enregistrement DNS brevo._domainkey.example.com qui publie la clé publique.
• h=from:to:subject:date:message-id — liste des headers couverts par la signature. Si l'un d'eux est modifié en transit, la signature casse.

L'enregistrement DNS chez ton registrar est typiquement un CNAME qui pointe vers le DNS du relais (le relais gère la clé) :

; Type : CNAME
; Nom  : brevo._domainkey
; Valeur : brevo.brevo-1k.com.    (fourni par le provider)

Certains providers exposent directement la clé publique en TXT au lieu d'un CNAME. La procédure est identique du point de vue Odoo : rien à configurer côté Odoo, tout côté DNS et côté compte provider.

5. Setup type — Brevo + Odoo 19 + 3 records DNS

Cas concret : domaine example.com, relais transactionnel Brevo, instance Odoo 19 envoyant les notifications, les emails de devis et les newsletters. Cinq étapes, pas une de plus.

Étape 1 — Valider le domaine dans le compte Brevo

Dans l'interface Brevo : Senders, Domains & Dedicated IPs → Domains → Add a new domain. Saisir example.com. Brevo fournit immédiatement :

• 1 TXT de vérification de propriété (à supprimer une fois validée).
• 1 valeur SPF à inclure (spf.brevo.com).
• 2 CNAME DKIM (brevo1._domainkey et brevo2._domainkey — 2 sélecteurs pour rotation de clés).

Étape 2 — Publier les 3 records DNS

Chez le registrar (OVH, Cloudflare, Gandi…) :

; SPF
example.com.            IN  TXT     "v=spf1 include:spf.brevo.com ~all"

; DKIM
brevo1._domainkey       IN  CNAME   brevo1.brevo-1k.com.
brevo2._domainkey       IN  CNAME   brevo2.brevo-1k.com.

; DMARC
_dmarc.example.com.     IN  TXT     "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; pct=100"

Propagation DNS : de quelques minutes à 24h selon le TTL configuré. Brevo détecte automatiquement la validation et marque le domaine « authenticated ».

Étape 3 — Configurer le serveur SMTP sortant dans Odoo

Settings → Technical → Email → Outgoing Mail Servers → Create :

Champ	Valeur	Pourquoi
name	Brevo Transactionnel	Libellé interne.
smtp_host	smtp-relay.brevo.com	Hôte SMTP fourni par Brevo.
smtp_port	587	STARTTLS standard.
smtp_encryption	starttls	Chiffrement à la connexion.
smtp_authentication	login	Authentification login/password (pas OAuth2 pour Brevo).
smtp_user	login Brevo fourni	Identifiant compte SMTP.
smtp_pass	clé API SMTP Brevo	Pas le mot de passe du compte web.
from_filter	example.com	Point critique pour l'alignement DKIM — voir ci-dessous.

Étape 4 — Configurer le mail.alias.domain

Depuis Odoo 17, la configuration des adresses de bounce, catchall et default_from est centralisée dans le modèle mail.alias.domain (et non plus dans l'ancien paramètre système mail.catchall.domain — voir piège n° 3 plus bas).

Settings → Technical → Email → Alias Domains :

Champ	Valeur
name	example.com
bounce_alias	bounce → bounce@example.com
catchall_alias	catchall → catchall@example.com
default_from	notifications → notifications@example.com

L'effet : tout email sortant utilisera notifications@example.com comme expéditeur par défaut, et bounce@example.com comme Return-Path. Le domaine example.com est couvert par le SPF, donc le check SPF passe. Le domaine est signé DKIM par Brevo, donc d=example.com. Les deux sont alignés avec le header From : DMARC valide.

Étape 5 — Tester la chaîne complète

Bouton Test Connection sur la fiche ir.mail_server — vérifie l'authentification SMTP. Puis envoi d'un email réel vers un service de validation externe (check-auth@verifier.port25.com, mail-tester.com) qui renvoie un rapport détaillé sur SPF, DKIM et DMARC en quelques secondes. Score cible : 10/10.

7. Lire un rapport DMARC agrégé

Un rapport agrégé arrive quotidiennement à l'adresse rua=. Format : XML compressé en GZIP ou ZIP, envoyé par chaque opérateur (Google, Microsoft, Yahoo…). Extrait représentatif d'un rapport Google :

<feedback>
  <report_metadata>
    <org_name>google.com</org_name>
    <email>noreply-dmarc-support@google.com</email>
    <report_id>14831284727584810532</report_id>
    <date_range>
      <begin>1748131200</begin>
      <end>1748217599</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>none</p>
    <pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>185.34.32.7</source_ip>
      <count>42</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>pass</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <dkim><domain>example.com</domain><result>pass</result></dkim>
      <spf><domain>example.com</domain><result>pass</result></spf>
    </auth_results>
  </record>
</feedback>

Lecture utile :

• source_ip + count — quelle IP envoie en mon nom, combien de messages.
• policy_evaluated/dkim et spf — verdict DMARC pour chaque protocole.
• auth_results — résultats bruts, avant prise en compte de l'alignement.
• header_from — domaine présenté dans le header From.

Pattern à surveiller : une source_ip inconnue qui envoie en quantité avec dkim=fail ou spf=fail. C'est soit un ancien relais oublié dans le SPF, soit une newsletter tierce non autorisée, soit un usurpateur. Réaction : identifier l'IP, l'ajouter au SPF si légitime, ou passer la politique à p=quarantine si illégitime.

Récapitulatif

• SPF autorise les IPs sortantes au nom du domaine — TXT à la racine, attention aux 10 lookups.
• DKIM signe le message cryptographiquement — CNAME ou TXT sous le sélecteur, géré par le relais transactionnel.
• DMARC arbitre l'alignement et collecte les rapports — TXT sur _dmarc, démarre toujours en p=none.
• Côté Odoo 19, le pivot est from_filter sur ir.mail_server. Aligne-le avec le domaine signé par le relais.
• Le modèle mail.alias.domain (depuis v17) centralise bounce, catchall et default_from. Plus d'ICP mail.catchall.* à manipuler.
• Industrie 2026 : Google, Yahoo et Microsoft imposent SPF + DKIM + DMARC aux expéditeurs > 5 000/jour. Pas négociable.

Le couplage Odoo ↔ relais SMTP est plus subtil qu'un simple branchement de serveur. Une fois les 3 records DNS publiés et le from_filter aligné, les rapports DMARC convergent vers 100% d'authentification en quelques jours. Et le développeur Odoo récupère une chaîne d'envoi vérifiable, traçable et conforme.

Pour la suite : la prochaine fois qu'un ticket « les emails Odoo finissent en spam » arrive, le réflexe est de vérifier dans cet ordre — record SPF / record DKIM / enregistrement DMARC / champ from_filter / mail.alias.domain. Quatre-vingt-quinze pour cent des cas se résolvent dans ces cinq points.