tva
← Insights

Configurer une boîte mail pour votre agent IA dédié à un projet

Tôt ou tard, l'agent IA que vous avez construit pour un projet a besoin d'une adresse e-mail. Le modèle de bot Telegram que nous avons décrit dans Construire un assistant IA dédié à un projet via Telegram gère la messagerie en temps réel, mais le mail est un canal différent — notifications de services, confirmations de fournisseurs, réinitialisations de mot de passe OAuth, correspondance backoffice avec des humains qui ne sont pas sur Telegram. Vous pouvez acheminer ce courrier vers une adresse personnelle et composer avec le bruit, ou donner au projet sa propre boîte mail sur un sous-domaine dédié.

Ce guide couvre la deuxième option : une boîte mail dédiée sur un sous-domaine de projet, avec DKIM, SPF et DMARC correctement configurés. Le modèle utilise un fournisseur pour le DNS (Cloudflare dans notre cas) et un fournisseur distinct pour le système de messagerie (Opalstack) — ce que la plupart des petites structures finissent par adopter : le DNS là où réside déjà le domaine apex, le mail chez le fournisseur qui offre un IMAP décent, un accès API propre et une réputation qui passe les filtres de Gmail.

L'ensemble de la configuration se résume à quatre appels API et trois enregistrements DNS. Avec une bonne préparation, cela prend une dizaine de minutes de bout en bout. Nous montrons les appels, la vérification, et les pièges dans lesquels nous sommes tombés la première fois.

Ce que ce guide résout

  • Un sous-domaine de projet (system.example.com) sans infrastructure mail
  • Les mails entrants vers une adresse dédiée au projet qui rebondissent faute d'enregistrement MX
  • Les mails sortants du projet qui échouent aux vérifications DKIM chez Gmail et atterrissent dans les spams
  • Des enregistrements SPF et DMARC qui existent mais n'ont rien à authentifier
  • Un agent IA qui a besoin d'un canal e-mail sans passer par votre compte personnel

Ce dont vous aurez besoin

  • Un domaine apex que vous contrôlez, avec un DNS chez un fournisseur qui expose une API (Cloudflare, Route53, DigitalOcean DNS, etc.)
  • Un fournisseur mail qui supporte l'ajout de domaines via API, génère les clés DKIM à la création du domaine et expose des endpoints IMAP/SMTP (Opalstack, Mailcow, Migadu, Fastmail, etc.)
  • Des tokens API pour les deux fournisseurs, stockés quelque part depuis lequel vous pouvez les appeler en shell
  • dig, openssl s_client et un interpréteur Python pour la vérification
  • Une quinzaine de minutes environ

Pourquoi combiner deux fournisseurs

Le réflexe habituel est de tout regrouper chez un seul fournisseur — héberger le site, le DNS et la boîte mail au même endroit. Ça fonctionne jusqu'au moment où l'un des trois éléments doit évoluer indépendamment. Nous avons détaillé le cadre de décision pour choisir entre services groupés et spécialistes dédiés dans L'auto-hébergement : quand le SaaS coûte plus cher que votre propre infrastructure, et la même logique s'applique ici à plus petite échelle.

Dans notre cas, le DNS du domaine apex est chez Cloudflare pour la résolution AnyCast, le proxying des sites publics et l'API pour la gestion automatisée des enregistrements. Le système de messagerie est chez Opalstack parce que leur coût par boîte est négligeable, la réputation de leur serveur IMAP est saine et leur API est l'une des plus propres dans l'espace de l'hébergement mail en Europe. On ne déplace pas le DNS pour suivre le mail, et on ne déplace pas le mail pour suivre le DNS. Le coût de les faire coexister se limite à trois enregistrements DNS et un seul modèle mental : le fournisseur DNS dit au monde où va le courrier ; le fournisseur mail le reçoit, le stocke et le signe.

Cette séparation a une importance opérationnelle : elle limite le rayon d'impact. Une panne du fournisseur DNS stoppe les nouvelles décisions de routage, mais les mails déjà en transit vers les hôtes MX continuent d'arriver. Une panne du fournisseur mail stoppe la livraison, mais les résolutions DNS fonctionnent toujours. Si nous avions tout centralisé, les deux couches auraient défailli ensemble. Le même raisonnement apparaît dans notre architecture de production pour l'empilement de reverse proxies — séparation des responsabilités, chaque couche remplaçable isolément.

Boîte dédiée, alias de redirection ou inbox SaaS

