Bilan de la délivrabilité 2026 : 9 changements à traiter avant 2027

Neuf changements ont touché les expéditeurs d’e-mails en 2026, et la plupart demandent une modification avant 2027. Google a retiré Postmaster Tools v1 et ses scores de réputation. DMARC a été republié sous le nom de RFC 9989, qui ajoute trois balises et abandonne pct. DKIM2 se profile pour 2027. Gmail juge désormais un domaine et ses sous-domaines ensemble, et Comcast a commencé à faire passer ses boîtes de messagerie sous les filtres de Yahoo.

Matthew Vernhout, d’Email Industries, a passé les neuf en revue lors du webinaire Unspam.email 2026 Deliverability Review and 2027 Outlook, le 8 octobre 2026, avec Michaela Barriga, d’Email Industries, à l’animation. Ce compte rendu reprend chaque changement avec les diapositives de la session, les modifications exactes de l’enregistrement DMARC et les dix questions posées par le public. Pour une liste datée de tous les changements de 2026, y compris ceux que la session n’a pas abordés, consultez notre tour d’horizon des actualités de la délivrabilité.

Appuyez sur lecture pour charger cette vidéo depuis YouTube (Google). Consultez notre politique de cookies.

Les neuf changements en un coup d’œil

Chaque changement ci-dessous a sa propre section, avec la diapositive montrée pendant la session quand il en existe une.

Google Postmaster Tools v1 a disparu, et les scores de réputation avec lui

Google Postmaster Tools v1 ne fonctionne plus : ses tableaux de bord, ses notes de réputation High, Medium, Low et Bad, ses exports et son API sont tous coupés. Spam Resource a rapporté que l’interface était retirée compte par compte à partir du 20 août 2026, et Matthew situe la fin de la coupure vers octobre. Postmaster Tools v2 n’a aucun score de réputation pour les remplacer.

Selon Matthew, qui s’appuie sur ses échanges avec des interlocuteurs chez Google, ces scores n’étaient plus exacts depuis longtemps. Postmaster Tools v1 avait environ 15 ans et avait cessé d’être maintenu bien avant son retrait. C’est pourquoi la v1 et la v2 affichaient des chiffres de plaintes pour spam différents pour le même domaine : la v2 disposait des flux de données complets, si bien que c’était déjà la v2 qui faisait foi.

Trois choses changent pour les expéditeurs :

• Tout ce qui lisait les données v1 doit être reconstruit. Les comptes sont passés en v2 d’eux-mêmes, mais pas les scripts ni les intégrations des prestataires. L’API v2 a une nouvelle structure de données et exige un accès OAuth au compte Postmaster.
• Postmaster Tools v2 rend compte de la conformité, pas de la réputation. Il affiche les taux de réussite du désabonnement en un clic, les échecs d’alignement SPF et DKIM et le spam signalé par les utilisateurs. Notre guide de Postmaster Tools v2 détaille chaque vue.
• Les données ne couvrent que les comptes Gmail personnels. Postmaster Tools mesure le courrier envoyé aux adresses gmail.com et googlemail.com, jamais aux boîtes Google Workspace. Une marque grand public obtient des données riches, tandis qu’un expéditeur B2B qui envoie peu vers des comptes Gmail personnels en obtient souvent trop peu pour une lecture fiable.

Matthew a demandé à tout le monde d’utiliser le bouton de commentaires de Postmaster Tools v2 pour réclamer un indicateur de réputation. Son raisonnement : Google ajoute ce que suffisamment d’expéditeurs demandent.

La blacklist Heatwave de Validity cible les domaines chauffés avec un faux engagement

Heatwave est une blacklist de domaines que Validity a lancée le 3 septembre 2026, et elle vise la prospection à froid envoyée depuis des domaines chauffés avec de l’engagement synthétique. Un outil de warm-up synthétique envoie du courrier entre des comptes qu’il contrôle, puis l’ouvre, y répond et le sort automatiquement du dossier spam, pour qu’un nouveau domaine ait l’air digne de confiance. L’annonce de Validity cite Spamhaus, SURBL, Comcast et Proofpoint parmi les organisations qui utilisent la liste ou l’évaluent. Matthew l’estimait à environ 1,1 million de domaines au lancement, un chiffre qui continue de grandir.

