Le playbook infrastructure cold email

Accueil › Services › Programmatic Outbound › Deliverability

Voici le pattern qu'on voit chaque semaine. Une équipe achète 120 inboxes sur 40 domains chez un reseller. Warm pendant deux ou trois semaines. Lance les campagnes. Zéro reply, même pas un out-of-office. Panique. Change la copy. Toujours rien. Six semaines plus tard, la deliverability s'effondre complètement. L'infrastructure est jetée et tout recommence.

Neuf fois sur dix, le problème est l'infrastructure, pas la copy. Une « mauvaise » copy envoyée sur une infrastructure correctement authentifiée est délivrée. Une « bonne » copy envoyée sur une infrastructure cassée non. Le framing et l'authentification comptent 10x plus que les spam words.

Le triangle d'authentification : SPF, DKIM, DMARC

Chaque sending domain en cold a besoin de trois enregistrements DNS, configurés en alignement. Dès qu'un seul manque ou est mal configuré, la deliverability s'effondre.

SPF (Sender Policy Framework)

SPF dit aux serveurs mail récepteurs quelles IP sont autorisées à envoyer depuis votre domain. Un enregistrement SPF Google Workspace standard ressemble à v=spf1 include:_spf.google.com ~all. La règle critique : la return address (envelope-from) doit correspondre à la sender address pour que SPF passe — on appelle ça l'alignement SPF. Le forwarding casse l'alignement, c'est pourquoi une « reply-to » différente sur une cold campaign tue souvent la deliverability.

DKIM (DomainKeys Identified Mail)

DKIM est une signature cryptographique — le timbre qui prouve que le message vient bien du domain qui prétend l'avoir envoyé. Google Workspace génère la clé DKIM dans la console admin ; vous la copiez en TXT dans le DNS. Microsoft 365 fonctionne pareil. Vérifiez que ça passe en vous envoyant un email à vous-même sur Gmail et en lançant « Afficher l'original » — SPF, DKIM et DMARC doivent tous afficher PASS.

DMARC (Domain-based Message Authentication)

DMARC est la policy qui dit aux récepteurs quoi faire quand SPF ou DKIM échouent. Les trois policies sont none, quarantine et reject. La best practice pour le cold sending est :

• v=DMARC1; p=reject; pct=100; rua=mailto:dmarc@yourdomain.com; sp=none

p=reject est l'étalon-or une fois SPF et DKIM en pass. Cela force une infrastructure propre — rien de non authentifié ne passe. Ajouter rua= (aggregate report URI) signifie que vous recevez des rapports quotidiens sur qui essaie d'envoyer en se faisant passer pour vous. Sauter rua= est une erreur de débutant classique ; sans, vous volez à l'aveugle.

Warmup de domain : 28 jours, pas deux semaines

Les domains frais ont besoin d'un minimum de 28 jours de warmup avant de lancer de vraies campagnes. Deux semaines ne suffisent pas. Trois semaines est le plancher pour des résultats marginaux. Quatre semaines est là où les taux de reply se stabilisent.

Les outils de warmup — Warmup Inbox, Warmbox, Warmforge, Mailwarm, Folderly, Mailreach, Warmy — simulent des conversations pour construire la réputation du domain. Utilisez-en un qui s'intègre à votre sequencer. Pendant le warmup, les inbox health scores doivent grimper de zéro vers 80-100. Si les scores restent sous 20 après trois semaines sur des domains frais, quelque chose est cassé en amont — généralement le bloc IP du reseller ou une mauvaise config DNS.

Ce que le warmup fait vraiment : il établit que votre domain a un trafic email légitime, à l'apparence humaine. Ce qu'il ne fait pas : compenser une mauvaise copy, des listes non vérifiées ou un registrar de domain sur une blocklist spam.

Placement testing, par provider

Chaque provider email a des seeds de deliverability différents. Le filtre spam de Google n'est pas celui de Microsoft 365. Mimecast, Barracuda et Proofpoint (anti-spam entreprise) classifient chacun différemment. Lancer un placement test vous dit quels providers inboxent et lesquels mettent en quarantaine avant que vous gâchiez une campagne sur une audience silencieuse.

Les outils qu'on utilise :

• mail-tester.com — health score basique, check des spam words, vérification d'auth
• Folderly — placement testing complet plus monitoring continu de deliverability
• GlockApps — inbox placement détaillé sur les providers
• Emailguard / Mailreach / Warmy — monitoring continu de placement
• Inbox Placement (Smartlead) — le quick check le moins cher

