Dates d’expiration des emails : Guide de mise en œuvre pour les routeurs

Introduction

Lorsque j’envoie mes lettres d’information ou mes campagnes d’e-mail marketing, j’aimerais spécifier la date après laquelle je considère l’e-mail comme obsolète. De cette façon, cette date sera transférée au client de messagerie de mon destinataire, qui pourra alors décider de supprimer tous les courriels obsolètes.

Contrôle de version et collaboration

Ce guide de mise en œuvre est un projet collaboratif qui évolue grâce à la contribution et au retour d’information de la communauté. La version actuelle est maintenue sur le site web zerocarbon.email, où vous trouverez les dernières mises à jour et modifications.

Les suggestions d’améliorations, de corrections ou d’ajouts à ce guide sont les bienvenues. Les questions et les propositions de changement peuvent être envoyées à contact@zerocarbon.email. Toutes les contributions seront examinées et prises en compte pour être incluses dans les versions futures.

Chaque mise à jour importante du guide est documentée afin de garantir la transparence et de suivre l’évolution des recommandations de mise en œuvre. Les contributeurs sont remerciés dans la documentation du projet.

Versions :

  • v1.0 – 20250502 – version initiale – Jonathan Loriaux

Problème et contexte

Le projet « Email Expiration Date » vise à réduire l’impact environnemental des courriels commerciaux en facilitant la suppression des messages périmés. Actuellement, les clients de messagerie ne disposent pas d’outils intégrés pour gérer efficacement la suppression des courriels envoyés par des annonceurs qui ont fixé une date d’expiration. La mise en œuvre de cette fonctionnalité dans les ESP et les clients de messagerie permettrait aux utilisateurs de disposer d’outils de nettoyage efficaces basés sur les dates d’expiration des courriels.

Pour plus d’informations sur le projet et la norme proposée, veuillez consulter le site du projet « Email Expiration Date » :

Avantages pour les destinataires

L’intégration de cette fonctionnalité permettrait aux destinataires d’e-mails de nettoyer plus facilement leur boîte de réception en supprimant automatiquement les messages expirés qu’ils ne liront probablement pas. En un ou deux clics, ils pourraient supprimer des centaines de messages inutiles, améliorant ainsi l’efficacité de la gestion du courrier électronique et contribuant à la réduction de l’empreinte carbone associée au stockage du courrier électronique (voir la section Ressources).

Avantages pour les expéditeurs

En fixant une date d’expiration pour leurs courriels, les expéditeurs de courriels en masse prennent leurs responsabilités et contribuent à réduire la pollution numérique. Cependant, il est important de noter que la mise en place de dates d’expiration dans les courriels n’est ni le seul ni le plus efficace moyen de réduire l’empreinte écologique des courriels.

Au-delà des dates d’expiration, d’autres pratiques sont nécessaires :

  • Promouvoir des produits et services plus respectueux de l’environnement
  • Réduire globalement les volumes d’envoi de courriels
  • Éco-conception des courriels

Exigences techniques

En-tête Expires :

L’en-tête « Expires : » est une exigence technique fondamentale pour la mise en œuvre des dates d’expiration des courriels. Cet en-tête doit être inclus dans les en-têtes SMTP du courrier électronique et doit respecter le format date-heure RFC 5322 (par exemple, « Expires : Thu, 25 Mar 2025 12:00:00 +0000 »). Les ESP doivent s’assurer que cet en-tête est correctement défini et transmis avec le courrier électronique.

Veuillez vous référer à la RFC pour toutes les instructions concernant l’en-tête Expires : https://www.ietf.org/archive/id/draft-ietf-mailmaint-expires-00.html

Signature DKIM

Bien que cela ne soit pas obligatoire, il est fortement recommandé d’inclure l’en-tête « Expires : » dans votre signature DKIM.

Toutefois, l’absence de l’en-tête « Expires : » ne doit pas vous empêcher de déployer des dates d’expiration dans vos outils. Gardez à l’esprit qu’il s’agit d’une bonne idée du point de vue de la sécurité.

Proposition de mise en œuvre

Ces propositions de mise en œuvre ne doivent pas limiter votre créativité et doivent s’adapter aux processus de création de campagnes d’emailing de votre outil. Ces suggestions sont proposées parce qu’elles semblent les plus évidentes aux auteurs de ce document et/ou parce qu’elles ont déjà été implémentées de cette manière dans d’autres outils.

N’hésitez pas à nous contacter si vous avez exploré d’autres possibilités et souhaitez améliorer ce document.

Interface utilisateur des ESP

Informations générales

Il y a deux façons de présenter la saisie de la date d’expiration :

  1. Offrir la possibilité de saisir une date et une heure absolues (par exemple le 1er mars 2025 à 11:00) : Cette solution est particulièrement adaptée aux campagnes ad hoc, mais ne convient évidemment pas aux messages électroniques envoyés automatiquement.
  2. Proposer une date relative (par exemple 2 mois après la date d’envoi du courriel) : Cette solution convient aussi bien aux campagnes ad hoc qu’aux courriels envoyés automatiquement.

Paramètres globaux

Nous vous suggérons d’offrir à vos utilisateurs la possibilité de définir un délai d’expiration par défaut pour tous les courriels créés dans la plateforme. Cette configuration peut être désactivée par les utilisateurs à tout moment, soit globalement, soit lors de la création d’un e-mail.