Heatwave note un domaine au lieu de simplement le lister. Matthew a décrit quatre états :

1. Non listé.
2. Pré-warm-up : le domaine est en cours de chauffe et n’a encore rien envoyé d’autre.
3. Warm-up synthétique observé : du trafic de chauffe, et rien d’autre.
4. Passé à la prospection : le domaine a été chauffé de façon synthétique et envoie désormais de la vraie prospection.

Un domaine qui n’a jamais utilisé d’outil de warm-up peut obtenir son délistage via la procédure d’escalade de Heatwave. Lisez d’abord la description associée à l’inscription sur la liste, car elle indique quel comportement a été observé. Un expéditeur qui utilise bel et bien un outil de warm-up devrait demander directement au prestataire si son schéma d’engagement est abusif, car ce sont ces outils que Heatwave vise.

DMARCbis ajoute trois balises : np, psd et t

DMARCbis est la norme DMARC révisée, publiée sous le nom de RFC 9989 en mai 2026, et elle ajoute trois balises à l’enregistrement DMARC : np, psd et t. Matthew l’a décrite comme la version deux de DMARC, même si un enregistrement DMARCbis commence toujours par v=DMARC1.

• np fixe la politique des sous-domaines qui n’existent pas. L’ancienne parade était un enregistrement SPF ou DKIM générique (wildcard) déclarant qu’un nom n’envoie aucun courrier. np=reject demande aux récepteurs de rejeter le courrier de tous vos sous-domaines qui n’ont aucun enregistrement DNS, et c’est là que les usurpateurs vont en premier.
• psd indique où commence votre organisation. DMARC trouvait autrefois le domaine organisationnel d’un domaine grâce à la Public Suffix List, un fichier tenu par des bénévoles qui peine à suivre les nouveaux domaines de premier niveau. La RFC 9989 remplace cette consultation par un parcours de l’arbre DNS, et psd=n sur votre propre domaine racine indique aux récepteurs qu’il est le domaine organisationnel pour lui-même et pour tout ce qui se trouve en dessous. psd=y est destiné aux registres qui exploitent un suffixe public, pas aux marques.
• t=y est un mode test. Un récepteur applique un niveau de moins que la politique publiée, si bien que p=reject; t=y est traité comme quarantine et p=quarantine; t=y comme none. Matthew le recommande pour le passage de none à quarantine, afin que les rapports montrent ce qui se passerait avant que le moindre message soit touché.

Matthew a ajouté un point qui compte plus que n’importe quelle balise : activez les rapports agrégés. Beaucoup d’entreprises qui arrivent chez Email Industries ont publié p=none il y a des années, sans adresse rua. Cet enregistrement satisfait l’exigence de Google et de Yahoo, mais il n’apprend rien au propriétaire du domaine. Les domaines personnels de Matthew, qui n’ont chacun qu’un seul utilisateur, sont régulièrement usurpés. Sur les domaines que nous testons, 48 % seulement publient une politique DMARC et 52 % des domaines n’en ont toujours aucune, d’après le benchmark de délivrabilité d’Unspam.email.

DMARCbis supprime pct, ri, rf et la limite de taille des rapports

La RFC 9989 a supprimé les balises pct, ri et rf, et a fait de la limite de taille ! sur une adresse de rapport une syntaxe obsolète que les générateurs de rapports ignorent. Les quatre peuvent être retirées d’un enregistrement DMARC dès aujourd’hui.

La balise pct est celle qui a semé le plus de confusion. Elle demandait aux récepteurs d’appliquer la politique à un pourcentage du courrier en échec, et Matthew soulignait que personne ne pouvait le calculer : que valent 50 % d’un nombre inconnu ? Certains récepteurs échantillonnaient un message sur deux, et beaucoup traitaient la balise comme du tout ou rien. La valeur la plus courante, pct=100, était de toute façon la valeur par défaut et ne faisait rien.

