L’e-mail est le premier canal ouvert par la plateforme, et elle le sert de bout en bout. Par défaut, sans prestataire pour la porter, elle gère elle-même sa réputation d’envoi : c’est une contrainte — il faut la construire — et une garantie, puisque aucun message, aucune adresse et aucun contenu ne transite alors par un tiers. Un espace qui ne porte pas de données de santé peut aussi confier la remise à un routeur externe sur son propre compte — Mailjet et Brevo sont intégrés, toute solution de routage exposant une API peut l’être : la route change, le suivi et la désinscription restent Missivia.
Le MTA ne garde rien : la file, les baux et les résultats restent dans le périmètre de l’API. La case « en mémoire » s’éclaire le temps d’une tentative, puis se vide.
Remise intégrée
Les messages sont remis directement aux serveurs de messagerie des destinataires, depuis les adresses IP de la plateforme.
Aucun prestataire d’envoi tiers par défaut : sur la route MTA, le contenu d’un message ne traverse pas une plateforme extérieure.
Chiffrement opportuniste des échanges avec le serveur destinataire, et repli explicite consigné lorsqu’il n’est pas possible.
Pour un espace qui porte des données de santé, TLS est obligatoire vers le serveur destinataire : sans TLS valide, la remise échoue explicitement, sans réessai, plutôt que de partir en clair. Le contact n’en est pas pénalisé — ni rebond, ni suppression.
MTA sans état : il prend un bail sur la file de la plateforme et demande le corps au moment de la tentative. La plateforme le rend à la volée et le signe en DKIM elle-même : aucun corps rendu n’est stocké, et les clés DKIM ne quittent jamais le périmètre.
À cette demande, la plateforme revérifie désinscription, limitation, suppression et inactivité : un message devenu inadmissible depuis sa mise en file n’est pas remis.
Rien ne part depuis le temps d’une requête HTTP : tout passe par la file, avec réessais espacés et différé plutôt qu’échec.
Issue inconnue : un corps transmis sans réponse du serveur destinataire n’est pas réexpédié aussitôt ; le message est représenté après un délai unique — deux heures par défaut — pour éviter un doublon. Un verdict tardif — remis, ou rejet définitif — est pris en compte quand il arrive : il corrige le statut du message et les compteurs, y compris pour un message déjà compté en échec, et la correction est publiée comme un événement.
Les fenêtres d’envoi et les quotas d’un espace sont respectés message par message.
Route de remise au choix
Le MTA Missivia par défaut ; un routeur externe par espace, sur le compte du client — Mailjet et Brevo aujourd’hui, et toute solution de routage qui expose une API. Quelle que soit la route, le suivi et la suppression restent Missivia.
Le choix est une donnée de l’espace, pas un réglage de la plateforme : un espace jamais configuré est remis par le MTA. Les identifiants du prestataire sont chiffrés avec la route et jamais restitués — une empreinte dit lesquels sont stockés.
Une vérification interroge le prestataire en lecture seule et consigne le résultat sur la route ; un prestataire qui refuse les identifiants est une réponse, pas une erreur de serveur.
Le rendu reste le nôtre, avec les règles de consentement évaluées au rendu : nos pixels, nos liens réécrits, notre lien de désinscription et ses en-têtes. Le tracking du prestataire est désactivé à l’envoi, et ses retours de mesure — ouvertures, clics — sont ignorés à l’entrée.
Pour Brevo, chaque écriture de la route exige une attestation, datée et nominative, que le suivi des ouvertures et des clics est désactivé sur le compte du prestataire employé par l’espace. Une route antérieure sans attestation est signalée, à régulariser.
La suppression est synchronisée dans un seul sens : Missivia décide — désinscription, rebond définitif, plainte — et reporte la décision sur la liste de blocage du prestataire. Sa liste n’est jamais importée.
Les retours du prestataire — rebond, plainte, désinscription, adresse invalide — produisent les mêmes effets que ceux du MTA ; l’URL de retour porte un jeton propre à la route, régénérable, stocké haché.
Un espace qui déclare un attribut de santé reste sur le MTA par construction, dans les deux sens : ni bascule vers un prestataire, ni déclaration d’un attribut de santé sur un espace déjà routé — et l’administration n’a pas de passe-droit.
Un prestataire s’intègre derrière une interface interne unique — envoi, retours, synchronisation des suppressions — : ajouter une solution de routage qui expose une API est un adaptateur de plus, sans changement pour les espaces.
Revenir au MTA ne demande aucun changement de DNS : les enregistrements du prestataire s’ajoutent aux nôtres, ils ne les remplacent pas.
Ce qui ne s’applique pas hors du MTA
La montée en charge du domaine expéditeur et la santé des adresses IP : elles pilotent nos IP et notre réputation ; sur une route externe, la réputation est celle du prestataire.
Le domaine de rebond aligné : l’adresse de retour appartient au prestataire, qui reçoit et classe ses propres rebonds.
Notre signature DKIM : le prestataire réécrit le corps et signe avec sa clé ; le domaine expéditeur est donc authentifié chez lui aussi, en plus de chez nous.
Inchangés : quota journalier, fenêtres d’envoi, consentement, liste de suppression, inactifs, rendu, pixels, liens réécrits, lien et en-têtes de désinscription.
Une route externe dont les identifiants sont illisibles fait échouer l’envoi explicitement : aucun repli silencieux sur le MTA, qui enverrait depuis une IP et un domaine que l’espace n’a pas préparés.
Domaines expéditeurs
Un domaine non vérifié n’envoie rien. La vérification est une condition, pas un conseil.
Déclaration d’un domaine, puis publication des enregistrements DNS fournis — SPF, DKIM, DMARC — et vérification avant le premier envoi.
Signature DKIM par domaine, avec des clés conservées chiffrées et jamais restituées.
Un domaine de rebond aligné par domaine expéditeur, pour que l’alignement DMARC soit satisfait.
Un domaine de suivi par espace pour les images, les pages publiques et les liens réécrits — servi sans cookie et sans ressource externe.
Le retrait d’un domaine est vérifié : il ne casse pas les envois en cours.
Ce que vous publiez dans votre zone DNS
Une autorisation d’envoi pour les adresses IP de la plateforme (SPF).
Une clé publique de signature par domaine (DKIM), dont la clé privée reste chiffrée dans le périmètre.
Une politique de traitement des messages non alignés (DMARC), et l’adresse à laquelle en recevoir les rapports.
Un enregistrement pour le domaine de rebond aligné, qui rend l’alignement possible.
Un enregistrement pour le domaine de suivi de l’espace : images, pages publiques et liens réécrits.
Réputation et montée en charge
Une adresse IP neuve n’envoie pas comme une adresse IP établie.
Montée en charge progressive par adresse IP et par domaine expéditeur : des plafonds quotidiens qui croissent avec la réputation.
Quand un plafond est atteint, le message est différé, pas perdu.
Surveillance de la santé par famille de destinataires : les grands fournisseurs de messagerie ne réagissent pas de la même façon.
Pause automatique quand les taux de rejet ou de plainte franchissent les seuils d’un espace : on s’arrête avant d’être bloqué.
Les signaux de réputation collectés auprès des fournisseurs de messagerie sont des agrégats portant sur nos propres adresses IP et domaines — jamais sur une personne.
Retours, plaintes et suppression
Ce qui revient est traité, et ce qui doit s’arrêter s’arrête.
Les rejets définitifs et les plaintes vont directement en liste de suppression : on n’écrit plus à cette adresse.
Les rejets temporaires sont réessayés selon un rythme décroissant, puis abandonnés proprement.
La liste de suppression est portée par des empreintes, survit à l’anonymisation d’une fiche, et n’est jamais purgée.
Une désinscription en un clic depuis la messagerie est prise en compte immédiatement, sans page intermédiaire. Le lien du corps passe par une page de confirmation, pour qu’un robot qui suit les liens d’un message ne désinscrive personne.
La gestion des inactifs se fonde uniquement sur le signal de délivrabilité, exempté : cesser d’écrire à quelqu’un qui n’ouvre plus ne demande pas son consentement à être mesuré.
Ce qui met une adresse en suppression
Un rejet définitif : boîte inexistante, domaine invalide, refus catégorique du serveur destinataire.
Une plainte pour courrier indésirable, remontée par le fournisseur de messagerie.
Une désinscription, qui vaut pour la finalité concernée et, si la personne le demande, pour toutes.
Une demande d’opposition enregistrée par le responsable de traitement.
Une entrée en suppression ne se retire pas d’elle-même : elle survit à l’anonymisation de la fiche.
Signaux et statistiques
Des chiffres qui disent ce qu’ils mesurent, et à qui ils se rapportent.
Envoyés, remis, rejetés — définitifs et temporaires séparés —, plaintes, désinscriptions : les signaux de remise sont indépendants de tout consentement à la mesure.
Les taux d’ouverture et de clic sont rapportés à la population consentante, publiée à côté du résultat.
Ventilation par domaine expéditeur, par parcours, par campagne et par étape.
Exports à la demande ou planifiés, sans donnée personnelle.
Les compteurs servis aux rôles d’exploitation de la plateforme sont masqués sous le seuil d’affichage.
GET /v1/stats/overview?from=2026-09-01&to=2026-09-07
{
"sent": 48210, "delivered": 47655,
"bounced_hard": 212, "bounced_soft": 343,
"complained": 9, "unsubscribed": 127,
"performance": {
"consented_population": 12480,
"opened": 5311, "clicked": 842,
"open_rate": 0.4256, "click_rate": 0.0675
}
}
# Les taux sont calculés sur la population
# consentante — jamais sur les envois.
