The format behind this is AMP for Email, announced by Google in 2018 and shipped in Gmail as "dynamic email" in 2019. Yahoo Mail and Mail.ru also implemented support. It is the most technically careful attempt yet at making the inbox interactive, and it is still worth understanding before you leave it enabled.
How it rides inside a normal message
Nothing about the transport changes. The message is an ordinary multipart/alternative body with an extra part alongside the usual plain text and HTML versions, carrying the media type text/x-amp-html. A client that recognises that part renders it. Every client that does not, which is most of them, falls through to the HTML exactly as before.
The AMP part cannot contain arbitrary JavaScript. It is restricted to a fixed set of components, which is the design decision that makes the whole proposal defensible, because a message that could run whatever code it liked inside your mail client would be an obvious disaster. The components are the interesting part:
amp-listfetches JSON from an endpoint at render time and fills a template with itamp-formsubmits data back to an endpoint from inside the messageamp-bindupdates the display in response to your interactionamp-carouselandamp-accordionhold content you reveal by tapping
Two of those exist specifically to talk to the sender's server while you are reading. That is the feature working as intended: a booking confirmation showing your current seat, a survey you answer without leaving the inbox, a shipment status that is accurate rather than as-of-send.
How this differs from a tracking pixel
A tracking pixel is a one-shot beacon. It fires when images load, and it reports that the message was rendered, roughly when, from what address if nothing is proxying, and what client did the rendering. Providers that proxy and cache images blunt most of that.
Dynamic content moves the interaction from a beacon to a session. The sender's endpoint is contacted on render, can be contacted again on later renders, sees which sections you expanded, and receives whatever a form in the message submits. Open-count and dwell patterns become visible at a resolution a pixel cannot reach.
The consequence that gets least attention is not about tracking at all. The message is no longer a fixed record. What you read on Tuesday may not be what the message shows on Friday, and neither party retains a copy of what was actually rendered. A price, a deadline, a set of terms delivered this way can be revised after delivery with no trace in your mailbox.
An email you received was a document that arrived. A dynamic email is a window onto a server the sender still controls. The first can be archived, forwarded, and quoted as evidence of what was said. The second cannot, because there is no fixed version of it to keep.
What Gmail did to contain it
Gmail did not open this to every sender. Using dynamic email requires registering with Google, passing authentication checks across SPF, DKIM and DMARC, and maintaining a sending history with low complaint rates. The relevant background is in email authentication.
Rendering is also mediated. The AMP runtime is served by Google, not by the sender, and the endpoints a message may contact have to satisfy Gmail's own cross-origin requirements. Your address is not handed directly to the sender's server the way a naive remote fetch would hand it over.
That containment is real, and it has a shape worth naming plainly. The party standing between the sender and you is the mailbox provider, and the arrangement gives that provider visibility into a new class of in-message interaction that previously did not exist to be observed.
Why encrypted mail providers declined
For a client built around end-to-end encryption the format is close to unimplementable, for a reason that has nothing to do with the encryption itself. A message encrypted to your key can carry an AMP part perfectly well. Rendering that part means the reading client makes live network requests to an endpoint the sender chose, at the moment you read.
A client that blocks remote images by default, proxies what it does load, and strips beacons has built a careful set of controls around exactly that behaviour. Executing amp-list would step over all of them. The confidentiality of the body survives; the network-level exposure the controls existed to prevent comes straight back.
There is a governance objection as well. The rest of email runs on specifications anyone can implement from a published document. This format ties message rendering to one vendor's component library, one runtime, and a registration gate controlled by that vendor. Adoption reflects it: dynamic email never became a general expectation, Google's wider AMP program lost its privileged position in search, and most senders now build a good HTML message and link out to the interactive thing.
Three ways to receive the same message
| Form | What the sender learns | Is the message fixed? |
|---|---|---|
| Plain text | Nothing beyond delivery, unless you click a link | Yes |
| HTML with remote images | That it rendered, approximate time, client, and address unless proxied | Text is fixed; images can be swapped server-side |
| Dynamic (AMP) part | Each render, which sections you opened, and anything a form submits | No. Content is produced at read time. |
What to change
In Gmail the control is in Settings, under General, as a "Dynamic email" checkbox. Turning it off gives you the HTML part instead, which is the same thing every other mail client in the world already shows you, so nothing breaks.
Keep remote images off by default while you are in there, because in day-to-day terms the pixel problem is far larger than the dynamic-email problem. Pixels are in nearly every commercial message you receive; dynamic parts are rare. The same applies to the tracking parameters bolted onto the links, covered in link decoration.
If you send email rather than receive it, the arithmetic is not favourable. You still have to build and maintain the HTML fallback for the majority of recipients, so the interactive version is additional work rather than replacement work, and it adds a registration relationship plus a rendering dependency you do not control. Building the fallback well is the same effort with fewer parties in the loop.
The proposal that keeps coming back
Every few years someone tries to make email an application platform. Scripting in HTML mail, embedded controls in desktop clients, remote content of increasing sophistication, and now a curated component runtime. The motivation is consistent, because the inbox is where attention already is, and the security response is consistent too, which is to restrict what a message is permitted to do.
AMP for Email is the most disciplined version of that idea so far. It still gives up the property that makes email useful as a record: a message you have received should be readable with the network unplugged, and should say the same thing next year as it does today. Interactivity and that property are difficult to hold at once, and the format resolves the tension by dropping the second one. If you want the reasons that property is worth defending, why encrypt email and reading email headers cover the adjacent ground.