Un cas dépasse le simple détail. Un enregistrement avec p=reject; pct=25 rejetait un quart du courrier en échec sous l’ancienne norme, et il le rejette entièrement chez un récepteur qui suit la RFC 9989. Google, Yahoo et Microsoft ne s’étaient pas publiquement engagés sur la sémantique de la RFC 9989 en septembre 2026, les deux lectures sont donc en vigueur en même temps. Notre guide de la RFC 9989 donne le détail. Un expéditeur qui a fait monter son niveau d’exigence par paliers avec pct devrait désormais utiliser t=y dans le même but.

La limite de taille est le !10m à la fin d’une adresse comme rua=mailto:drua@example.net!10m, qui demandait des rapports de 10 Mo au plus. Matthew l’a rarement vue utilisée, et les rapports agrégés sont de toute façon légers. La RFC 9989 ne garde cette syntaxe que pour que les anciens enregistrements restent lisibles.

Une mise à jour DMARCbis tient en trois suppressions et deux ajouts

L’enregistrement de la diapositive de Matthew venait d’un vrai client, seul le domaine a été changé. Voici la version héritée :

v=DMARC1; p=reject; pct=100; ri=86400; fo=1; rua=mailto:drua@example.net!10m; ruf=mailto:druf@example.net

Voici le même enregistrement mis à jour pour DMARCbis :

v=DMARC1; p=reject; np=reject; psd=n; fo=1; rua=mailto:drua@example.net; ruf=mailto:druf@example.net

La mise à jour supprime pct=100, ri=86400 et la limite de taille !10m, et ajoute np=reject et psd=n. Elle peut être publiée sans risque dès aujourd’hui. Un récepteur encore sur la RFC 7489 ignore np et psd, car les deux normes demandent aux récepteurs d’ignorer les balises qu’ils ne connaissent pas, et les valeurs supprimées étaient des valeurs par défaut ou sont ignorées.

La question que le public a posée le plus souvent était de savoir quand faire ce changement, et la réponse de Matthew a été : maintenant. Le DMARC Checker d’Unspam.email signale pct, ri et rf dans un enregistrement publié, et le DMARC Record Generator produit un enregistrement avec une politique np.

DKIM2 règle le replay et la casse des listes de diffusion, un chantier pour 2027

DKIM2 est la prochaine version de DKIM, encore un brouillon de l’IETF et pas une RFC, et elle corrige deux problèmes que le DKIM d’origine traîne depuis des années. Matthew pense qu’elle pèsera en 2027.

• DKIM2 empêche le replay. Avec le DKIM actuel, un attaquant peut prendre un message signé, modifier les parties que la signature ne couvre pas et le renvoyer en masse avec un DKIM toujours valide. Les expéditeurs s’en protégeaient en sur-signant les en-têtes (oversigning). DKIM2 enregistre chaque saut d’un message, si bien qu’une copie rejouée vers d’autres destinataires n’est plus validée comme l’original.
• DKIM2 survit aux listes de diffusion. Une liste de discussion qui ajoute un pied de page ou modifie l’objet casse aujourd’hui une signature DKIM. Avec DKIM2, chaque système qui modifie un message enregistre ce qu’il a changé, et le récepteur final peut remonter la chaîne pour confirmer que l’original était intact. Matthew parle de chaîne de traçabilité.

DKIM2 ouvre aussi la voie à des clés plus robustes, y compris des algorithmes post-quantiques. Sur la longueur des clés, Matthew a été direct : les clés de 512 bits ne devraient jamais être utilisées, celles de 1024 bits sont en voie de disparition, et 2048 bits, c’est la taille à demander à votre plateforme. Notre guide sur la longueur des clés DKIM explique le compromis.

