Email Expiration Dates: Implementation Guide for ESPs

Introduction

When I send my newsletters or email marketing campaigns, I would like to specify the date after which I consider the email to be obsolete. This way, this date will be transferred to my recipient’s email client, which can then decide to delete all obsolete emails.

Version Control and Collaboration

This implementation guide is a collaborative project that evolves through community input and feedback. The current version is maintained on the zerocarbon.email website, where you can find the latest updates and changes.

We welcome suggestions for improvements, corrections, or additions to this guide. Questions and change proposals can be sent to contact@zerocarbon.email. All contributions will be reviewed and considered for inclusion in future versions.

Each significant update to the guide is documented to ensure transparency and track the evolution of the implementation recommendations. Contributors are acknowledged in the project’s documentation.

Versions :

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

Problem and Context

The “Email Expiration Date” project aims to reduce the environmental impact of commercial emails by facilitating the deletion of outdated messages. Currently, email clients lack integrated tools to effectively manage the deletion of emails sent by advertisers who have set an expiration date. Implementing this feature in ESPs and email clients would provide users with effective cleanup tools based on email expiration dates.

For more information about the project and the proposed standard, please refer to:

Recipients Benefits

Integrating this feature would allow email recipients to more easily clean up their inboxes by automatically deleting expired messages they are unlikely to read. With just one or two clicks, they could remove hundreds of unnecessary messages, improving email management efficiency and contributing to the reduction of the carbon footprint associated with email storage (see Ressources section).

Senders Benefits

By setting an expiration date for their emails, mass email senders take responsibility and contribute to reducing digital pollution. However, it is important to note that implementing expiration dates in emails is neither the only nor the most effective way to reduce email’s ecological footprint.

Beyond expiration dates, other practices are necessary:

  • Promote more environmentally responsible products and services
  • Globally reduce email sending volumes
  • Eco-design emails

Technical Requirements

Expires header

The “Expires:” header is a fundamental technical requirement for implementing email expiration dates. This header must be included in the email’s SMTP headers and should follow the RFC 5322 date-time format (e.g., “Expires: Thu, 25 Mar 2025 12:00:00 +0000”). ESPs must ensure this header is properly set and transmitted with the email.

Please refer to the RFC for all instructions regarding the Expires header: https://www.ietf.org/archive/id/draft-ietf-mailmaint-expires-00.html

DKIM Signature

While it’s not mandatory, it is strongly recommended to include the “Expires:” header in your DKIM signature.

However, the absence of the “Expires:” header should not be a blocker for deploying expiration dates in your tools. Keep in mind that it’s a good idea from a security perspective.

Implementation Proposal

These implementation proposals should not restrict your creativity and should adapt to your tool’s email campaign creation processes. These suggestions are proposed because they seem the most obvious to the authors of this document and/or because they have already been implemented this way in other tools.

Please don’t hesitate to contact us if you have explored other possibilities and would like to improve this document.

ESPs user interface

General Information

There are two ways to present the expiration date input:

  1. Offer the ability to enter an absolute date and time (for example March 1st, 2025 at 11:00): This solution is particularly appropriate for ad-hoc campaigns, but obviously won’t be suitable for automatically sent emails.
  2. Offer a relative date (for example 2 months after the email sending date): This solution will be suitable for both ad-hoc campaigns and automatically sent emails.

Global settings

We suggest offering your users the ability to set a default expiration delay for all emails created in the platform. This configuration can be disabled by users at any time, either globally or during email creation.

Option: In more sophisticated email sending tools, it is also possible to define different expiration delays based on email type (newsletter, promotional email, transactional email, lifecycle…).

Ad-hoc campaigns

Two options must be presented to the user:

  1. Enable or disable expiration dates for the email or campaign
  2. If expiration dates are enabled, define the expiration delay or absolute date

The option can be displayed in two different locations:

  1. In the campaign settings
  2. In the final sending panel (with campaign scheduling)

To promote this option and boost its adoption, we recommend implementing it directly in the final sending panel.

Marketing automation

Since marketing automation campaigns are sent on an ongoing basis (executed based on an event or cyclically), expiration dates must necessarily be relative to the email’s sending time. Therefore, only this option can be selected during message configuration.

API implementation

When sending an email via the API, you can set an expiration date using one of these methods:

  1. Absolute date: Specify a fixed date and time in ISO 8601 format { "expires_at": "2025-12-31T23:59:59Z" }
  2. Relative date: Define a duration from the sending time { "expires_in": "2months" }

For relative dates, accepted duration formats include:

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

SMTP Relay

For SMTP relay, the “Expires:” header must be directly inserted into the email passed to the relay. The relay will ensure it remains intact. Therefore, it is the absolute date that must be passed.

This header follows the standard RFC 2822 format for dates and times.

Do’s and Don’ts

  • Allow users to set a default expiration duration at the account level
  • Offer both absolute dates and relative durations for more flexibility
  • Place the expiration option prominently in the final campaign sending panel
  • Implement validations to prevent expiration dates that are earlier than the sending date
  • Provide expiration duration suggestions based on content type (promotions, newsletters, etc.)
  • Include explanatory tooltips about the environmental impact of expired emails
  • Offer a preview of the Expires header in the interface before sending
  • Clearly document the functionality in user guides and API documentation

Challenges and Considerations

It is crucial that this feature be discussed within the community to anticipate and address potential challenges. For example, measures must be taken to prevent the malicious use of expiration dates, such as dates set before the email is sent or just a few hours after sending. The user must always remain in control of deleting emails in their inbox.

Priority

Given the climate emergency and the importance of reducing the environmental impact of technology, we request that this feature be considered a high priority. Every technology must adapt to minimize its environmental impact.

Usage and Adoption

Currently, only a small number of mass emails have an expiration date. According to a study by Orange in France, as of May 2024, about 5% of emails have an expiration date (source: https://www.linkedin.com/posts/jonathanloriaux_orange-email-expiration-date-activity-7211730790152306689-AscM).

This is mainly due to the difficulty of enforcing an evolution of an internet standard. Although mass senders are very interested in deploying expiration dates in their emails, few sending platforms allow the addition of SMTP “Expires:” headers, and no major Mailbox Provider has implemented the technology.

Therefore, it is essential that the entire ecosystem (mass senders, mass email sending solutions, and email clients) advances to make this project a reality.

Implementation examples

Below, you will find different examples of expiration date implementations in ESPs, both real and fictional.

Brevo (real example)

Link to the documentation : https://help.brevo.com/hc/en-us/articles/4413566705298-Create-an-email-campaign#tab-content-301

Sendingly / Numberly (real example)

Link to the documentation : https://www.zerocarbon.email/documentation/email-expiration-dates-sendingly-numberly/

Sweego API (real example)

Sweego is a transactional messaging solution (email and SMS) that implements email expiration dates in its API and SMTP relay

Link to the documentation : https://learn.sweego.io/docs/headers/expiration_date

Mailchimp (fictionnal example)

TBD

Additional Comments

Expiration dates in emails are mainly intended for mass emails. At this stage, it does not seem relevant to allow an email client user to set an expiration date for emails they send.

Ressources