Skip to main content
Une plateforme de listes de diffusion (MailWizz, Listmonk, Mautic…) qui envoie via votre OxiMail a besoin que l’expéditeur d’enveloppe diffère du From visible :
  • From: reste l’adresse lisible que les destinataires voient et à laquelle ils répondent.
  • Return-Path: (le MAIL FROM d’enveloppe) est une boîte technique dédiée qui collecte les notifications de statut de livraison, pour que le traitement des bounces ne fouille jamais le courrier ordinaire d’une personne.
C’est l’arrangement standard de l’envoi en masse : tous les expéditeurs commerciaux fonctionnent ainsi (Amazon SES parle de custom MAIL FROM domain, Postmark de custom Return-Path). Par défaut OxiMail le refuse, à juste titre : un compte authentifié ne peut utiliser que ses propres identités comme MAIL FROM, et une boîte de bounce n’est volontairement pas une identité de l’expéditeur. Les grants de domaine d’enveloppe ouvrent exactement cet arrangement, et rien de plus.
Un grant élargit l’enveloppe seulement. Le header From: garde sa propre porte : il doit toujours être une identité du compte authentifié. Et un grant n’est pas un alias : il n’implique aucune délivrance et ne crée aucune identité. C’est de l’autorisation pure.

​
Comment ça marche

Un grant autorise un compte à utiliser toute local-part d’un domaine comme MAIL FROM. La granularité domaine est délibérée : le traitement des bounces frappe normalement une enveloppe différente par destinataire (VERP, bounce+alice=example.com@bounces.example.org), donc des règles par adresse ne pourraient jamais suivre. Un domaine accordé couvre toutes les variantes VERP. Deux garde-fous s’appliquent à la création du grant, pas découverts plus tard :
  1. Preuve DNS. Le grant n’autorise rien tant que vous n’avez pas publié un enregistrement TXT et vérifié : la même discipline que les domaines déclarés du relais. La preuve est revérifiée périodiquement ; si l’enregistrement disparaît, le grant est suspendu fail-closed en moins d’un intervalle et les envois sous ce domaine sont rejetés. La métrique oximail_envelope_domain_suspended_total compte ces suspensions.
  2. La règle de même organisation. Le domaine accordé doit partager son domaine organisationnel avec une identité du compte. bounces.example.org peut être accordé à sender@example.org ; bounces.other.net non. C’est la règle d’Amazon SES, et c’est ce qui garde SPF aligné sous DMARC par construction : un Return-Path hors organisation casse DMARC en silence chez certains récepteurs des semaines plus tard, alors OxiMail le rend irreprésentable plutôt que de le documenter en avertissement.
Les grants sont provisionnés par l’opérateur (CLI). Un compte ne peut pas s’accorder l’exemption qui le gate.

​
Mise en place

Disons que la plateforme s’authentifie comme sender@example.org et que vous voulez collecter les bounces dans une boîte dédiée.
Pointez le traitement de bounces de la plateforme sur la boîte de bounce@ (IMAP), et réglez son Return-Path sur une adresse du domaine accordé. Terminé : la plateforme envoie comme sender@, les destinataires voient sender@, et chaque DSN atterrit dans bounce@.

​
VERP sans aucun travail serveur supplémentaire

Si la plateforme frappe des enveloppes par destinataire (VERP), faites-lui utiliser un plus-tag de la boîte de bounce : bounce+<abonné>@bounces.example.org. Le grant autorise chaque variante (toute local-part du domaine passe), et le plus-addressing d’OxiMail les délivre toutes nativement dans la boîte de bounce@. Pas de catch-all, pas de configuration serveur. La répartition des rôles est délibérée, et c’est celle de toute l’industrie : le serveur de mail autorise et garde DMARC aligné ; la plateforme de listes frappe les enveloppes et dépouille les bounces. OxiMail ne génère pas d’adresses VERP et ne gère pas la cadence d’envoi : votre plateforme fait déjà les deux, et les règles des grands récepteurs (désabonnement en un clic, plafonds de taux de plainte) sont aussi ses obligations.

​
Quand un envoi est refusé

Un MAIL FROM qui ne correspond à aucune identité et à aucun grant actif est rejeté en fin de DATA :
Consultez le journal du serveur : si un grant pour ce domaine existe mais n’est pas vérifié ou est suspendu, le log le dit explicitement (« one step from done ») au lieu de ressembler à une tentative de forge. Lancez envelope-domain verify et revérifiez votre enregistrement TXT.

​
Retirer un grant

Le retrait est immédiat : les envois sous ce domaine sont rejetés avec le 550 ci-dessus. --yes est requis, comme pour tout verbe destructif.

​
Relation avec les comptes relais

Si vous opérez un smarthost, notez la frontière : un compte relais role="service" a sa propre autorisation d’enveloppe (les domaines déclarés prouvés d’ADR-116) et ne peut pas recevoir de grants de domaine d’enveloppe. Un mécanisme par type de compte. Les grants sont pour les comptes normaux d’un Primary normal, qui envoient le courrier de listes de leur propre organisation.