Les expéditeurs qui passent par une plateforme d’envoi d’e-mails n’ont presque rien à changer dans le DNS à court terme. Les plateformes feront tourner un signataire DKIM2 à côté du signataire DKIM1 avec votre clé existante, et un CNAME qui fait pointer votre enregistrement DKIM vers le fournisseur lui permet de mettre à jour les clés plus tard sans votre intervention. FastMail est le plus grand fournisseur de messagerie à signer en DKIM2 aujourd’hui et à le vérifier sur le courrier entrant, mais la plupart des expéditeurs ne signent pas encore. Le conseil pratique de Matthew : demandez à votre plateforme d’envoi sa feuille de route DKIM2 lors de votre prochain point ou de votre prochain renouvellement, car les plateformes construisent ce que suffisamment de clients demandent. Notre guide DKIM2 et DMARCbis traite le brouillon en profondeur.

Le programme de Gmail pour les expéditeurs politiques est une vérification, pas un passe-droit

Gmail a ouvert un Verified Sender Program pour les comités politiques américains le 8 septembre 2026, bâti sur Campaign Verify, le service de vérification déjà utilisé pour les SMS et les appels politiques. Il fait suite à un premier programme pilote de Google pour le courrier politique, que peu de campagnes avaient rejoint.

Un comité enregistré auprès de la Federal Election Commission peut s’inscrire dès qu’il vérifie son domaine d’envoi via Campaign Verify, signe avec DKIM, publie SPF, s’enregistre dans Postmaster Tools et maintient son taux de spam sous 0,3 % en moyenne sur 14 jours. Le courrier d’un comité inscrit part tout de même en spam quand un destinataire le signale, bloque l’expéditeur ou le filtre. Matthew a insisté sur ce point : avec ce programme, Google apprend qui est un expéditeur politique, il ne l’exempte pas de ses règles.

Plusieurs clients d’Email Industries se sont inscrits, et Matthew n’a pas encore constaté d’effet mesurable. Rien ne change pour les autres expéditeurs.

L’AI Inbox de Gmail lit votre texte, et un e-mail tout en image n’a rien à résumer

Gmail utilise désormais Gemini pour trier, prioriser et résumer le courrier, et un résumé ne peut décrire que le texte que contient un message. Google a annoncé le Gmail de l’ère Gemini le 8 janvier 2026, et la vue AI Inbox, qui classe ce qui mérite l’attention, reste réservée aux abonnés.

Matthew a fait quatre remarques sur le courrier dans l’AI Inbox :

• Chaque onglet de Gmail fait partie de la boîte de réception. Principale, Promotions, Réseaux sociaux, Notifications et Forums, c’est toujours la boîte de réception, et quelqu’un qui lit Gmail dans Outlook ou Thunderbird ne voit jamais les onglets. Manœuvrer pour passer de Promotions à Principale fonctionne un temps, puis le courrier est reclassé.
• La priorité se déduit de l’engagement. L’AI Inbox décide de ce qui est urgent selon la façon dont chaque personne traite votre courrier, si bien qu’un e-mail marketing qu’un abonné n’ouvre jamais descend dans sa liste.
• Un e-mail tout en image se résume mal. Sans texte réel, le modèle doit lire les images ou deviner. Du texte HTML et des textes alternatifs descriptifs lui donnent de quoi travailler, et il vaut la peine de vérifier si le résumé dit bien ce que vous vouliez dire.
• Les données structurées sont mises en avant. Gmail fait déjà remonter un code d’authentification à deux facteurs en haut d’un message, avec un bouton pour le copier. Un balisage Schema pour une promotion permet aux mêmes systèmes d’afficher l’offre de façon plus visible.

La façon dont les résumés lisent un message, et ce qu’un expéditeur y maîtrise, est traitée dans notre guide des résumés par IA dans la boîte de réception.

Gmail juge désormais vos sous-domaines et votre domaine racine ensemble

