Que se passe-t-il quand un code OTP part de votre infrastructure et atterrit dans le dossier spam d’un utilisateur qui essaie de se connecter ? Il expire avant d’être lu. L’utilisateur relance, votre volume double, le complaint rate grimpe encore. Un OTP ou un reset de mot de passe n’a pas droit à la seconde chance qu’un email marketing peut se permettre : il doit passer du premier coup, en quelques secondes. Une confirmation de paiement obéit à la même logique. Ce guide couvre le setup technique qui protège la délivrabilité (deliverability) de ces envois : IP dédiée, domaine séparé, alignement SPF/DKIM/DMARC et monitoring, sans revenir sur la réputation d’expéditeur en général ni sur la définition de ce qui est transactionnel.
La réponse courte : une IP dédiée à partir d’un volume significatif, un sous-domaine réservé au transactionnel, un alignement DMARC combinant DKIM strict et SPF relaxé, un warm-up mené sur le flux réel plutôt que sur un calendrier fixe. Ajoutez un monitoring quotidien du bounce et du complaint rate. Chaque brique casse si l’une des autres manque. C’est toute la délivrabilité du flux critique qui en pâtit.
Une IP fraîchement listée sur le SBL Spamhaus avec un formulaire de délistage qui annonce 72 heures de traitement, c’est le genre d’incident qui arrête un flux d’authentification en pleine production. La configuration ci-dessous vise justement à ne jamais en arriver là sur un flux qui porte du 2FA.
IP dédiée ou IP partagée pour l’OTP et le reset de mot de passe
En dessous d’un certain volume, une IP mutualisée suffit. Au-delà d’environ 50 000 emails transactionnels par mois, la dédier devient pertinent pour isoler la réputation du flux critique. La raison : une IP mutualisée hérite de la réputation de tous les expéditeurs qui la partagent. Si un autre client du même pool envoie une campagne mal segmentée un vendredi soir, votre email de reset de mot de passe part avec le même IP reputation tier dégradé, même si votre propre hygiène de liste est irréprochable. Postmark applique ce principe en interne : la plateforme réserve des flux de messages séparés au transactionnel pur et refuse le trafic marketing sur ces mêmes streams, précisément pour isoler la réputation.
En dessous de ce seuil, une IP mutualisée gérée par un fournisseur sérieux (Resend, Postmark, SendGrid) reste défendable : elle bénéficie d’un volume agrégé suffisant pour lisser les variations, à condition que le fournisseur applique déjà une segmentation stricte par type de trafic. Le choix entre ces fournisseurs et leurs limites réelles en production a déjà été traité dans ce comparatif après 18 mois en production.
Une IP dédiée mal warmée est pire qu’une IP mutualisée bien gérée, alors que la documentation postmaster n’insiste jamais sur ce point. Passer en dédié sans plan de montée en charge revient à repartir de zéro sur la réputation, avec un volume transactionnel qu’on ne peut pas suspendre le temps de la construire.
Un sous-domaine transactionnel séparé du marketing
Le M3AAWG recommande depuis plusieurs années d’assigner un sous-domaine distinct à chaque usage d’envoi : bulk marketing, prospection un-à-un, transactionnel, relevés périodiques. L’objectif est que chaque segment construise sa propre réputation de domaine, sans que les fluctuations d’un usage n’affectent les autres.
En pratique : notify.votredomaine.com pour les OTP et confirmations, marketing.votredomaine.com ou news.votredomaine.com pour les campagnes. Gmail et Outlook pèsent désormais la réputation de domaine autant, voire plus, que celle de l’IP : un sous-domaine isolé protège le transactionnel même si le domaine marketing prend un coup. Cette distinction entre logique transactionnelle et logique marketing, notamment sur le cas piège des emails de panier abandonné souvent classés à tort comme transactionnels, est détaillée dans cet article dédié.
Aligner SPF, DKIM et DMARC sans casser l’authentification tierce
Pour un envoi transactionnel via un ESP tiers (Postmark, SendGrid, Mailgun), le combo qui évite de casser l’intégration est DKIM strict et SPF relâché. Un SPF forcé en strict casse fréquemment les intégrations tierces légitimes.
SPF et DKIM valident l’authentification technique. DMARC ajoute une vérification supplémentaire : il vérifie que le domaine authentifié par SPF ou par DKIM s’aligne avec le domaine visible dans le champ From. Il existe 2 modes. En alignement strict (aspf=s, adkim=s), le domaine doit correspondre exactement : c’est le réglage DKIM du combo recommandé par le M3AAWG, qui garantit que la signature vient bien du sous-domaine transactionnel. En alignement relâché (aspf=r, adkim=r), une correspondance au niveau du domaine organisationnel suffit : c’est le réglage SPF, qui tolère que l’ESP envoie depuis un domaine organisationnel légèrement différent du Return-Path exact.
Le déploiement de la politique DMARC elle-même se pilote avec le tag pct=, qui fixe le pourcentage de messages non conformes soumis à la disposition choisie. En p=none, le dispositif se contente de collecter des rapports sans bloquer quoi que ce soit. Sur un sous-domaine transactionnel, mieux vaut passer directement à quarantine après une phase d’observation courte plutôt que de laisser tourner ce mode passif trop longtemps : un enregistrement qui ne fait qu’observer n’empêche aucune usurpation d’OTP. Le mode reject, plus radical, reste réservé aux domaines déjà stabilisés.
Les spécifications elles-mêmes ont bougé. Peu de guides encore en ligne le mentionnent. RFC 7489, la base de DMARC depuis 2015, est désormais obsolète. Elle a été remplacée en mai 2026 par 3 documents connus sous le nom de DMARCbis (RFC 9989 pour l’authentification et la politique, RFC 9990 pour le reporting agrégé, RFC 9991 pour le reporting d’échec), qui font passer DMARC du statut informationnel à celui de standard proposé. Les enregistrements existants en v=DMARC1 restent valides. Les outils qui exploitent les rapports agrégés (parsedmarc, entre autres) et lisent le champ policy_evaluated de chaque rapport XML continueront de s’appuyer sur cette même structure.
Warm-up d’un flux qu’on ne pilote pas soi-même
Une campagne marketing se warme sur un calendrier choisi : on décide du volume envoyé chaque jour. Un flux transactionnel ne fonctionne pas comme ça. Le volume dépend des connexions utilisateurs et des paniers validés. Un mot de passe oublié en pleine nuit y contribue tout autant. Un pic de credential stuffing sur votre application peut faire exploser le nombre d’OTP envoyés en quelques minutes, sur une IP encore en cours de warm-up.
2 garde-fous limitent ce risque. Un PTR record (reverse DNS) d’abord : configuré et cohérent avec le nom d’hôte annoncé par le serveur avant le premier envoi, sans quoi une grande partie des MTA de réception rejettent directement la connexion. Et un rate-limiting applicatif en amont de l’envoi, indépendant du fournisseur d’emailing, qui plafonne le nombre d’OTP déclenchables par adresse IP source ou par compte sur une fenêtre glissante.
Comptez 3 à 6 semaines pour qu’une IP transactionnelle atteigne son plein volume auprès des principaux FAI, en démarrant sur les adresses les plus engagées (comptes actifs récents) avant d’élargir. Ce délai laisse peu de marge pour corriger une erreur de configuration avant que le monitoring ne prenne le relais.
Monitoring : bounce, complaint rate, blocklists et FBL
Le seuil de complaint rate à ne pas dépasser diffère selon le contexte. Gmail rend un expéditeur inéligible aux mécanismes d’atténuation dès que le taux de spam signalé dépasse 0,3 %, d’après la documentation Google Workspace publiée en 2024. Le retour à l’éligibilité, lui, exige de rester sous ce seuil pendant 7 jours consécutifs. Pour du transactionnel pur, ce seuil réglementaire est trop permissif : un utilisateur qui reçoit un OTP qu’il n’a pas demandé le signale presque systématiquement comme spam, ce qui pousse la cible réaliste sous 0,02 %.
« Les expéditeurs en masse dont le taux de spam signalé dépasse 0,3 % perdent l’accès aux mécanismes d’atténuation de Gmail. » (documentation Google Workspace Admin, 2024)
Côté Microsoft, le monitoring passe par SNDS (Smart Network Data Services), qui publie une donnée par jour sur les IP enregistrées. S’y ajoute le programme JMRP, le feedback loop (FBL) d’Outlook et Hotmail. Le guide SNDS de Twilio décrit ce complaint rate comme l’indicateur central du tableau de bord ; en pratique, un taux qui dépasse durablement 0,3 % (le même seuil que celui retenu par Gmail) expose à un throttling visible sur les volumes envoyés vers ces domaines. SNDS ne couvre que les boîtes grand public (Outlook.com, Hotmail, Live) : les domaines Microsoft 365 professionnels n’y apparaissent pas.
Sur le bounce, un code SMTP 550 5.1.1 (user unknown) signale une adresse définitivement invalide : elle doit rejoindre la Suppression List et ne plus jamais être resollicitée, y compris pour un envoi transactionnel déclenché par une action utilisateur légitime. Sur un flux OTP ou reset de mot de passe, ce type de rejet dur touche presque toujours une adresse mal saisie à l’inscription plutôt qu’une boîte réellement pleine ou temporairement indisponible : c’est le hard bounce qui pèse le plus lourd sur la réputation d’une IP encore en warm-up, parce qu’il survient tôt dans le cycle de vie du compte.
L’hygiène de liste en amont change la donne pour une infra dédiée au transactionnel. La vérification d’une adresse au moment de l’inscription, avant qu’elle ne déclenche un premier envoi critique sur une IP qui n’a pas de marge d’erreur, évite l’essentiel des rejets 550 5.1.1 sur ce flux. Une IP en cours de warm-up qui encaisse plusieurs hard bounces sur ses premiers jours d’activité met en péril le calendrier entier.
Checklist de mise en production avant le premier envoi critique
Avant de router le premier OTP réel sur l’infrastructure dédiée, vérifiez dans l’ordre :
- PTR record configuré et résolu dans les 2 sens (IP vers hostname et hostname vers IP)
- Sous-domaine transactionnel isolé du domaine marketing, avec ses propres enregistrements SPF et DKIM
- DMARC publié en quarantine minimum, DKIM en alignement strict, SPF en alignement relâché
- Rate-limiting applicatif actif sur les endpoints qui déclenchent un OTP
- Inscription à SNDS et au JMRP pour les domaines Outlook/Hotmail/Live, à Google Postmaster Tools pour Gmail
- Vérification d’adresse à l’inscription en place pour écarter les rejets 550 5.1.1 avant le premier envoi
Questions fréquentes
Une IP dédiée est-elle obligatoire pour du transactionnel critique ?
Non. En dessous d’un volume significatif, une IP mutualisée chez un fournisseur qui segmente déjà strictement son trafic transactionnel reste défendable. La dédier devient utile passé un certain seuil, quand le contrôle de la réputation justifie l’effort de warm-up.
Combien de temps prend le warm-up d’une IP transactionnelle ?
Comptez 3 à 6 semaines pour atteindre le plein volume auprès des principaux FAI. Le calendrier ne se pilote pas comme pour du marketing : le volume suit les actions utilisateur, jamais un envoi planifié à l’avance.
Faut-il passer DMARC directement en p=reject ?
Non. Une phase en quarantine avec un pct= progressif permet d’observer les rapports agrégés avant de bloquer. Un passage direct en reject sans observation préalable reste une cause fréquente de perte de messages légitimes.
Un OTP qui met 200 millisecondes à partir et finit dans un dossier spam n’a servi à rien.