Option : Dans les outils d’envoi d’emails plus sophistiqués, il est également possible de définir différents délais d’expiration en fonction du type d’email (newsletter, email promotionnel, email transactionnel, cycle de vie…).

Campagnes ad hoc

Deux options doivent être présentées à l’utilisateur :

  1. Activer ou désactiver les dates d’expiration pour l’e-mail ou la campagne
  2. Si les dates d’expiration sont activées, définissez le délai d’expiration ou la date absolue.

L’option peut être affichée à deux endroits différents :

  1. dans les paramètres de la campagne
  2. Dans le panneau d’envoi final (avec la programmation de la campagne)

Pour promouvoir cette option et favoriser son adoption, nous recommandons de l’implémenter directement dans le panneau d’envoi final.

Automatisation du marketing

Les campagnes d’automatisation du marketing étant envoyées de manière continue (en fonction d’un événement ou de manière cyclique), les dates d’expiration doivent nécessairement être relatives à l’heure d’envoi de l’e-mail. Par conséquent, seule cette option peut être sélectionnée lors de la configuration du message.

Mise en œuvre de l’API

Lors de l’envoi d’un courriel via l’API, vous pouvez définir une date d’expiration à l’aide de l’une de ces méthodes :

  1. Date absolue : spécifiez une date et une heure fixes au format ISO 8601. { "expires_at": "2025-12-31T23:59:59Z" }
  2. Date relative : définir une durée à partir de l’heure d’envoi. { "expires_in": "2months" }

Pour les dates relatives, les formats de durée acceptés sont les suivants

  • “2weeks”
  • “1month”
  • “90days”
  • “2months”
  • “1year”

Relais SMTP

Pour le relais SMTP, l’en-tête « Expires : » doit être inséré directement dans l’e-mail transmis au relais. Le relais veillera à ce qu’il reste intact. C’est donc la date absolue qui doit être transmise.

Cet en-tête suit le format standard RFC 2822 pour les dates et les heures.

À faire et à ne pas faire

  • Permettre aux utilisateurs de définir une durée d’expiration par défaut au niveau du compte
  • Proposer à la fois des dates absolues et des durées relatives pour plus de flexibilité
  • Placer l’option d’expiration bien en vue dans le panneau d’envoi de la campagne finale.
  • Mettre en œuvre des validations pour empêcher les dates d’expiration antérieures à la date d’envoi.
  • Proposer des suggestions de durée d’expiration en fonction du type de contenu (promotions, lettres d’information, etc.)
  • inclure des infobulles explicatives sur l’impact environnemental des courriels expirés
  • offrir un aperçu de l’en-tête Expires dans l’interface avant l’envoi.
  • documenter clairement la fonctionnalité dans les guides d’utilisation et la documentation de l’API.

Défis et considérations

Il est essentiel que cette fonctionnalité fasse l’objet de discussions au sein de la communauté afin d’anticiper et de résoudre les problèmes potentiels. Par exemple, des mesures doivent être prises pour empêcher l’utilisation malveillante des dates d’expiration, telles que les dates fixées avant l’envoi du courrier électronique ou quelques heures seulement après l’envoi. L’utilisateur doit toujours garder le contrôle de la suppression des courriels dans sa boîte de réception.

Priorité

Compte tenu de l’urgence climatique et de l’importance de réduire l’impact environnemental des technologies, nous demandons que cette fonctionnalité soit considérée comme hautement prioritaire. Toute technologie doit s’adapter pour minimiser son impact sur l’environnement.

Utilisation et adoption

Actuellement, seul un petit nombre de courriels de masse ont une date d’expiration. Selon une étude réalisée par Orange en France, en mai 2024, environ 5 % des courriels auront une date d’expiration (source : https://www.linkedin.com/posts/jonathanloriaux_orange-email-expiration-date-activity-7211730790152306689-AscM).

Cette situation est principalement due à la difficulté d’imposer l’évolution d’une norme internet. Bien que les expéditeurs de masse soient très intéressés par le déploiement de dates d’expiration dans leurs courriels, peu de plateformes d’envoi permettent l’ajout d’en-têtes SMTP « Expires : », et aucun grand fournisseur de boîtes aux lettres n’a mis en œuvre la technologie.

Il est donc essentiel que l’ensemble de l’écosystème (expéditeurs de masse, solutions d’envoi de courriels en masse et clients de messagerie) progresse pour faire de ce projet une réalité.

Exemples de mise en œuvre

Vous trouverez ci-dessous différents exemples de mise en œuvre de la date d’expiration dans des ESP, réels ou fictifs.

Brevo (exemple réel)

Lien vers la documentation : https://help.brevo.com/hc/en-us/articles/4413566705298-Create-an-email-campaign#tab-content-301

Sendingly / Numberly (exemple réel)

Lien vers la documentation : https://www.zerocarbon.email/documentation/email-expiration-dates-sendingly-numberly/

Sweego API (exemple réel)

Sweego est une solution de messagerie transactionnelle (email et SMS) qui implémente les dates d’expiration des emails dans son API et son relais SMTP.

Lien vers la documentation : https://learn.sweego.io/docs/headers/expiration_date

Mailchimp (exemple fictif)

A DÉTERMINER

Commentaires supplémentaires

Les dates d’expiration dans les courriels sont principalement destinées aux courriels de masse. A ce stade, il ne semble pas pertinent de permettre à un utilisateur de client de messagerie de fixer une date d’expiration pour les courriels qu’il envoie.

Ressources