Gmail vérifie ses exigences pour les expéditeurs sur un domaine et ses sous-domaines ensemble, et la page de statut de conformité de Postmaster Tools v2 les présente de cette façon. La page contrôle huit exigences : authentification SPF et DKIM, alignement de l’en-tête From, authentification DMARC, chiffrement, taux de spam signalé par les utilisateurs, enregistrements DNS, désabonnement en un clic et respect des désabonnements.

L’avertissement de Matthew : un sous-domaine conforme ne protège plus un domaine racine qui ne l’est pas. Le cas typique, ce sont des e-mails marketing envoyés depuis un sous-domaine avec un désabonnement en un clic qui fonctionne, pendant que le courrier transactionnel part du domaine racine vers des personnes qui se sont déjà désabonnées. Quand ces destinataires se plaignent du courrier transactionnel, c’est tout le domaine qui paie. La même chose se produit quand une deuxième division écrit à sa propre liste et que les deux listes se recoupent. Email Industries le constate, selon les mots de Matthew, « encore et encore ».

La solution est organisationnelle plutôt que technique : une seule liste de suppression, partagée par chaque équipe et chaque plateforme qui envoie sous le domaine. Sur les e-mails que nous testons, seuls 14 % des expéditeurs passent la vérification List-Unsubscribe en un clic, pour la plupart des programmes, c’est donc l’en-tête lui-même qu’il faut corriger en premier. Notre guide de l’en-tête List-Unsubscribe montre les en-têtes qu’attend Gmail.

Le courrier Comcast passe sous les filtres de Yahoo

Comcast migre ses boîtes de messagerie grand public vers Yahoo, si bien que le courrier envoyé aux adresses comcast.net sera de plus en plus filtré selon les règles de Yahoo. La page de migration publiée par Xfinity indique que les adresses restent en @comcast.net, et les enregistrements MX de comcast.net pointent encore vers Comcast pour l’instant. Les domaines grand public d’AT&T, comme att.net, ont déjà suivi le même chemin.

Pour les expéditeurs, la migration joue dans les deux sens :

• Les problèmes rencontrés chez Yahoo vous suivront chez Comcast. Un expéditeur qui arrive mal en boîte de réception chez Yahoo doit s’attendre à la même chose sur comcast.net à mesure que les boîtes migrent.
• Ce qui marche chez Yahoo marchera chez Comcast. Le plafond de 0,3 % de plaintes, les règles d’authentification et les codes de bounce de Yahoo s’appliquent, et la plupart des plateformes traitent déjà ces bounces.
• La transition sera agitée. Matthew s’attend à davantage de bounces, à de nouveaux blocages et à un déplacement de l’origine des plaintes pendant la migration des boîtes.
• Yahoo Sender Hub mérite une inscription. Vérifiez vos domaines via le DNS, puis surveillez le volume livré et les taux de plaintes. Yahoo a dit à Matthew que d’autres données arrivent.

Notre guide pour corriger la délivrabilité chez Yahoo couvre les règles qui s’appliquent désormais à une part croissante du courrier grand public américain. Matthew a aussi mentionné une proposition de norme pour les rapports d’engagement, draft-brotman-aggregate-performance-reporting, qui indiquerait aux expéditeurs combien de messages sont arrivés en boîte de réception et comment les destinataires ont interagi. D’après lui, seul Comcast envoie ces rapports aujourd’hui, et il l’a laissée hors des diapositives parce qu’elle pourrait ne pas survivre à la migration.

Le plan de délivrabilité pour 2027 tient en quatre étapes

Matthew a conclu la session avec un plan en quatre étapes pour 2027, et chaque étape correspond à l’un des changements ci-dessus.

1. Auditez le DNS pour DMARCbis. Retirez les balises supprimées, ajoutez np=reject et confirmez votre alignement. Ensuite, soumettez SPF, DKIM et DMARC à une revue tous les six mois.
2. Passez à l’API Postmaster Tools v2. Reconstruisez tout ce qui lisait les données v1, et récupérez de façon planifiée les taux de réussite du désabonnement et les diagnostics d’authentification.
3. Maintenez les plaintes sous 0,1 %, et jamais au-dessus de 0,3 %. Si les plaintes ou les bounces augmentent, resserrez votre politique de mise en sommeil. Si vous utilisez un service de warm-up automatisé, vérifiez si Heatwave liste vos domaines.
4. Recalibrez vos envois pour Yahoo et Comcast. Traitez les codes de bounce de Yahoo de la même façon partout, et surveillez de près les bounces Comcast pendant la migration des boîtes.