Avant de créer quoi que ce soit, choisissez le bon niveau de dédicace. Les trois options ne sont pas équivalentes.

Une boîte dédiée, c'est une vraie inbox qui conserve les mails, possède des identifiants IMAP et peut émettre et recevoir. Coût : environ un à trois euros par mois chez un fournisseur mail auto-hébergé, plus le travail de configuration via API. C'est ce qu'utilise l'agent IA quand il a vraiment besoin de lire des mails — pour analyser les confirmations de fournisseurs entrants, gérer les notifications de services, entretenir un fil de discussion avec un interlocuteur humain sur plusieurs échanges.

Un alias de redirection, c'est une adresse virtuelle qui redirige simplement vers une boîte existante. Coût : zéro, configuration uniquement. C'est le bon choix quand l'agent IA a seulement besoin de recevoir à une adresse au nom du projet, mais que la lecture et le traitement effectifs se font dans une inbox humaine déjà existante. La contrepartie : pas d'accès IMAP pour l'agent, pas de filtrage par projet côté destination, et aucun chemin de rollback propre quand le projet se termine — le nettoyage des alias tombe dans l'oubli.

Une inbox SaaS, c'est un service comme Postmark, Mailgun Inbound ou AWS SES avec des règles de réception. Coût : facturation au message, plus le travail d'intégration de l'agent IA dans les récepteurs webhook. C'est le bon choix quand l'agent doit gérer un volume important, router les mails par règles d'en-têtes ou déclencher des workflows automatisés à chaque message. Pour un agent de projet qui gère des dizaines à quelques centaines de messages par mois, c'est disproportionné.

Pour le cas d'usage décrit dans l'article sur l'assistant IA Telegram — un opérateur humain, deux collaborateurs, un bot adossé à Claude — la boîte dédiée est le bon choix. L'agent dispose d'une vraie adresse qu'il peut lire en IMAP, utiliser en émission via SMTP, et qui vit et meurt proprement avec le projet.

Étape 1 : Enregistrer le sous-domaine dans votre système mail

Le fournisseur mail doit savoir que votre sous-domaine de projet fait partie de ses domaines avant d'accepter du courrier pour lui. C'est cet appel qui génère également la paire de clés DKIM.

POST https://my.mailhost.example/api/v1/domain/create/
Authorization: Token <YOUR_MAIL_API_TOKEN>
Content-Type: application/json

[{"name": "system.example.com"}]

La réponse contient trois champs importants : l'UUID du domaine (nécessaire pour le nettoyage et le mapping d'adresse ultérieur), le champ state (généralement PENDING_CREATE pendant quelques secondes, puis READY), et un champ dkim_record avec une valeur TXT entièrement formatée, prête à coller dans le DNS :

{
  "id": "<DOMAIN_UUID>",
  "state": "PENDING_CREATE",
  "name": "system.example.com",
  "dkim_record": "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4G..."
}

Interrogez l'API jusqu'à ce que state passe à READY, puis capturez la valeur de dkim_record. Vous la collerez telle quelle chez le fournisseur DNS à l'étape suivante. Si l'appel de création échoue avec une erreur invalid hostname, la cause la plus fréquente est que votre fournisseur mail ne prend en charge que les domaines de deuxième niveau et refuse les sous-domaines à trois niveaux. Ouvrez un ticket de support ; en pratique, nous n'avons encore jamais rencontré de fournisseur qui refuse.

Vérifiez la taille de la clé DKIM avant de continuer. Une valeur dkim_record inférieure à environ 250 octets correspond à une clé RSA 1024 bits ; les clés 2048 bits font environ 380 à 420 octets. Le NIST a abandonné RSA 1024 bits en 2013, et Gmail, Microsoft, Yahoo et AWS SES considèrent 2048 bits comme le standard 2026 — les clés 1024 bits s'authentifient encore mais sont perçues comme un signal faible par les filtres anti-spam d'entreprise. Si votre fournisseur vous laisse choisir, optez pour 2048 ; un défaut 1024-only est un signal sur le choix du fournisseur.

Étape 2 : Configurer les enregistrements DNS

Trois enregistrements, tous créés chez votre fournisseur DNS pour le sous-domaine du projet. Aucun ne peut être proxifié via l'edge de Cloudflare — les enregistrements MX et TXT doivent être DNS-only, et l'API Cloudflare retombe silencieusement sur DNS-only si vous définissez proxied: true, mais il est plus propre de le définir explicitement.

