Prospection e-mail : deliverability et garde-fous mailbot

La deliverability : votre vrai produit (et l’e-mail, juste le packaging)

Je vais commencer par une phrase qui fâche — donc, parfaite.

En prospection, votre produit n’est pas votre message. Votre produit, c’est votre capacité à atteindre une boîte de réception.

Parce que si l’e-mail n’est jamais vu :

• vous n’avez pas une “mauvaise conversion”,
• vous avez une absence de distribution,
• et une réputation qui se dégrade silencieusement (le genre de problème qu’on découvre quand il est déjà tard).

Un mailbot outbound, en 2026, c’est un peu comme un callbot : la démo “wahou” n’a aucune valeur si la prod s’effondre quand vous passez de 100 à 100 000 conversations. En e-mail, la prod s’appelle deliverability, et elle a une mémoire d’éléphant.

Les trois piliers : SPF, DKIM, DMARC (aka “montrez patte blanche”)

On peut résumer l’authentification e-mail comme un contrôle d’identité à l’entrée d’un club :

• SPF : “ce serveur a le droit d’envoyer pour ce domaine”¹
• DKIM : “ce message n’a pas été modifié, et il est signé par le domaine”²
• DMARC : “voici la politique si SPF/DKIM échouent, et voici comment me remonter les incidents”³

Oui, c’est technique. Oui, c’est chiant. Oui, c’est exactement ce qui sépare “on envoie” de “on délivre”.

Ce que les inbox providers attendent (et pourquoi vous devriez écouter)

Si vous envoyez en volume, vous jouez sur le terrain de Gmail/Google, Yahoo, Microsoft, etc. Et ces acteurs publient des exigences très concrètes pour les bulk senders (authentification, désabonnement, etc.). Google, par exemple, documente des règles explicites pour les expéditeurs d’e-mails.⁴

Traduction “terrain” : si vous ne cochez pas ces cases, votre mailbot va se faire traiter comme un bot. Ce qui est, au fond, assez cohérent.

Warm-up et throttling : le mailbot qui sait lever le pied

Là où beaucoup d’équipes se plantent : elles pensent “capacité d’envoi” comme une ressource infinie.

En réalité, l’envoi est une relation :

• votre domaine a une réputation,
• votre IP (ou pool) a une réputation,
• et votre comportement d’envoi est observé.

Un mailbot outbound doit embarquer un cerveau “traffic shaping” :

• warm‑up (monter progressivement la cadence),
• throttling (limiter les pics),
• retry policy (réessayer quand c’est safe),
• et pause automatique quand les signaux se dégradent.

Je vous donne une analogie : envoyer des e-mails en masse sans ramp‑up, c’est comme débarquer à la salle en annonçant “aujourd’hui je fais 200 burpees”.

Vous allez faire deux choses :

1. vous blesser,
2. impressionner personne.

Votre mailbot a besoin d’un “coach” qui lui dit : on commence petit, on observe, on augmente.

1

Définir le profil d’envoi

Nouveau domaine ? Nouveau sous-domaine ? Nouvelle IP/pool ? Le warm-up dépend de ce que vous “introduisez” au monde. Documentez-le.

2

Ramping progressif + plafonds

Montez la cadence de façon graduelle, avec un plafond quotidien et horaire. Votre objectif est la stabilité, pas le record.

3

Throttling dynamique

Ajustez selon les signaux : bounces, plaintes, erreurs SMTP, ralentissements provider, engagement. Si ça pique, on ralentit.

4

Pause automatique (circuit breaker)

Définissez des seuils où le système stoppe l’envoi et alerte un humain. Un mailbot “safe” sait s’arrêter.

5

Reprise contrôlée + post-mortem

Reprise = ramping à nouveau. Post-mortem : quel segment, quel contenu, quel domaine a déclenché la dégradation ?

Opt-out : la différence entre “marketing” et “harcèlement”

Je vais faire simple : si se désabonner est compliqué, vous créez de la plainte.

Et la plainte, ce n’est pas un “feedback” : c’est un signal de spam.