La fenêtre de mise en sommeil de 60 jours sur la diapositive est un point de départ pour un programme qui a déjà des problèmes, pas une règle. La réponse de Matthew sur la politique de mise en sommeil, dans les questions-réponses ci-dessous, donne la fourchette qu’il applique réellement.

Les questions-réponses en direct

Le public a envoyé dix questions pendant la session. Voici les réponses de Matthew, en version condensée.

Quand mettre à jour un enregistrement DMARC pour DMARCbis ?

Mettez-le à jour maintenant. Matthew recommande une réunion de revue DNS tous les six mois pour confirmer que SPF est à jour, que les clés DKIM sont les bonnes et que le niveau d’exigence DMARC convient toujours. Un domaine resté en p=none pendant cinq ans, et dont le travail préparatoire est fait, est prêt pour quarantine. Si votre prochaine revue a lieu en janvier, ajoutez-y DMARCbis.

Gmail filtre-t-il différemment les domaines .edu ?

Non. Matthew ne pense pas que Gmail traite un domaine différemment à cause de son domaine de premier niveau. Gmail juge les performances passées, donc davantage de courrier en spam signifie en général que les destinataires n’en veulent plus ou ne le trouvent plus pertinent. C’est le contenu qui décide de l’onglet : une promotion de la librairie d’un campus, avec des prix et des remises, se lit comme promotionnelle et arrive dans Promotions.

Pourquoi Postmaster Tools signale-t-il des erreurs de désabonnement en un clic alors qu’il est en place ?

L’erreur signifie en général que du courrier parvient encore à quelqu’un qui s’est déjà désabonné. Gmail attend qu’un désabonnement prenne effet sous 48 heures, et les causes habituelles sont plusieurs listes ou plateformes qui ne partagent pas leurs suppressions, ou du courrier transactionnel envoyé via une autre plateforme à des personnes qui se sont désinscrites. Les rapports agrégés DMARC montrent chaque plateforme qui envoie au nom de votre domaine, et c’est ainsi qu’on trouve le flux que personne n’avait recensé. D’après l’expérience de Matthew, il s’agit presque toujours d’une plateforme tierce dont l’équipe ignorait qu’elle envoyait.

Le courrier transactionnel est-il exempté des règles de désabonnement de Gmail ?

Non. Les filtres antispam ne savent pas distinguer le courrier transactionnel du marketing : ils voient un message avec un contenu. Si le courrier transactionnel attire des plaintes ou des tentatives de désabonnement, il contient probablement du contenu promotionnel, ou les destinataires le signalent comme spam parce qu’il n’a pas de lien de désabonnement. Le Canada rend la frontière explicite : le droit canadien connaît les messages commerciaux et non commerciaux, et rien entre les deux, si bien qu’un message transactionnel qui contient une publicité est commercial.

Peut-on envoyer trop d’e-mails transactionnels ?

Oui, quand le destinataire s’est désinscrit du marketing. L’exemple de Michaela était un achat unique qui a produit cinq e-mails, de la confirmation de commande à la demande d’avis. Pour Matthew, une demande d’avis peut compter comme commerciale, car la marque profite de l’avis. Une fois que quelqu’un s’est désabonné, envoyez uniquement du transactionnel strict, comme la notification d’expédition, et abandonnez la vente croisée.

Quelle durée pour une politique de mise en sommeil ?