Les deux enregistrements MX indiquent aux expéditeurs où livrer le courrier. La plupart des fournisseurs mail exploitent deux hôtes MX ou plus avec une priorité égale pour le failover en round-robin :

POST https://api.dnsprovider.example/zones/<ZONE_ID>/dns_records

{"type":"MX","name":"system.example.com",
 "content":"mx1.de.mailhost.example","priority":10,
 "ttl":3600,"proxied":false}

{"type":"MX","name":"system.example.com",
 "content":"mx2.de.mailhost.example","priority":10,
 "ttl":3600,"proxied":false}

L'enregistrement TXT DKIM utilise la valeur dkim_record de l'étape 1, placée sous dkim._domainkey.<sous-domaine> :

{"type":"TXT",
 "name":"dkim._domainkey.system.example.com",
 "content":"v=DKIM1; k=rsa; p=MIGfMA0G...",
 "ttl":3600,"proxied":false}

Si la clé publique DKIM dépasse 255 octets (ce qui est le cas pour les clés RSA 2048 bits), vous devrez la découper en plusieurs blocs entre guillemets : "bloc1" "bloc2". La plupart des fournisseurs DNS gèrent ce découpage automatiquement dans leur API ; si le vôtre ne le fait pas, c'est à vous de le faire.

Les enregistrements SPF et DMARC se définissent une fois, sur le sous-domaine lui-même et sur _dmarc.<sous-domaine>. SPF indique aux destinataires quelles IPs sont autorisées à envoyer pour ce domaine ; DMARC leur dit quoi faire en cas d'échec SPF ou DKIM :

{"type":"TXT","name":"system.example.com",
 "content":"v=spf1 include:spf.mailhost.example ~all",
 "ttl":3600,"proxied":false}

{"type":"TXT","name":"_dmarc.system.example.com",
 "content":"v=DMARC1; p=none; rua=mailto:[email protected]; aspf=r; adkim=r",
 "ttl":3600,"proxied":false}

Démarrez DMARC avec p=none. C'est le mode surveillance — les destinataires envoient des rapports agrégés à l'adresse rua, mais aucun mail n'est rejeté sur la base de la politique. Le déploiement standard dure deux à six semaines en p=none, jusqu'à ce que les rapports agrégés montrent au moins 98 % de conformité sur les mails légitimes, puis une montée en charge progressive via le tag pct= — par exemple p=quarantine; pct=25 pendant deux semaines, puis pct=75, puis pct=100, puis enfin p=reject. Passer directement à p=reject sur un tout nouveau domaine est un moyen sûr de perdre ses propres mails légitimes avant d'avoir validé le chemin de signature DKIM.

Étape 3 : Créer la boîte mail et le mapping d'adresse

Le modèle de données du fournisseur mail distingue généralement deux ressources : un mailuser (le compte IMAP avec ses identifiants et un quota) et une adresse (la chaîne local@domaine qui achemine le courrier vers un mailuser). Ils sont séparés parce que le même mailuser peut être la destination de plusieurs adresses différentes sur un même domaine ou des domaines différents.

Générez un mot de passe robuste et créez le mailuser. La convention de nommage varie selon les fournisseurs ; le modèle courant est <local>_<domaine-avec-underscores>. Attention à la limite de longueur — la plupart des fournisseurs plafonnent les noms de mailuser à 32 caractères, ce qui est facile à dépasser avec un sous-domaine un peu long :

import secrets, string
alphabet = string.ascii_letters + string.digits + "!@#%^&*-_=+"
password = ''.join(secrets.choice(alphabet) for _ in range(32))

# Puis :
POST /api/v1/mailuser/create/
[{"name": "bot_system_example_com",
  "imap_server": "<IMAP_SERVER_UUID>",
  "password": password}]

Une fois le mailuser à l'état READY, créez le mapping d'adresse qui relie local@sous-domaine à celui-ci :

POST /api/v1/address/create/
[{"source": "[email protected]",
  "destinations": ["<MAILUSER_UUID>"],
  "forwards": []}]

Le tableau forwards sert à indiquer des adresses externes supplémentaires qui doivent recevoir une copie. Laissez-le vide à moins de vouloir réellement que la boîte transfère en parallèle vers une inbox humaine — ce qui est pratique en phase de passation de projet, mais source de confusion sur le long terme.

Étape 4 : Vérifier la configuration de bout en bout

