Interactive Email Was Supposed to Be AMP. It Became Something Else Entirely.

In February 2018, Google took the stage at AMP Conf in Amsterdam and ran a demo that made a room full of email people sit forward in their chairs. An email that wasn’t a picture of an interface. An email that was the interface. RSVP without leaving the message. Browse a product carousel inline. Submit a form and watch the response come back, right there in the inbox. The case for interactive email had never been made that cleanly.

Eight years later, only 22% of email platforms have built support for sending it, and fewer than 5% of their users routinely do.

That gap is worth sitting with, because this isn’t a story about a bad idea. AMP for Email was a genuinely good idea, built by smart people, solving a real problem. It just picked a fight it couldn’t win. And while it was losing that fight, interactive email showed up somewhere nobody was watching.

What AMP actually asked you to sign up for

The mechanics matter here, because they explain everything that followed.

An AMP email isn’t a different email. It’s a third MIME part (text/x-amp-html) riding alongside your plain text and HTML versions. Supporting clients render the AMP part. Everyone else falls back to the HTML you were already sending. On paper, that’s an elegant piece of design: progressive enhancement, no downside.

In practice, you’re now maintaining two versions of every campaign. You register your sending domain with Google and wait for approval. If your AMP email pulls live data, you stand up and own the endpoints it calls, with the uptime guarantees and CORS headers that implies. Then you QA across a client matrix that behaves three different ways.

None of that is unreasonable on its own. Stacked together, it’s a real engineering commitment. And you make that commitment before you know whether the payoff is there.

The client support problem never got better

Gmail shipped AMP support broadly in March 2019. Yahoo Mail and Mail.ru followed. That was the high-water mark.

Outlook.com announced support, tested it, and quietly walked away. Apple Mail never showed serious interest. Fastmail and Proton render the fallback. Check Can I Email today and the picture is essentially unchanged from 2019, which is remarkable for a web technology in an eight-year window.

Badsender put the three supporting clients at around 30% of opens worldwide. So: build it twice, maintain two endpoints, pass a manual review, and reach maybe a third of your list with the good version. Everyone else gets the static fallback you would have built anyway.

I’ve watched teams run that math in a planning meeting and talk themselves out of it in under ten minutes. Not because they didn’t want interactivity. Because the ratio of work to reach never closed.

AMP lost the web before it lost the inbox

Here’s the part that gets left out of most AMP post-mortems.

In June 2021, Google’s Page Experience update removed AMP as a requirement for Top Stories. That single change pulled the load-bearing wall out of the whole project. AMP on the web was never mostly about speed for publishers. It was about the carousel. Once any fast page could qualify, publishers started switching it off: the Irish Independent and Belfast Telegraph dropped it outright, and Press Gazette reported the New York Times and Washington Post were weighing the same move.

Email teams noticed. When the parent technology stops being strategically necessary to the company that built it, you start asking uncomfortable questions about the offshoot. Will this still be supported in three years? Is anyone at Google still working on it? Those questions are hard to answer with a roadmap, and they’re exactly the questions a CTO asks when you request engineering time.

Momentum is a real asset in technology adoption. AMP for Email lost it in 2021 and never got it back.

Interactive email didn’t die. It moved to the server.

So what did AMP get right, and what did it get wrong?

Right: email content shouldn’t be frozen at the moment you hit send. A message that says “only 4 left in stock” is lying to whoever opens it on Thursday. That observation was correct in 2018 and it’s more correct now.

Wrong: the assumption that the only way to unfreeze content is to run code inside the email client. That assumption is what forced the whole client-support problem into existence.

There’s another place to put the logic. Not in the client. On the server, at the moment the recipient’s mail app requests an image.

Every email client loads images. That’s the one thing they all do. Outlook 2013, Apple Mail, Gmail on Android, the webmail client at a bank running software from 2011. They differ wildly on CSS support, they differ on dark mode, they differ on whether they’ll let you use a <div> without a fight. They agree on images.

Which means if you render the image at request time rather than at send time, you get content that reflects the actual moment of opening, delivered through a channel with 100% support. Countdown timers that count down. Product blocks reflecting live inventory. Store maps built around where the reader actually is. Weather, time of day, device, language, all resolved at open.

The best data I can point to is a Forrester Total Economic Impact study of Movable Ink, the biggest vendor in this space, which put the ROI of open-time content at 422% over three years. Movable Ink commissioned it, so weight it accordingly. But the direction matches what you’d expect, and it matches what I’ve seen: a countdown that’s genuinely counting outperforms a countdown baked into a static JPEG, every time.

Is it as flexible as a form you can submit inline? No. You’re rendering pixels, not running an application. But you’re rendering them for everyone, with no registration, no second endpoint to babysit, and no client matrix to argue about.

The bar moved again, and it moved toward this

Gmail’s Gemini layer changed the shape of the problem. In the quarter Gemini summaries rolled out, Omeda’s engagement report, covering 2 billion sends, saw total open rates climb to 45.6% while unique click-through fell from 4.35% to 3.93%. People are reading the AI summary and moving on. Folderly’s analysis puts up to 40% of Gmail-delivered mail getting deprioritized before a human sees it.

Think about what that does to the case for in-email interactivity. If a growing share of your audience never fully opens the message, the value of an inline form drops. But the value of the content being correct in the two seconds they do look goes up sharply. A stale price or an expired offer doesn’t just underperform now. It teaches the reader that your email isn’t worth the glance.

That’s the shift. Interactive email in 2018 meant “let them do things in the message.” Interactive email in 2026 mostly means “make sure the message is true when they see it.” The second definition is less exciting and considerably more useful.

Where I’d actually put your effort

If you have engineering appetite and a Gmail-heavy list, AMP is still worth a pilot. It works. Mailmodo and a handful of others have built real businesses on it. Just go in knowing you’re building for a slice of your audience and maintaining two versions indefinitely.

For everyone else, the honest answer is that the interactivity you probably want (urgency, relevance, live data) doesn’t require AMP at all. Start with the piece of your email that’s most often wrong by the time someone opens it. That’s usually a deadline, a price, or an availability claim. Fix that one thing at open time and measure it. Then find the next one.

Alterable does exactly this: countdown timers, dynamic images, live product blocks, store maps, all rendered the moment the email is opened and delivered as an image any client can display. If you’ve been holding off on interactive email because the AMP tooling never justified itself, that’s the gap worth looking at.

Voilà. No MIME part required.