Un calendrier de warmup IP sur 6 semaines pour expéditeurs auto-hébergés

Un IP sans historique d'envoi a la même tête, vu d'un fournisseur de messagerie, qu'un IP qui vient d'être repris. Aucun signal de légitimité — pas encore. Envoyer 50 000 messages dès le jour un depuis un IP neuf est indiscernable d'un spammeur qui loue un bloc d'IP vierge pour expédier avant que les systèmes de réputation ne rattrapent.

Aussi, Gmail, Outlook, Yahoo, Apple iCloud Mail et les fournisseurs régionaux font tous la même chose au premier contact : ils acceptent un petit volume initial, regardent comment les destinataires réagissent (ouverture / clic / marquage spam / suppression sans lecture), et ne débloquent les volumes plus importants qu'après quelques jours d'engagement propre. Ces « quelques jours » constituent la fenêtre de warmup. Sautez-la et vous n'êtes pas bloqué — vous êtes throttlé et envoyé en dossier spam pendant des semaines, dont il est plus difficile de remonter que d'un rejet net.

Deux formes de rampe sont largement utilisées :

• Linéaire — même incrément fixe chaque jour. 50 → 100 → 150 → 200 → 250 … Prévisible, lent, prudent.
• Exponentielle — multiplicative. 50 → 100 → 200 → 400 → 800 … Atteint le volume cible plus vite, mais est plus agressive en fin de course.

Le moteur de warmup intégré de AcelleMail (modèle : app/Model/WarmupStrategy.php) supporte les deux via les constantes GROWTH_STRATEGY_LINEAR et GROWTH_STRATEGY_EXPONENTIAL, plus deux préréglages de confort : PRESET_BALANCED (linéaire, incrément modéré) et PRESET_CAUTIOUS (linéaire, incrément plus petit avec fenêtre de rampe plus longue). Pour des domaines d'envoi tout neufs sans réputation historique, cautious est le défaut le plus sûr. Pour une migration d'IP où le domaine From a déjà une réputation sur un autre IP, balanced ou exponentiel sont acceptables.

Les chiffres exacts ci-dessous correspondent à une rampe linéaire prudente. Ils sont volontairement conservateurs ; la discipline compte plus que les valeurs précises. La règle unique qui casse tout warmup : ne doublez jamais le volume de la veille sur le nouvel IP tant que la réputation n'est pas établie. Une fois que les taux hebdomadaires de rebonds + plaintes sont propres pendant une semaine au pic, l'IP est « warm » et le warmup s'arrête.

À la fin de la semaine 1, vous avez prouvé que vous pouviez envoyer et que les destinataires s'engagent. À la fin de la semaine 2, vous êtes à 10 000/jour — un ordre de grandeur au-dessus du jour un. C'est à ce moment que les seuils bulk sender de Gmail et Yahoo commencent à s'appliquer : au-delà de ~5 000 messages/jour vers un même fournisseur de messagerie, l'alignement DMARC, le désabonnement en un clic et les plafonds de plaintes deviennent opposables au lieu de simplement recommandés. S'il vous manque l'une de ces préconditions, la semaine 2 est le moment où cela se voit — non pas comme un blocage, mais comme un glissement silencieux vers le dossier spam.

La parade consiste à poser les trois préconditions avant que le warmup ne démarre :

• DMARC en p=quarantine; pct=100 au minimum, idéalement p=reject, avec les rapports RUA qui circulent.
• Désabonnement en un clic via les en-têtes List-Unsubscribe + List-Unsubscribe-Post (RFC 8058). AcelleMail les émet par défaut.
• Budget de plaintes — Amazon SES impose un plafond dur de 0,1 % de plaintes. Restez sous 0,05 % comme marge de travail.

La commande console app/Console/Commands/WarmupListServers.php est le point d'entrée cron. Elle itère sur chaque serveur d'envoi actif doté d'une stratégie attachée et applique le plafond quotidien du jour de la stratégie avant d'autoriser toute campagne à consommer le serveur. Le plafond vit dans SendingServerWarmupUsage ; le journal d'exécution par jour est SendingServerWarmupLog. La stratégie elle-même supporte trois types de limite via des constantes sur WarmupStrategy :

• LIMIT_TYPE_PER_DAY_CAP — « le budget d'envoi d'aujourd'hui est N, rien de plus »
• LIMIT_TYPE_TARGET_VOLUME — « rampez jusqu'à ce que N/jour soit tenu, puis marquez comme terminé »
• LIMIT_TYPE_STOP_AFTER_DAYS — « rampez pendant N jours, puis arrêtez »

Pour la plupart des opérateurs, la bonne combinaison est GROWTH_STRATEGY_LINEAR + LIMIT_TYPE_TARGET_VOLUME : rampe linéaire jusqu'à atteindre la cible quotidienne, puis désengagement du warmup et fonctionnement normal. La stratégie peut être attachée à n'importe quel serveur d'envoi — SES, Mailgun, SMTP générique, sur mesure — indépendamment du driver sous-jacent.

Si vous faites votre warmup contre Amazon SES (l'appairage recommandé selon /pricing), trois chiffres dans le panneau « Reputation metrics » de la console SES comptent pendant la rampe :

• Taux de rebonds — AWS alerte à 5 %, suspend à 10 %. Vous devez rester largement sous 2 %.
• Taux de plaintes — AWS alerte à 0,1 %, suspend à 0,5 %. Restez sous 0,05 % comme marge de travail.
• Quota d'envoi quotidien — SES l'élargit automatiquement au fil de votre historique d'envoi. S'il cesse de croître, votre rampe de warmup dépasse l'auto-grant.

Chacun est par compte, pas par IP, donc la métrique est une dérivée de l'ensemble de vos envois agrégés. Si le taux de rebonds grimpe en semaine 2, ralentissez — ne forcez pas le passage. Le fournisseur a remarqué quelque chose, et le coût d'enquêter maintenant est bien moindre que le coût de récupérer après une suspension.

Vous pouvez sauter le warmup dans deux situations, et deux seulement :

1. Vous utilisez SES avec des IPs partagés (le défaut — les comptes SES de production partagent un pool d'IPs géré). Le pool est pré-chauffé ; vous héritez de sa réputation. Le warmup n'a pas lieu d'être, sauf si vous passez à des IPs dédiés SES.
2. Votre domaine From existant a déjà de la réputation construite sur un autre IP, et vous migrez vers le nouvel IP. Vous faites quand même un warmup, mais sur un préréglage exponentiel plutôt que linéaire prudent, car la réputation du domaine From se reporte.

Pour tous les autres — nouveaux domaines, IPs dédiés, installations Postal MTA auto-hébergées fraîches — le warmup n'est pas optionnel. Le traitement plus détaillé, avec interprétation jour par jour du dashboard SES, vit dans /guide/email-deliverability §7.