Quatre vérifications, dans l'ordre. Ne sautez pas le bouclage local — c'est le seul test qui confirme que le routage entrant atteint effectivement la boîte.

Propagation DNS. Les fournisseurs AnyCast de niveau Cloudflare propagent généralement en moins d'une minute. Bouclez jusqu'à ce que les deux enregistrements apparaissent :

for i in $(seq 1 36); do
  mx=$(dig +short system.example.com MX)
  dkim=$(dig +short dkim._domainkey.system.example.com TXT)
  if [ -n "$mx" ] && [ -n "$dkim" ]; then break; fi
  sleep 5
done
echo "MX: $mx"
echo "DKIM: $dkim"

Connexion IMAP. Vérifiez que les identifiants fonctionnent et que la boîte est bien adossée à une inbox :

openssl s_client -crlf -connect imap.mailhost.example:993 -quiet
a1 LOGIN bot_system_example_com <password>
a2 SELECT INBOX

Réponse attendue : a1 OK Logged in suivi de la confirmation SELECT indiquant EXISTS 0 pour une boîte fraîchement créée.

Bouclage local. Le meilleur test de bout en bout : envoyer un mail depuis la nouvelle adresse vers elle-même et vérifier qu'il arrive en IMAP. Cela valide l'intégralité du chemin — authentification SMTP, signature DKIM, résolution MX, acceptation du mail, livraison en boîte, visibilité IMAP — sans dépendre du filtre anti-spam d'un fournisseur externe :

import smtplib, ssl, imaplib, time
from email.message import EmailMessage

msg = EmailMessage()
msg["From"] = "[email protected]"
msg["To"]   = "[email protected]"
msg["Subject"] = "loopback test"
msg.set_content("hello self")

with smtplib.SMTP("smtp.mailhost.example", 587) as s:
    s.starttls(context=ssl.create_default_context())
    s.login("bot_system_example_com", "<password>")
    s.send_message(msg)

time.sleep(10)
imap = imaplib.IMAP4_SSL("imap.mailhost.example", 993)
imap.login("bot_system_example_com", "<password>")
imap.select("INBOX")
typ, search = imap.search(None, "ALL")
print("inbox count:", len(search[0].split()))

Dans les en-têtes du mail livré, cherchez la ligne Authentication-Results. Une configuration correcte affiche spf=pass avec le bon smtp.mailfrom et un en-tête DKIM-Signature avec d=<votre sous-domaine> et s=dkim. Si ces éléments sont présents, toute la chaîne fonctionne ; la seule variable restante est la perception qu'ont les destinataires externes de votre domaine, que les rapports DMARC vous renseigneront dans les jours suivants.

Envoi externe. Envoyez un mail à une adresse externe que vous pouvez vérifier — un Gmail personnel, une boîte pro séparée, quelque chose hors de votre système. Confirmez qu'il arrive en inbox, pas dans les spams. Si le tout premier envoi depuis un nouveau domaine atterrit dans les spams, la cause la plus fréquente est l'absence de réputation pour ce domaine expéditeur ; la montée en réputation est progressive, mais un seul mail de test devrait passer proprement, car le destinataire évalue DKIM et SPF sur leurs mérites propres, indépendamment du volume d'envoi historique.

Pièges courants

La limite à 32 caractères pour le nom de mailuser frappe dès que votre sous-domaine combiné à la partie locale est plus long que prévu. backoffice_dashboard_system_example_com fait trente-neuf caractères et sera rejeté ; bo_dashboard_system_example_com tient en trente et un. Choisissez vos abréviations délibérément plutôt que de laisser l'API vous les imposer en plein déploiement.

Le piège du proxy Cloudflare. L'interface Cloudflare permet d'activer le proxy orange pour n'importe quel enregistrement. Pour les A/AAAA d'une origine web, on le veut presque toujours activé. Pour les enregistrements MX, il est toujours désactivé — Cloudflare ne proxifie pas le mail. Le piège, c'est quand on active le proxying en masse via un script et qu'on inclut accidentellement les enregistrements MX. Cloudflare abandonne silencieusement le flag proxy pour les types non supportés, si bien que tout semble fonctionner, mais on perd des minutes à déboguer un problème inexistant.

Le greylisting sur le premier message entrant. Les systèmes mail mettent parfois en liste grise le premier message d'un expéditeur inconnu — réponse temporaire 4xx, avec demande de réessai quelques minutes plus tard. Gmail réessaie automatiquement. Si votre premier test d'entrée semble échouer, attendez quinze minutes avant de conclure à un dysfonctionnement.

