Pratiques d’infrastructure d’envoi

Cet article complète les articles sur la gestion des adresses IP avec les recommandations d’infrastructure qu’ajoutent les guides des ESP (Postmark, AWS SES, Twilio SendGrid) : le choix entre IP dédiée et IP partagée, la réputation et la chauffe du domaine (distinctes de celles de l’IP), le raccordement des feedback loops et la surveillance.

Adresses IP dédiées ou partagées

Les articles sur l’allocation des IP dimensionnent les parcs d’IP dédiées ; la question préalable est de savoir s’il faut une IP dédiée.

Planchers de volume pour une IP dédiée (référence)

« Quel volume justifie une IP dédiée ? » n’a pas de réponse unique, car les chiffres publiés mesurent des choses différentes. Les planchers et les minimums des éditeurs ci-dessous varient dans un rapport d’environ 5 à 10, mais ils ne se contredisent pas : ils répondent à des questions différentes. C’est la mise en regard de référence pour cette base : les autres articles citent ce tableau plutôt que de répéter un plancher.

Seuils des éditeurs pour une IP dédiée (règles maison). Les ESP publient leurs propres minimums, qui reflètent autant les gammes de produits et l’économie du support de chaque éditeur que les statistiques des récepteurs. Ils se situent au-dessus ou en dessous des deux planchers selon le modèle de l’éditeur, et ne se contredisent pas :

Mise en regard : une IP transactionnelle dédiée peut se justifier dès ~1 000/jour, mais toute IP qui porte un flux général ou de masse a besoin de ~40 000/semaine avant que sa réputation soit statistiquement lisible ; les minimums des éditeurs sont des règles maison commerciales qui s’ajoutent aux deux.

Mises en garde de Postmark : une IP dédiée n’est pas une solution miracle ; pour les expéditeurs sous la barre de volume, elle peut nuire à la délivrabilité, et « une IP dédiée est un moyen pour les ESP de réduire leurs coûts de support » (a dedicated IP is a way for ESPs to lower their support overhead) autant qu’une fonction de livraison. Les IP dédiées exigent aussi un volume régulier et prévisible ; les pics soudains sont signalés comme suspects. Le filtrage moderne accorde de plus en plus de poids à la réputation du domaine par rapport à la réputation de l’IP.

Réputation du domaine et stratégie de sous-domaines

La réputation du domaine est l’opinion que les récepteurs (fournisseurs de messagerie et services antispam) ont de votre domaine. Contrairement à la réputation d’IP, elle est portable : elle suit le domaine d’un système d’envoi et d’un fournisseur à l’autre, si bien qu’un domaine qui a un passé de spam emporte ce passé vers toute nouvelle infrastructure, et une mauvaise réputation de domaine peut pénaliser jusqu’aux emails transactionnels (Postmark).

La réputation de l’IP et celle du domaine sont évaluées séparément, mais interagissent : une mauvaise réputation d’IP peut nuire au domaine qui envoie par cette IP, même quand le dossier du domaine lui-même est bon.

Séparation par sous-domaines

AWS SES et Postmark recommandent tous deux de répartir les flux de messages par sous-domaine, l’équivalent au niveau du domaine de la séparation des IP par domaine de réputation décrite dans Segmentation avancée des adresses IP :

• Envoyez le marketing depuis par exemple marketing.example.com et le transactionnel depuis orders.example.com, plutôt que tout depuis example.com (AWS SES).
• Les sous-domaines développent des réputations indépendantes (par exemple notify.example.com et newsletter.example.com) : un incident marketing (adresse piège touchée, déclenchement d’un filtre de contenu) ne fait pas tomber la livraison transactionnelle. Ils ne s’influencent qu’indirectement (Postmark).
• Surveillez les domaines sosies (par exemple company.com et company-mail.com) : leur réputation et les abus qui y sont liés peuvent influer sur la façon dont les messages de votre marque sont jugés (SendGrid).

Les quatre domaines de chaque message (Postmark)

1. Domaine de signature DKIM (d=) : signez avec votre propre domaine, pas avec un domaine par défaut de l’éditeur, pour que la réputation vous revienne.
2. Domaine du Return-Path : utilisez un Return-Path personnalisé (CNAME) correspondant à votre domaine From ou aligné sur lui ; indispensable à l’alignement SPF dans le cadre de DMARC.
3. Domaine de l’adresse From ou de réponse : il doit identifier clairement la marque ; publiez-y une politique DMARC.
4. Domaines des URL dans le contenu : les liens tiers ne nuisent à la livraison que lorsque les domaines liés ont été vus en train d’agir de façon trompeuse ou malveillante ; mieux vaut malgré tout ne lier que des sites de confiance que vous contrôlez (SendGrid).

Hygiène de l’adresse From (AWS SES)

• Certains fournisseurs d’accès rattachent une réputation à l’adresse From elle-même ; c’est aussi la première impression des destinataires.
• N’envoyez jamais d’emails de masse depuis une adresse de fournisseur d’accès (par exemple sender@hotmail.com) : de gros volumes depuis une adresse de messagerie grand public sont traités avec méfiance ; envoyez depuis un domaine qui vous appartient.
• Évitez les adresses no-reply@ en From ou en Reply-To : elles signalent que vous ne voulez pas de retour des destinataires, alors que les réponses sont un signal d’engagement positif.
• Tenez à jour l’enregistrement WHOIS du domaine : un enregistrement honnête et actuel est un signe de légitimité.

