Nos e-mails de confirmation en double opt-in partent dans les spams, donc la moitié de nos inscrits ne confirment jamais
L’e-mail de bienvenue arrive bien mais la confirmation de double opt-in atterrit dans les spams, si bien que beaucoup d’inscrits ne confirment jamais et que la boutique les perd. Cela arrive parce que le Default From au niveau du compte est encore une adresse chez un fournisseur gratuit (un @gmail.com ou un @yahoo.com), qui échoue à l’authentification selon les règles Google et Yahoo de 2024, et parce que la confirmation touche des destinataires tout neufs et froids.
La solution
Dans Klaviyo, ouvrez le menu du compte (en bas à gauche) et allez dans Settings > Account > Contact Information > Organization, puis réglez le Default From / Reply-To sur une adresse d’un domaine que vous possédez. N’utilisez jamais une adresse @gmail.com, @yahoo.com ou d’un autre fournisseur gratuit, car depuis les règles Google et Yahoo de février 2024 un From chez un fournisseur gratuit échoue à l’authentification. Associez-le à un domaine d’envoi à votre marque vérifié (Settings > Domains), pour que la confirmation soit alignée DMARC, et notez que changer le Default From n’affecte que les e-mails créés ensuite : mettez donc aussi à jour le modèle de confirmation existant. Assurez-vous que ce modèle n’est pas trop pauvre en texte : un simple « cliquez pour confirmer » sans contenu réel se lit comme du hameçonnage pour les filtres.
Notre domaine d’envoi à notre marque s’affichait comme actif, puis il est discrètement revenu à klaviyomail.com et les e-mails ont recommencé à partir dans les spams
Un domaine d’envoi à votre marque se vérifie et affiche Active, puis se déconnecte tout seul, et Klaviyo retombe silencieusement sur le domaine partagé klaviyomail.com, si bien que la délivrabilité s’effondre des semaines plus tard sans cause évidente. Le déclencheur habituel est le proxy Cloudflare (nuage orange) sur les enregistrements Klaviyo, ou une dérive DNS comme un point final manquant à la fin d’une valeur CNAME, qui provoque des échecs de revérification périodiques.
La solution
Dans Cloudflare, réglez chaque enregistrement DNS Klaviyo (les sélecteurs CNAME km, le CNAME de tracking et l’enregistrement TXT de vérification) sur DNS only (nuage gris), jamais sur Proxied, et laissez-les ainsi définitivement, car Klaviyo exige que le proxy reste désactivé même après une vérification réussie. Recontrôlez l’hôte et la valeur exacts face à Settings > Domains, en guettant un point final manquant à la fin d’une valeur CNAME, qui pousse certains fournisseurs à y ajouter automatiquement votre domaine racine. Si le routage dynamique (NS) échoue sans cesse à se propager, basculez sur la configuration statique (CNAME) en solution de repli, en notant que Klaviyo recommande officiellement le routage dynamique pour de meilleures performances. Confirmez la propagation avec dnschecker.org ou MXToolbox, puis vérifiez sur un envoi réel que le domaine d= de DKIM est bien votre sous-domaine à votre marque, et pas klaviyomail.com.
Nous avons passé cette liste en simple opt-in pour protéger nos indicateurs d’inscription, et des robots ont bombardé le formulaire, détruisant nos taux de bounce et de plaintes
Les commerçants qui passent une liste en simple opt-in signalent des vagues d’adresses fausses ou mal orthographiées qui inondent leurs formulaires d’inscription et leur flux de panier abandonné, provoquant des hard bounces, des touches de spam traps et des plaintes qui font plonger la réputation de domaine. Les listes Klaviyo sont en double opt-in par défaut, donc le bombardement de liste frappe le plus durement les listes délibérément passées en simple opt-in et les formulaires intégrés ou codés à la main, où la protection anti-robots intégrée de Klaviyo ne s’applique pas complètement.
La solution
Réactivez le double opt-in sur la liste concernée (Lists & segments > la liste > Settings > Consent > Opt-in Process), pour qu’aucune adresse de robot non confirmée ne reçoive de message ; c’est la défense la plus efficace, parce que seuls les abonnés confirmés sont ajoutés. Sachez que la protection native de Klaviyo n’est qu’un CAPTCHA réactif présenté à des IP déjà suspectes : elle n’entre en jeu qu’après le début d’une attaque et ne couvre pas complètement les formulaires intégrés ou codés à la main. Pour une protection proactive, vous devez ajouter Google reCAPTCHA et un champ honeypot au HTML de votre propre formulaire. Pour réparer les dégâts, construisez un segment de profils qui peuvent recevoir du marketing par e-mail, qui ont reçu 3 e-mails ou plus au cours des 180 derniers jours, et qui n’ont aucune ouverture, aucun clic et aucune commande depuis toujours, puis supprimez-les.
Les fausses ouvertures d’Apple gardent des abonnés morts sur notre liste, et notre flux de fin de vie ne se déclenche jamais
Avec environ la moitié des ouvertures qui viennent désormais d’Apple Mail Privacy Protection, les serveurs d’Apple préchargent le pixel de tracking de Klaviyo à la remise et enregistrent une ouverture, que quelqu’un ait lu l’e-mail ou non. Cela casse toute logique bâtie sur les ouvertures : les segments engagés se remplissent de fantômes, les flux de fin de vie qui suppriment sur « aucune ouverture en 90 à 180 jours » ne se déclenchent jamais pour les utilisateurs Apple, et les flux de reconquête partent sur un réengagement fantôme, si bien que des adresses non engagées continuent de recevoir des messages.
La solution
Cessez de définir l’engagement sur les ouvertures. Klaviyo marque chaque ouverture avec une propriété booléenne nommée Apple Privacy Open, mise à True pour les ouvertures générées par MPP : ajoutez donc le filtre « where Apple Privacy Open equals False » à toute condition Opened Email et reconstruisez vos segments engagés, vos déclencheurs de fin de vie et vos flux de reconquête autour des clics et du comportement d’achat réel. Les clics sont bien plus difficiles à simuler pour Apple MPP, puisque MPP précharge les images, pas les liens. Pour des décisions de suppression définitives, fondez-les sur des événements comportementaux côté serveur (viewed-product, added-to-cart, placed-order) qui remontent par la Track API de Klaviyo plutôt que depuis un pixel dans la boîte de réception, car ceux-là sont réellement immunisés contre le préchargement de MPP.
Un testeur de délivrabilité signale les IP Klaviyo partagées comme inscrites sur liste noire, et vous en concluez que vos envois sont cassés
Des expéditeurs lancent GlockApps ou un testeur comparable, voient un taux de spam élevé et le rattachent à des inscriptions sur liste noire des IP d’envoi partagées de Klaviyo, alors que SPF, DKIM et DMARC passent tous et que leur propre domaine est propre. Comme Klaviyo répartit les envois sur un pool partagé, certaines de ces IP portent presque toujours une inscription due à un voisin bruyant, et le même test sur d’autres ESP montre la même chose.
La solution
Regardez de quelle liste noire il s’agit avant de réagir. Les listes mineures comme Hostkarma ou all.s5h.net n’affectent pas le placement en boîte de réception, et vous pouvez le confirmer en cherchant une mention de ces listes dans vos messages de bounce. Les inscriptions sur IP partagée sont un bruit qui se moyenne, puisque les vraies campagnes se répartissent sur de nombreuses IP : ne passez donc pas à une IP dédiée à moins d’envoyer régulièrement bien au-delà de 50 000 à 100 000 messages par mois, car un volume trop faible sur une IP dédiée gagne une moins bonne réputation qu’un pool partagé en bonne santé. C’est la réputation de domaine, pas l’IP, qui pilote le placement chez Gmail : si votre authentification est alignée et votre domaine propre, vous êtes en bonne posture. Obtenez une lecture honnête en sollicitant de vraies boîtes de réception pendant une campagne réelle plutôt qu’à partir d’un instantané de testeur isolé.