Le plafond de lookups DNS pour SPF. SPF impose une limite stricte de dix lookups DNS pendant l'évaluation (RFC 7208 §4.6.4). Un seul include:spf.mailhost.example compte comme un lookup, même si cet include résout en douzaines d'IPs en interne. On n'atteint le plafond qu'en enchaînant plusieurs expéditeurs — par exemple en ajoutant plus tard include:_spf.resend.com pour un pipeline marketing. Concevez l'enregistrement SPF pour la liste d'expéditeurs à long terme, pas seulement pour le premier.

Champ dkim_privkey vide côté fournisseur mail. Certains fournisseurs exposent un endpoint de création de domaine qui réussit sans générer la clé DKIM, nécessitant un appel séparé « activer DKIM ». Vérifiez que le champ dkim_record dans la réponse de création est non vide avant de continuer. S'il est vide, consultez la documentation du fournisseur pour l'appel secondaire.

Une surveillance naïve du déploiement. Si vous gérez des dizaines de domaines, un enregistrement DKIM défaillant ou une destination de rapport DMARC expirée n'apparaîtra pas dans la surveillance de routine à moins de vérifier activement. Notre routine de contrôle mensuel pour les services auto-hébergés inclut une étape d'audit des enregistrements mail pour exactement cette raison.

Ignorer MTA-STS quand il est disponible. MTA-STS publie une politique qui oblige les expéditeurs à utiliser TLS vers vos hôtes MX et à valider le certificat. Gmail, Microsoft 365 et Yahoo le vérifient ; l'adoption mondiale reste inférieure à un pourcent, donc une politique valide constitue un signal de réputation modeste. La contrepartie est opérationnelle : une politique pointant vers des hôtes MX qui échouent la vérification TLS bloque le courrier entrant légitime. Si votre fournisseur expose MTA-STS, activez-le après que DKIM et DMARC sont stabilisés.

Chemin de rollback

Si la vérification échoue ou si vous décidez que le projet n'a finalement pas besoin de sa propre boîte, le nettoyage est idempotent et prend cinq minutes :

  1. POST /api/v1/address/delete/ avec l'UUID de l'adresse
  2. POST /api/v1/mailuser/delete/ avec l'UUID du mailuser
  3. POST /api/v1/domain/delete/ avec l'UUID du domaine dans le système mail (cela efface également les clés DKIM)
  4. DELETE /zones/<zone>/dns_records/<id> pour chacun des trois enregistrements DNS

L'ordre a son importance, car certains fournisseurs refusent de supprimer le domaine tant qu'il a encore des adresses attachées. L'ordre inversé vous offre aussi un point d'arrêt sensé pour inspecter — si l'étape 1 échoue parce qu'il y a des mails dans la boîte que vous aviez oubliés, le routage DNS n'est pas encore cassé.

Laisser les enregistrements SPF et DMARC sur le sous-domaine après un rollback est sans conséquence. Ils n'authentifient rien, mais ils indiquent aux futurs destinataires que ce sous-domaine n'envoie explicitement aucun mail légitime — ce qui constitue un petit avantage anti-usurpation. Nous les considérons comme activés par défaut une fois créés. Cette logique de « résidu inoffensif » est la même que celle que nous appliquons à la reprise après sinistre pour les services auto-hébergés : le modèle de nettoyage-après compte autant que le modèle d'installation.

Pour conclure

Une boîte mail dédiée à un projet n'est pas de l'infrastructure ; c'est une brique opérationnelle qui permet à un agent IA — ou à tout autre processus automatisé — de devenir un participant à part entière dans les workflows basés sur le mail. Le modèle à quatre appels API se transpose facilement entre fournisseurs mail ; les enregistrements DNS se transposent entre fournisseurs DNS. Ce qui mérite d'être bien fait, c'est la frontière entre les deux systèmes : quel enregistrement vit où, à quoi ressemblent les modes d'échec, et comment vérifier de bout en bout sans dépendre du bon vouloir du filtre anti-spam d'un tiers.

Si vous souhaitez de l'aide pour architecturer une stack dédiée à un projet — agent Telegram, boîte mail, gestion documentaire et tout le reste — tva peut vous accompagner.

Autres articles

Articles connexes

Construire un assistant IA dédié à un projet via Telegram

Affiner un agent de style Hermes qui évolue avec votre projet

Construire des compétences d'agent IA pour les workflows métier spécifiques à un domaine