Structured Email Frameworks

In recent years, several vendors have devised some general frameworks for structured, dynamic and interactive email.

Individual approaches are discussed in more detail on their respective subpages.


Overview for Email AMP Email Actionable Messages
Core idea Add machine-readable version of its content to emails Provide special markup for creating a more interactive/dynamic email experience Provide special markup for creating a more interactive/dynamic email experience
Exists since 2013 2018 2017
Sender side Add markup to HTML email body Design email in AMP and add as multipart/alternative Design email in Adaptive Cards markup and embed in HTML email body
Data formats in JSON-LD or Microdata AMP HTML (subset) Adaptive Cards JSON
Client side Extract and process embedded markup Render AMP email or fall back to HTML email Render actionble message or fall back to HTML email
Dynamic email content (retrieved via HTTP when viewing)   JSON lists and dynamic autocompletion Can retrieve/replace complete actionable message
Interaction (Form rendering) Only simple buttons (“ConfirmAction”) yes yes
Interaction (Form data) “ConfirmAction” triggers simple request against a specified HTTP endpoint Customizable JSON data can be sent to a specified HTTP endpoint Customizable JSON data can be sent to a specified HTTP endpoint
Supporting ISPs Gmail, Yahoo, WEB.DE, Zoho Gmail, Yahoo, Microsoft Office 365,
Supporting tools (besides ISP-specific clients) KMail, Nextcloud Mail Outlook  
Related tools KDE Itinerary   Microsoft Teams


While the described approaches are used in practice, they are typically confined within their vendor-specific “stovepipe”. In particular, there’s barely any support by vendor-independent 3rd-party tools, which is unausual in the case of email.

This section elaborates on various aspects which might inhibit a broader adoption of the different approaches.

High entry barriers

Getting started with either of the three described approaches is a complex and tedious task. Particularly with ISPs, there are various prerequisites imposed. This may involve manual registration and review and message sending requirements such as DKIM/SPF, which even differ between approaches and vendor.

Due to the registration procedures, it is difficult to do proper testing, which may have further negative effects on adoption.

Lack of interoperability

Interoperability is limited on the level of prerequisites (as mentioned before), but also in terms of content and its usage. Notably, vendors supporting for Email do partially support different subsets of and use different means of presentation to the user.

One-way communication only

All three approaches are basically designed for services to send emails to end users, which have a limited set of response actions, that initiate synchronous HTTP requests. End users cannot respond asynchronously by email (using the curresponding paradigm) and especially cannot send emails using one of the frameworks to others.

Essentially, this contradicts the otherwise decentralized nature of email technology.

Disjoint concepts

While AMP Email (AMP) and Actionable Messages (AM) are quite similar to each other, for Email (EM) is roughly orthogonal to both approaches. While AMP/AM allow for more interaction and dynamic features, they lack possibilities to specify the semantic meaning of email content in a way EM allows.

This situation of related and overlapping but technically different approaches - sometimes even provided by the same vendor - may be confusing for potential users.

Table of contents