Chauffe de domaine

Les nouveaux domaines et sous-domaines ont besoin d’une chauffe tout comme les nouvelles IP (voir Recommandations pour la chauffe d’IP) ; c’est le domaine qui accumule l’historique le plus durable. Le calendrier de Postmark (les volumes s’entendent par fournisseur de réception, par exemple par Gmail/Yahoo/Microsoft) :

Rythme de progression : doubler à peu près chaque jour au début ; à des volumes importants, ralentir à des hausses quotidiennes de 20 à 50 % (30 à 50 %/jour pendant les semaines 2 et 3, puis 20 à 30 %/jour). Comptez 3 à 6 semaines pour une réputation établie et une livraison fiable à plein volume ; aucun calendrier unique ne convient aux seuils de tous les fournisseurs.

Paliers d’engagement pendant la chauffe : commencer par les meilleures données et élargir (comparez avec la règle des plus engagés d’abord dans Recommandations pour la chauffe d’IP) :

Règle cardinale : n’augmentez jamais le volume sans avoir examiné, fournisseur par fournisseur, les indicateurs d’engagement et de rebonds de l’envoi précédent. Si les indicateurs se dégradent, réduisez le volume de 25 à 30 % jusqu’à ce qu’ils redeviennent normaux ; les déclencheurs de mesures correctives précis sont présentés dans Indicateurs et valeurs de référence de la délivrabilité. Mieux vaut prendre une ou deux semaines de plus que de se précipiter et d’abîmer la délivrabilité à long terme.

Feedback loops et raccordement des notifications

Une feedback loop (FBL) est un canal par lequel un fournisseur de messagerie transmet à l’expéditeur les plaintes pour spam des destinataires. Exigences opérationnelles :

• Inscrivez-vous aux FBL des fournisseurs auxquels vous envoyez (seuls certains en proposent). Word to the Wise tient une liste de référence des points d’inscription aux FBL des fournisseurs d’accès (Postmark). Les plateformes d’ESP les raccordent généralement à l’avance et transmettent automatiquement les plaintes (c’est le cas d’AWS SES).
• Les notifications de plainte masquent l’adresse du plaignant ; intégrez des en-têtes X ou des identifiants dans le corps qui permettent de rattacher les plaintes à une adresse et à une campagne (AWS SES).
• La boîte qui reçoit les notifications de rebonds et de plaintes doit accepter les messages de façon fiable et ne doit pas classer ces notifications en spam (AWS SES) ; voir Hygiène de base de données et politiques de mise en sommeil pour savoir quoi faire de ces données.
• Gmail : les données de plaintes arrivent via Postmaster Tools plutôt que via une FBL par message. Étiquetez les campagnes avec des identifiants de feedback loop uniques pour voir les taux de plaintes ventilés par campagne ou par expéditeur et isoler rapidement le contenu problématique (SendGrid).

Outils de surveillance de la réputation

Vérifiez aussi que des enregistrements de DNS inverse (PTR) existent et concordent pour chaque IP d’envoi (une exigence de Google et de Yahoo envers les expéditeurs de gros volumes, selon SendGrid), et validez l’authentification (SPF/DKIM/DMARC) avec des outils de vérification publics.

Listes de blocage (denylists)

• Les fournisseurs et les services antispam inscrivent les IP et les domaines qui présentent beaucoup d’adresses pièges touchées, un volume élevé de plaintes, ou les deux (SendGrid).
• L’impact varie beaucoup : certaines listes influencent fortement les grands fournisseurs ; beaucoup ne sont que du bruit.
• En cas d’inscription sur une grande liste de blocage : arrêtez immédiatement d’envoyer, suivez la procédure de retrait de liste, puis reprenez avec un volume nettement réduit (Postmark).
• Méfiez-vous des listes payantes qui facturent le retrait au lieu d’évaluer le comportement de l’expéditeur (SendGrid).

Cadre de dépannage (Postmark)

Quand le placement ou la livraison baisse, diagnostiquez cinq domaines, dans l’ordre :

1. Authentification : vérifiez SPF, DKIM, l’alignement du Return-Path personnalisé et DMARC avec des outils de validation publics.
2. Contenu : évaluez le message avec un outil de vérification fondé sur SpamAssassin et des tests sur liste de test ; si un changement de modèle a précédé la baisse, annulez les modifications une à une (voir les règles de contenu dans Indicateurs et valeurs de référence de la délivrabilité).
3. Engagement : comparez les taux de rebonds, de plaintes et d’ouverture aux seuils ; placez les rebonds définitifs en liste de suppression ; évitez noreply@.
4. Réputation : vérifiez la réputation du domaine et des IP dans les outils postmaster et les recherches sur les listes de blocage ci-dessus.
5. Infrastructure : confirmez le rDNS/PTR, les inscriptions aux FBL, la santé du pool d’IP, et que le logiciel d’envoi signe correctement avec DKIM.

Il n’y a pas de solution miracle : la délivrabilité est une surveillance continue de ces cinq domaines, ancrée dans des listes propres et un engagement fort.

Voir aussi

• Allocation de base des adresses IP et Segmentation avancée des adresses IP : dimensionner et segmenter les parcs d’IP
• Recommandations pour la chauffe d’IP : l’équivalent au niveau de l’IP de la chauffe de domaine
• Indicateurs et valeurs de référence de la délivrabilité : les chiffres à surveiller
• Hygiène de base de données et politiques de mise en sommeil : exploiter les données des FBL et des rebonds