Un client m'envoie sa checklist avant sa première grosse campagne. Ligne 3 : « réchauffer l'adresse IP sur six semaines ». Il envoie depuis Brevo, offre standard. Il n'a pas d'adresse IP. Il en partage une avec des milliers d'autres expéditeurs, et cette IP est chaude depuis des années.
Le conseil n'est pas faux. Il ne le concerne pas. Et c'est le cas de la quasi-totalité des PME que j'accompagne : Brevo, Mailchimp, Klaviyo, Sendinblue devenu Brevo, tout le monde démarre sur un pool d'adresses mutualisées, et presque personne ne le sait. Résultat, on passe des semaines à s'inquiéter d'un levier qu'on ne tient pas, pendant que les vrais leviers restent en friche.
Sur un pool mutualisé, la réputation de l'IP ne vous appartient pas. Celle de votre domaine, oui, entièrement. Tout l'effort utile est de ce côté-là.
Vous n'avez pas d'IP, et c'est presque toujours une bonne nouvelle
Une IP mutualisée, c'est une adresse d'expédition partagée entre plusieurs clients du même prestataire d'envoi. Elle est déjà chauffée, elle encaisse du volume tous les jours, et elle n'attend rien de vous. À l'inverse, une IP dédiée démarre à zéro : aucun historique, donc aucune confiance, et il faut plusieurs semaines d'envois réguliers pour la rendre crédible.
Brevo publie ses propres seuils dans sa documentation sur la différence entre IP partagée et IP dédiée : le passage en dédié se justifie à partir de trois campagnes par semaine vers 3 000 contacts ou plus, ou au-delà de 100 000 envois mensuels. En dessous, une IP froide fait moins bien que le pool. Je le dis franchement à chaque fois qu'on me pose la question : pour une entreprise qui envoie une newsletter par mois à 4 000 adresses, l'IP dédiée est un problème qu'on achète.
Le revers existe, il faut être honnête. Google écrit noir sur blanc dans ses consignes aux expéditeurs que l'activité de n'importe quel expéditeur d'une IP partagée affecte la réputation de tous les autres. C'est vrai. Ce n'est simplement pas actionnable de votre côté, et votre prestataire, lui, surveille : Brevo attend de ses comptes en mutualisé un taux de plainte sous 0,2 %, un taux de hardbounce, c'est-à-dire d'adresses qui n'existent plus, sous 2 à 3 % et un taux de désabonnement sous 1 à 2 %, sous peine de vous demander de partir en dédié.
La réputation de domaine, c'est votre part du contrat
Voici le passage des consignes Google que je montre systématiquement en rendez-vous, parce qu'il règle le débat en deux lignes : les quotas liés à DKIM et SPF, les deux mécanismes qui authentifient vos envois, sont propres à votre domaine, et si vous atteignez la limite, les autres domaines qui envoient depuis la même IP ne sont pas forcément touchés. Le quota d'IP, lui, est partagé par tout le monde.
Autrement dit, deux compteurs tournent en parallèle. L'un est collectif et hors de votre portée. L'autre est nominatif, il porte votre nom de domaine, et il vous suit partout, y compris si vous changez de prestataire dans deux ans. Yahoo le formule encore plus nettement dans ses exigences et recommandations aux expéditeurs : bien appliquées, ces règles donnent à un expéditeur une réputation constante pour son domaine, quelle que soit l'IP depuis laquelle le courrier part.
C'est toute la thèse de cet article. Vous ne louez pas une réputation, vous en construisez une, et elle est attachée à un nom, pas à une adresse.
L'authentification, la seule pièce entièrement entre vos mains
Trois enregistrements dans la zone DNS de votre nom de domaine, là où se règlent ses paramètres techniques, et le sujet est bouclé pour des années. SPF déclare qui a le droit d'envoyer en votre nom. DKIM signe cryptographiquement vos messages. DMARC dit aux serveurs qui reçoivent quoi faire quand l'un des deux échoue, et vous renvoie des rapports.
Les seuils ne sont plus négociables depuis 2024. Google impose à tout expéditeur SPF ou DKIM, un enregistrement PTR valide, c'est-à-dire une résolution inverse propre de l'adresse d'envoi, une connexion chiffrée en TLS et un taux de plainte sous 0,30 %. Au-delà de 5 000 messages par jour vers des comptes Gmail : SPF et DKIM et DMARC, avec alignement du domaine visible dans le champ « De » sur celui de SPF ou de DKIM, plus le désabonnement en un clic. Yahoo applique les mêmes seuils et accepte l'alignement souple. Microsoft a rejoint le mouvement en mai 2025 avec ses exigences pour les gros expéditeurs vers Outlook, au-delà de 5 000 messages quotidiens vers les boîtes grand public.
Le piège, celui que je retrouve sur presque tous les comptes que je reprends : par défaut, beaucoup de prestataires signent vos messages avec leur domaine, pas le vôtre. Techniquement, tout passe. DMARC, lui, échoue à s'aligner, parce que le nom que voit le destinataire n'est pas celui qui a signé. Le correctif tient en trois enregistrements CNAME à poser chez votre hébergeur DNS, ceux que votre prestataire vous donne au moment de « vérifier le domaine ». C'est cinq minutes de travail, et c'est la différence entre être authentifié et croire l'être.
Un parti-pris, en revanche : ne démarrez pas en p=reject. Publiez p=none avec une adresse de rapports, lisez ce qui remonte pendant trois à quatre semaines, découvrez au passage les cinq outils qui envoient en votre nom sans que personne s'en souvienne, puis durcissez. J'ai détaillé ce chemin dans mon article sur la délivrabilité, DMARC, BIMI et le réchauffement d'IP, qui traite le sujet côté IP dédiée.
Ce qu'on vous conseille, et ce qui s'applique vraiment
| Le conseil qu'on lit partout | Pourquoi il ne tient pas sur un pool mutualisé | Ce qui compte à la place |
|---|---|---|
| Réchauffer son IP sur six semaines | L'IP est déjà chaude, et elle n'est pas la vôtre | Monter en charge sur le domaine expéditeur |
| Passer en IP dédiée pour mieux délivrer | Sous 100 000 envois par mois, une IP froide fait pire que le pool | Rester mutualisé et travailler la liste |
| Surveiller la réputation de son IP | Vous ne pilotez pas les autres expéditeurs du pool | Surveiller la réputation du domaine dans Postmaster Tools |
| Publier un DMARC en p=reject tout de suite | Le risque de blocage est immédiat, le bénéfice différé | p=none avec rapports, puis quarantine, puis reject |
| Envoyer depuis le domaine principal | Un incident sur une campagne contamine les mails de facturation | Un sous-domaine d'envoi dédié au marketing |
| Piloter la délivrabilité au taux d'ouverture | Google ne mesure pas l'ouverture et ne se fie pas aux chiffres tiers | Taux de plainte, hardbounces, désabonnements |
Le sous-domaine d'envoi, la décision que je prends au démarrage
Concrètement : vos campagnes partent de news.votredomaine.fr ou mail.votredomaine.fr, pas de votredomaine.fr. Yahoo recommande explicitement de séparer les types de courrier par IP ou par domaine de signature DKIM, et de ne pas mélanger le marketing avec les messages de service, parce que chaque domaine de signature porte sa propre réputation.
L'intérêt est facile à voir le jour où ça tourne mal. Une campagne qui prend trop de plaintes dégrade le sous-domaine. Vos devis, vos factures et vos mots de passe oubliés continuent de partir du domaine principal, intact. Sans cette séparation, une mauvaise semaine de newsletter peut faire tomber en spam un mail de confirmation de commande, et là on ne parle plus de marketing, on parle d'exploitation.
La nuance honnête : un sous-domaine neuf n'a aucun historique. Le créer la veille d'un envoi à 40 000 adresses est une mauvaise idée. La bonne date pour le poser, c'était avant votre première campagne. La deuxième meilleure, c'est aujourd'hui, tant que votre base est encore petite.
Monter en charge sans IP à chauffer
Ce qu'on appelle « réchauffement » garde tout son sens, simplement il s'applique au domaine et non à l'adresse. Google est très clair sur la marche à suivre : envoyer à un rythme constant, éviter les à-coups, commencer par un volume faible vers des destinataires engagés, ne pas doubler brutalement un volume sans historique, et surveiller les réponses des serveurs de réception, le protocole SMTP renvoyant un code à chaque message, pour ralentir dès que les rejets montent.
En pratique, je découpe la première montée en trois ou quatre envois sur trois semaines. Le premier part aux contacts qui ont ouvert quelque chose dans les quatre-vingt-dix derniers jours, en général vingt à trente pour cent de la base. Ce sont eux qui produisent le signal positif dont vous avez besoin. On élargit ensuite, par paliers, en gardant un œil sur les plaintes. Le même principe vaut pour les scénarios automatisés : je préfère lancer une séquence d'automation sur un segment engagé avant de l'ouvrir à toute la base.
La pire première campagne reste toujours la même : celle qui part d'un coup à toute la base, depuis un domaine que les serveurs de réception n'ont jamais vu, avec un fichier constitué depuis cinq ans. Ce n'est pas la délivrabilité qui est en cause à ce moment-là, c'est la méthode.
L'erreur la plus coûteuse
Acheter une IP dédiée pour régler un problème de liste. Je l'ai vu plusieurs fois : les résultats se dégradent, quelqu'un suggère de « prendre une IP à soi », on paie l'option, on chauffe pendant six semaines, et rien ne s'améliore. Normal. La cause était une base achetée, un fichier jamais nettoyé ou une promesse d'inscription qui ne correspondait pas au contenu envoyé. Une IP dédiée ne corrige pas ça. Elle isole juste le problème pour qu'il soit bien à vous, sans plus personne pour l'amortir.
Ma règle de cadrage : interdiction de prononcer le mot « IP dédiée » tant qu'on n'a pas regardé l'origine des adresses, la date du dernier nettoyage et le taux de plainte réel.
Les trois chiffres que je regarde, et celui que j'ignore
Le taux de plainte d'abord. Google demande de le tenir sous 0,10 % et de ne jamais atteindre 0,30 %, Yahoo fixe la même limite haute, et votre prestataire attend souvent mieux encore sur un pool partagé. C'est le seul indicateur qui peut vous faire tomber en spam sur une seule campagne. Ensuite les hardbounces, qui trahissent une liste vieillie (le softbounce, lui, est temporaire et ne se traite pas de la même façon), et le taux de désabonnement, qui trahit une promesse d'inscription mal tenue.
Celui que j'ignore, et c'est un vrai changement d'habitude pour beaucoup d'équipes : le taux d'ouverture. Google écrit explicitement qu'il ne le mesure pas, qu'il ne peut pas vérifier les chiffres publiés par des tiers, et qu'un faible taux d'ouverture n'indique pas nécessairement un problème de placement. Depuis la protection de la confidentialité dans Mail chez Apple, une bonne partie des ouvertures remontées sont de toute façon des préchargements. Continuer à présenter un rapport de délivrabilité fondé sur l'ouverture, c'est mesurer autre chose que ce qu'on croit mesurer.
Les bons outils sont gratuits. Postmaster Tools de Google fonctionne parfaitement sur une IP partagée : Google recommande même de s'en servir pour vérifier la réputation du pool. Côté Yahoo, la boucle de retour sur les plaintes exige une signature DKIM, ce qui donne une raison de plus de signer avec votre domaine. Et je branche systématiquement ces indicateurs sur le reste du reporting, comme je le fais pour le suivi analytics et le pilotage par la donnée.
La checklist DNS, dans l'ordre où je la déroule
- Un seul enregistrement SPF sur le domaine d'envoi, incluant votre prestataire. Deux enregistrements SPF sur un même domaine et l'ensemble échoue.
- Les CNAME DKIM du prestataire posés sur votre domaine ou votre sous-domaine, pour que la signature porte votre nom et non le sien.
- Un enregistrement DMARC sur
_dmarc, enp=noneavec une adresseruaqui reçoit vraiment les rapports. - Le désabonnement en un clic, via les en-têtes décrits par la RFC 8058. La plupart des plateformes le gèrent, encore faut-il vérifier que l'option est active et que le lien visible dans le corps du message fonctionne aussi.
- Un envoi de contrôle vers une adresse Gmail et une adresse Outlook, puis lecture des en-têtes : SPF, DKIM et DMARC doivent afficher « pass », et le domaine signataire doit être le vôtre.
Une demi-journée pour l'ensemble, une seule fois. C'est le meilleur rapport effort/résultat de tout le marketing par email, et c'est aussi ce qui protège vos mails transactionnels, ceux dont dépend directement le chiffre d'affaires sur un site marchand, comme je l'explique dans mon accompagnement e-commerce.
Au creuset : transmuter l'adresse en réputation
Une adresse IP se loue, se partage et se remplace. Elle n'a pas de mémoire de vous. Un nom de domaine, si : il accumule, il se souvient, et il vous suit d'une plateforme à l'autre. C'est la seule matière durable dans toute cette affaire, et c'est précisément celle qu'on néglige en s'inquiétant d'un réchauffement qui ne nous concerne pas.
Alors oubliez l'IP. Posez trois enregistrements DNS proprement, séparez le marketing du reste par un sous-domaine, montez en charge par paliers et nettoyez votre liste avant de la doubler. Le jour où vos volumes justifieront vraiment une IP dédiée, vous arriverez avec un domaine déjà réputé, et la transition se fera sans douleur. C'est exactement l'ordre dans lequel je travaille le sujet dans mon expertise emailing et marketing automation.
Vos emails arrivent-ils vraiment en boîte de réception ?
Je vérifie votre authentification DNS, je lis vos rapports DMARC, je regarde vos vrais taux de plainte et je vous rends une configuration propre plus un plan de montée en charge.