Les standards e-mail existent depuis longtemps pour exposer des options de désabonnement (List‑Unsubscribe).⁵ Et il existe un mécanisme de désabonnement one‑click standardisé (souvent appelé “one-click unsubscribe”).⁶

Ce que le mailbot doit garantir :

• lien de désabonnement visible et fonctionnel,
• support du header List‑Unsubscribe (et idéalement List‑Unsubscribe‑Post),
• gestion immédiate des opt‑out (pas “dans 72h”),
• propagation au CRM (sinon vous relancez quand même),
• et aucune négociation automatique (“vous êtes sûr ?”) sur les segments sensibles.

Contenu : l’IA aide, mais les filtres n’ont pas le sens de l’humour

Le contenu joue sur la deliverability, mais il y a une nuance :

• un bon texte ne sauve pas une mauvaise authentification,
• un texte “spammy” peut plomber une réputation correcte.

Le mailbot doit donc être contraint. Pas bridé — contraint.

Patterns qui font mal :

• trop de promesses (“gratuit”, “urgent”, “dernier rappel”) sur des volumes froids,
• des liens raccourcis non maîtrisés,
• des domaines de tracking qui ne matchent pas votre domaine,
• des images lourdes sans texte,
• des variantes générées à l’infini (les filtres adorent les distributions stochastiques… jusqu’au jour où ils détestent).

Architecture : envoyer comme un système, pas comme une boucle for

Si vous voulez faire du outbound “clean”, il vous faut :

• une outbox (intentions d’envoi),
• un scheduler (fenêtres, fuseaux, throttling),
• un policy engine (opt‑out, segments, consentement),
• un renderer (templates + personnalisation),
• un sender (ESP ou SMTP),
• une brique de feedback (bounces, complaints, replies),
• et un contrôle humain quand c’est sensible.

Idempotency : oui, même pour l’envoi

Un mailbot outbound doit éviter :

• l’envoi en doublon (replay, bug, retry),
• les relances contradictoires,
• et les bursts causés par un worker qui repart en vrille.

Idempotency key = campaign_id + contact_id + step_id + template_version.

Et vous stockez sent_at, provider_message_id, status.

Les métriques qui comptent (et celles qui vous mentent)

Un mailbot outbound doit suivre, au minimum :

• bounce rate (hard vs soft),
• complaint rate (signal spam),
• unsubscribe rate (normal… jusqu’à un point),
• reply rate (et surtout : quality replies),
• inbox placement (quand vous pouvez la mesurer),
• et erreurs SMTP par provider.

Google évoque aussi des recommandations sur les taux de spam/erreurs pour les expéditeurs en volume.⁴

Délivrer, c’est aussi gérer ce qui revient (réponses, bounces, et “stop.”)

Le paradoxe de l’outbound : on pense “envoi”, mais la réalité c’est le retour.

Un mailbot outbound mature sait traiter trois retours très différents :

1. les bounces (technique),
2. les réponses (conversation),
3. les signaux d’opt‑out (conformité + réputation).

Et c’est là que beaucoup de systèmes “IA” se mettent à faire n’importe quoi, parce qu’ils confondent tout : un bounce n’est pas une objection, un “stop” n’est pas une demande d’info, et une réponse agressive n’est pas une invitation au débat.

Routage simple :

• bounces → pipeline deliverability (mise à jour CRM + suppression future + dashboards),
• opt‑out (lien + mots-clés) → action immédiate + confirmation courte,
• replies → classification inbound (N1) + escalade si besoin (N2).

Runbook : quand tout part en spam (et que la Slack devient un film d’action)

Le moment arrive toujours : un segment qui se plaint, une campagne qui “tank”, une IP qui se fait refroidir. Le pire réflexe, c’est d’augmenter la pression (“on relance plus fort”). En deliverability, on ralentit pour comprendre.

1

Stopper la source (circuit breaker)

Pause sur la campagne/segment. Gardez une exception pour le transactionnel/support si vous avez compartimenté vos domaines.

2

Vérifier l’authentification (SPF/DKIM/DMARC)

