ESP : ce qu'est un prestataire d'envoi d'emails et ce qu'il prend en charge

Un ESP (Email Service Provider) est un prestataire qui envoie des emails pour le compte de ses clients : newsletters, campagnes marketing, messages transactionnels déclenchés par une application. Il exploite les MTA, les adresses IP, les files d'attente et les outils de suivi, et laisse au client la gestion de ses listes, de ses contenus et de ses enregistrements DNS.

Ce qu'un ESP prend en charge#

Derrière une interface web ou une API, un ESP assure un ensemble de fonctions qu'une entreprise aurait du mal à maintenir seule :

• un parc de MTA dimensionné pour des millions de messages par jour, avec gestion des files, des réessais et des limites propres à chaque routeur ;
• des plages d'adresses IP dont la réputation est entretenue en continu, avec surveillance des DNSBL et des feedback loops ;
• la signature DKIM des messages et la publication des enregistrements SPF nécessaires ;
• le traitement des bounces et des plaintes, avec suppression automatique des adresses concernées ;
• le suivi des ouvertures et des clics, via un domaine de suivi et des liens réécrits ;
• les en-têtes List-Unsubscribe et la gestion du désabonnement en un clic exigée par Google et Yahoo depuis 2024.

Les ESP marketing (Brevo, Mailchimp, Salesforce Marketing Cloud, Klaviyo, Adobe Campaign…) se distinguent des ESP transactionnels ou « SMTP relay » (SendGrid, Amazon SES, Mailgun, Postmark, Mailjet…) par leurs outils d'édition et de segmentation, mais l'infrastructure sous-jacente répond aux mêmes contraintes. Certains acteurs couvrent les deux usages.

IP partagées et IP dédiées#

Un ESP affecte chaque client à l'une des deux organisations suivantes.

IP partagées : des centaines ou des milliers de clients émettent depuis une même plage d'adresses. La réputation est celle du groupe : elle bénéficie aux petits expéditeurs qui n'auraient jamais assez de volume pour construire la leur, et elle est protégée par l'ESP, qui surveille et exclut les clients dont le trafic dégrade la plage. En contrepartie, un client irréprochable peut subir les conséquences d'un voisin mal intentionné, et il n'a aucun levier direct sur la réputation de l'IP.

IP dédiées : une ou plusieurs adresses réservées à un seul client. Celui-ci construit sa propre réputation, répond seul de ses erreurs et doit respecter un warm-up à la mise en service. Une IP dédiée n'a de sens qu'à partir d'un volume régulier, souvent estimé à quelques dizaines de milliers de messages par semaine ; en dessous, le trafic est trop faible pour que les routeurs établissent un historique stable.

Dans les deux cas, la réputation de domaine, attachée au domaine signataire DKIM et au domaine visible, reste celle du client. C'est elle qui pèse le plus chez les grands routeurs, et elle n'est pas transférée à l'ESP.

Ce que le client doit publier dans son DNS#

Un ESP demande presque toujours à son client de déléguer une partie de son identité DNS :

; SPF : autoriser les IP de l'ESP pour le domaine d'enveloppe
exemple.fr.               IN TXT  "v=spf1 include:spf.esp.example -all"

; DKIM : clé publique ou délégation par CNAME vers l'ESP
esp1._domainkey.exemple.fr. IN CNAME esp1.dkim.esp.example.

; Return-path personnalisé : les bounces reviennent sur un sous-domaine du client
bounce.exemple.fr.        IN CNAME bounce.esp.example.

; Domaine de suivi des clics et des images
lien.exemple.fr.          IN CNAME track.esp.example.

Le return-path personnalisé permet l'alignement SPF au sens de DMARC : le domaine d'enveloppe (bounce.exemple.fr) appartient au même domaine organisationnel que le From (exemple.fr). Sans lui, SPF passe mais n'est pas aligné, et seule la signature DKIM assure la conformité DMARC. Un domaine de suivi sous le domaine du client évite que les liens pointent vers un domaine générique de l'ESP, partagé avec tous ses clients et parfois listé.

Reconnaître le prestataire derrière un domaine#

Les enregistrements DNS d'un domaine trahissent ses prestataires. Les MX indiquent qui reçoit le courrier, et SenderRadar identifie ce prestataire à partir des noms d'hôtes MX. Les include SPF, les CNAME DKIM et le domaine de retour révèlent qui l'envoie. Un domaine peut ainsi recevoir chez Google Workspace, envoyer ses newsletters via un ESP marketing et ses notifications applicatives via un relais transactionnel, chacun apparaissant dans une partie différente de la configuration.

Ce qu'il faut vérifier#

• Les enregistrements demandés par l'ESP sont publiés et vérifiés dans son interface avant le premier envoi.
• Le nombre de requêtes DNS du SPF reste sous dix après ajout de l'include de l'ESP.
• La signature DKIM utilise le domaine du client (d=exemple.fr), et non celui de l'ESP, pour que DMARC soit aligné.
• Le return-path personnalisé est activé, pour l'alignement SPF et pour que les bounces soient traités.
• L'ESP donne accès aux journaux d'envoi, aux codes de refus par routeur et aux plaintes, pas seulement à des taux agrégés.
• Le contrat précise ce qui se passe en cas d'incident de réputation sur une IP partagée.

Erreurs fréquentes#

• Laisser l'ESP signer avec son propre domaine DKIM : le message passe DKIM mais échoue DMARC pour le domaine du client.
• Multiplier les ESP sans sous-domaines distincts, de sorte qu'un incident chez l'un touche la réputation de tout le domaine.
• Passer en IP dédiée pour un volume trop faible, puis constater des placements en spam faute d'historique.
• Changer d'ESP sans migrer progressivement, en coupant le trafic d'un jour à l'autre vers des IP neuves.
• Oublier de retirer les enregistrements DNS d'un ancien prestataire, qui conserve alors l'autorisation d'envoyer au nom du domaine.