Tout dépend de votre fréquence d’envoi. Pour un expéditeur quotidien, Matthew suggère environ 30 jours sans engagement, ce qui donne à un abonné 30 occasions de réagir. Pour un expéditeur mensuel, deux ans peuvent être raisonnables. Les visites sur le site, les connexions, l’usage de l’application et un abonnement payant comptent tous comme de l’engagement, et un abonné payant devrait continuer à recevoir du courrier. Soixante jours sont le point de départ agressif qu’il retient quand un programme a des problèmes de délivrabilité, 120 jours conviennent mieux à la plupart des marques, et la fenêtre peut s’élargir de nouveau une fois les problèmes réglés.

Les logos BIMI s’afficheront-ils pour les utilisateurs Comcast ?

Oui. Une fois que la boîte d’un utilisateur Comcast est passée sur l’application web ou mobile de Yahoo, Matthew s’attend à ce que l’affichage BIMI de Yahoo s’applique. Un expéditeur qui a mis BIMI en place devrait commencer à y voir son logo.

Faut-il modifier les enregistrements DKIM ou DMARC d’un domaine Google Workspace en place depuis longtemps ?

Pour DMARC oui, pour DKIM non, du moins pour l’instant. DMARCbis modifie les balises, alors revoyez votre enregistrement et retirez ou ajoutez des balises selon les besoins. Un prestataire DMARC qui gère votre enregistrement devrait se charger de la mise à niveau. Pour DKIM, les fournisseurs signeront en DKIM2 avec votre clé existante, et Matthew ne s’attend pas à des changements DNS tant que DKIM2 ne sera pas une norme formelle. Si votre enregistrement DKIM est un CNAME vers votre fournisseur, celui-ci pourra le mettre à jour plus tard avec peu d’effort de votre côté.

Arriver dans les spams nuit-il à l’engagement ?

Oui. La plupart des gens ouvrent rarement leur dossier spam, si bien que le courrier qui y arrive suscite peu d’engagement, et ce manque d’engagement l’y maintient. Il ne produit pas non plus de plaintes, car un destinataire ne peut pas signaler comme spam un message qui se trouve déjà dans les spams. Un programme qui n’a presque aucune plainte et de mauvais résultats devrait vérifier où arrive son courrier.

La loi canadienne exige-t-elle un lien de désabonnement dans les e-mails transactionnels ?

Selon la loi canadienne antispam (CASL), un message purement transactionnel comme un reçu électronique n’a pas besoin de consentement, mais il doit tout de même comporter les autres éléments, dont un moyen de se désabonner. Ce désabonnement s’applique ensuite aux futurs e-mails commerciaux. Les messages personnels et la correspondance d’affaires courante en sont entièrement exemptés. Matthew n’a vu aucune procédure engagée pour un désabonnement manquant dans un e-mail transactionnel, mais il en a cité deux récentes pour des envois à des personnes désabonnées : un engagement de $500,000 et $200,000 payés par un site d’offres d’emploi. Selon son décompte, $700,000 ont été perçus en six semaines, si bien qu’une liste de suppression qui n’est pas reportée d’un envoi à l’autre représente un vrai risque juridique pour quiconque écrit au Canada.

Testez ces changements avant votre prochaine campagne

Chacun des changements ci-dessus se voit dans les en-têtes et les résultats d’authentification d’un vrai message. Envoyez-en un au test de spam d’Unspam.email avant votre prochaine campagne : il indique les résultats SPF, DKIM et DMARC, les en-têtes List-Unsubscribe et un score de spam en un seul test. Pour un programme qui a besoin d’un accompagnement concret, les consultants en délivrabilité d’Unspam.email travaillent avec les expéditeurs sur les audits et les corrections.

La page des webinaires d’Unspam.email présente cette session et les suivantes. La précédente, avec Matthew Vernhout et Lawrence Heslin, est résumée dans Inbox for the Holidays.

À propos des intervenants

Matthew Vernhout est conseiller e-mail chez Email Industries, à Toronto. Il a présenté la session et répondu aux questions du public.

Michaela Barriga travaille au marketing chez Email Industries et a animé la session.

Le webinaire était organisé par Unspam.email avec Email Industries.