Contrôlez l’alignement, la signature DKIM, les sous-domaines de tracking, et les modifications en route (forwarders).

3

Regarder les signaux (pas les opinions)

Bounces, plaintes, erreurs SMTP par provider, opt‑out, replies négatives.

4

Isoler la variable toxique

Segment vs contenu vs infra vs cadence. Testez petit, pas sur toute la base.

5

Repartir en mode warm-up

Après correction, repartez progressivement, avec validation HITL sur les premières vagues.

Cas d’usage : prospection, creators, assurance (la même discipline)

Prospection commerciale (B2B)

Le mailbot peut :

• qualifier des réponses (reply parsing),
• proposer un next step (rendez-vous),
• relancer si (et seulement si) les signaux sont bons.

Marketing pour creators (faceless TikTok / YouTube)

Si vous gérez un pipeline de sponsors, le mailbot outbound peut :

• répondre aux demandes de partenariat,
• envoyer des briefs standardisés,
• proposer une date,
• escalader juridique sur clauses sensibles.

Ici, la deliverability n’est pas un KPI marketing. C’est une promesse business : si votre sponsor ne reçoit pas le mail, vous perdez de l’argent.

Assurance (relances documents)

Même discipline : cadence, opt‑out quand applicable, et surtout ton. Une relance de pièces sur un sinistre n’est pas une campagne. C’est du service.

Compartimenter : transactionnel, support, prospection (trois mondes, trois réputations)

Un conseil qui paraît “old school”, mais qui évite des drames modernes : séparez vos flux.

Pourquoi ? Parce que :

• le support (inbound/outbound) a besoin de stabilité,
• le transactionnel (OTP, factures, confirmations) ne doit jamais être pénalisé par une campagne,
• la prospection est, par nature, plus risquée (plaintes, opt‑out, segments froids).

La séparation peut être :

• par sous-domaine (notify. vs support. vs sales.),
• par IP pool,
• par clés/quotas si la personnalisation IA est lourde.

Conclusion : “à l’échelle” = discipline, pas punchlines

Un mailbot outbound qui fonctionne n’est pas celui qui écrit le meilleur e-mail.

C’est celui qui :

• s’authentifie proprement (SPF/DKIM/DMARC),
• respecte les standards de désabonnement,
• maîtrise sa cadence (warm‑up + throttling),
• structure son envoi (queue, scheduler, idempotency),
• mesure la santé (bounces, plaintes, inbox placement),
• sait s’arrêter quand ça dérape.

Bref : un système, pas une démo.

Checklist “deliverability-ready”

• SPF / DKIM / DMARC alignés (et testés)
• List‑Unsubscribe + one‑click (et opt‑out immédiat)
• Warm‑up + throttling + circuit breakers
• Outbox + idempotency + état d’envoi
• Monitoring par provider (bounces/complaints/SMTP errors)
• HITL sur campagnes/segments sensibles

FAQ

Questions frequentes

Est-ce que l’IA suffit pour améliorer la deliverability ?+

Non. L’IA aide à mieux cibler et mieux écrire, mais la deliverability dépend surtout de l’authentification, de la réputation, de la cadence et des signaux (plaintes/bounces). Pensez “système”, pas “prompt”.

Faut-il un domaine dédié pour la prospection ?+

Souvent oui, pour compartimenter le risque (réputation) et éviter d’impacter les e-mails transactionnels/support. L’important est la cohérence (alignement DMARC, tracking, liens) et une gouvernance claire.

Pourquoi insister sur l’opt-out one-click ?+

Parce que la friction se transforme en plaintes. Un désabonnement simple est bon pour l’utilisateur… et bon pour votre réputation.

Sources et references

1. [1]IETF — RFC 7208 : Sender Policy Framework (SPF) :
2. [2]IETF — RFC 6376 : DomainKeys Identified Mail (DKIM) Signatures :
3. [3]IETF — RFC 7489 : DMARC :
4. [4]Google — Email sender guidelines (bulk senders) :
5. [5]IETF — RFC 2369 : List-Unsubscribe headers :
6. [6]IETF — RFC 8058 : One-click unsubscribe :