Lancez des placement tests sur l'infrastructure fraîche avant de partir live, puis re-testez toutes les deux semaines. La deliverability dérive — un domain qui inboxe en semaine 4 peut être en quarantaine en semaine 8. Détectez-le tôt et rotez avant que les replies meurent.

Le stack multi-ESP, multi-registrar

L'étalon-or 2026 : deux registrars de domain, deux ESP (Google Workspace + Microsoft 365), au minimum. Trois de chaque à vraie échelle. Le raisonnement est simple : un single point of failure tue toute la pipeline. Quand Google deprecate un reseller grey-hat ou que Microsoft serre les quotas, vous rotez sur votre second stack pendant que vous réparez le premier.

À quoi ça ressemble en pratique pour une équipe qui envoie 100K+ emails par mois :

• Batch 1 : 30 domains sur registrar A, Google Workspace, sequencer 1 — envoi pendant deux semaines, puis cool down
• Batch 2 : 30 domains sur registrar B, Microsoft 365, sequencer 2 — envoi pendant que le batch 1 se repose
• Batch 3 : réserve hot-swap — pré-warmée, prête à déployer quand l'un des batch crame

C'est pour ça que les agences qui font tourner 100+ inboxes sans rotation voient une falaise de deliverability toutes les six semaines. Elles cramant un stack à la fois. La rotation distribue le burn et étend la durée de vie de l'infrastructure.

Naming des domains : lettres, .com ou .co, sans exception

Les administrateurs systèmes des cibles entreprise bloquent activement les TLD inhabituels et les domains à l'air suspect. Votre sending domain doit ressembler exactement à un domain d'entreprise normal qu'un sysadmin verrait passer sans tiquer.

• Utiliser : .com, .co et TLD géo-spécifiques (.de, .nl, .fr, .uk) pour les campagnes locales
• Éviter : .xyz, .online, .site, .tech, .info, .biz — tous flaggés par les filtres entreprise
• Éviter : chiffres (company1.com), tirets (get-company.com) — pattern phishing
• Préférer : variantes lettres uniquement (trycompany.com, hqcompany.com, getcompany.com, usecompany.com, joincompany.com)

Votre domain principal ne doit jamais servir au cold sending — le risque réputationnel est trop élevé. Utilisez des domains look-alike achetés sur infrastructure séparée et gardez votre domain principal propre pour la communication client.

Deux inboxes par domain, pas trois

Données de deliverability sur des milliers de setups cold sending : deux inboxes par domain sur Google Workspace performent mieux que trois. Plus d'inboxes par domain n'est pas plus de débit — c'est plus de risque par burn de domain. Quinze domains avec deux inboxes chacun (30 mailboxes) battent dix domains avec trois inboxes chacun (30 mailboxes) en deliverability.

Spam words et hygiène de copy

Les listes de spam words sont surcotées. Le framing et l'infrastructure comptent 10x plus. Cela dit, ne tassez pas délibérément un message avec « free », « guarantee », « urgent », « act now » ou un langage commercial typique. Utilisez le checker spam de Mailmeteor ou le word checker de Folderly pour un sanity check rapide.

Plus important que les mots individuels :

• Garder les cold emails sous 50-60 mots (les data de copy Leadbird montrent constamment que plus court délivre mieux)
• Ne pas inclure HTML, CSS ou tracking pixels au first touch — le plain text gagne
• Pas de liens dans le premier email sauf raison exceptionnelle
• Une CTA, pas trois
• Spintax ou variantes générées par AI sur chaque ligne pour éviter le pattern fingerprinting

Ce qu'on construit pour les clients

Un engagement deliverability typique :

• Audit de la flotte de domain existante, des enregistrements d'auth, des warmup pools et du placement
• Mise en place d'une architecture multi-ESP, multi-registrar dimensionnée au volume
• Configuration de SPF, DKIM, DMARC p=reject avec reporting rua=
• Construction du planning de rotation (batch 1/2/3) et d'une réserve hot-swap
• Intégration d'une cadence de placement testing (toutes les 2 semaines, alertes automatisées)
• Ingestion des métriques de deliverability dans HubSpot aux côtés des data de sequence et de reply
• Formation de votre équipe à faire tourner le système et à diagnostiquer la dérive

Timeline : quatre à six semaines du contrat au premier envoi propre, selon la taille de la flotte de domain et le statut warmup. On lance des campagnes LinkedIn et cold calling pendant le warmup pour ne pas attendre un mois la pipeline.