The Rise of Interactive Email: AMP and Beyond in 2026

AMP for Email launched in 2019 with Google's backing, a roster of household-name partners, and a genuinely good idea. Eight years on it is supported by three mailbox providers and used by a low single-digit percentage of email programmes. That's the part most coverage leaves out.

The support list, which explains almost everything

Start here, because every strategic question about AMP resolves back to it.

Two things follow immediately. Apple Mail is a very large share of opens for consumer audiences, and Outlook dominates corporate ones — so for most lists, the majority of recipients cannot see an AMP email at all. And because of that, every AMP campaign has to ship a complete HTML fallback anyway.

The structural problem AMP doesn't replace your email. It's a second email you build in addition to the one you were already building — for the minority of your list who can see it.

That's not a criticism of the technology, which works. It's the arithmetic that has kept adoption flat for the better part of a decade, and it's why Outlook's withdrawal in 2020 mattered more than any feature release since.

Be careful with the adoption statistics

This category has a data problem worth naming, because you'll encounter it the moment you start researching.

Litmus reporting has placed AMP usage at roughly 2% of tracked programmes — a niche tactic, described as such for years. Meanwhile a widely circulated figure suggesting around a quarter of senders use interactive email comes from a report published by a company whose product is an AMP email builder, and measures interactivity broadly rather than AMP specifically. Both numbers get quoted in the same articles, often without distinguishing them.

Neither figure is dishonest. They measure different things and come from parties with different interests. The practical rule: in this category, check who published the research before you plan around it, because the vendors with the most to gain from adoption also produce most of the adoption data.

So what is actually rising?

Interactive email genuinely is growing. It's just mostly not AMP, and the distinction matters because the two carry completely different costs.

CSS-based interactivity

The quiet workhorse. Standard HTML and CSS techniques producing carousels, hover states, accordions, image swaps and simple hotspot reveals — no separate document format, no whitelisting, no live data.

Support is inconsistent, but that matters far less than it does with AMP because these techniques degrade gracefully: a client that doesn't support the interaction shows a static version of the same content. You build one email, not two. For most teams wanting to make a message feel less flat, this is where to start and often where to stop.

Server-side dynamic content

Content assembled at send time from your own data — different blocks, products, offers or copy per recipient. Not interactive in the click-inside-the-inbox sense, but it produces the relevance that interactivity is usually being reached for as a proxy.

It works everywhere, in every client, with no support caveats at all. And it's increasingly where the practical gains sit, particularly as AI reshapes email personalisation and makes per-recipient assembly cheaper to operate.

Real-time content via image services

An older technique that keeps earning its place: content rendered as an image generated at open time, so countdown timers, live inventory or updated pricing reflect the moment of opening rather than the moment of sending. It works in most clients since it's just an image, though it depends on images loading and privacy features have made that less reliable than it was.

Featured Recommendation AD · AFFILIATE

4.6 / 5.0

MailerLite

Simple and affordable email builder with clean templates and reliable deliverability

Best for: Simple Email Builder

Visit Website

View details Compare

Gmail's own structured features

Easy to overlook because it isn't "interactive" in the demo sense, but Gmail supports structured markup that produces promotional cards, order summaries and action buttons in the inbox list view — before the message is even opened. For transactional and e-commerce senders that's often higher-leverage than anything inside the email body, because it works on the screen where the open decision gets made.

It also uses the same schema thinking as the rest of your machine-readable content work, so the skill transfers.

The accessibility question

Barely mentioned in this category and it should be, because interactivity and accessibility pull against each other unless someone is watching.

Custom interactive components frequently break screen reader navigation, keyboard operation and focus order — email clients strip and rewrite markup unpredictably, so accessibility behaviour that works in a browser often doesn't survive the inbox. A carousel a sighted mouse user enjoys can be an unusable dead end for someone navigating by keyboard.

The practical guard: every interactive element needs a non-interactive path to the same information and the same action. If the only way to reach the offer is through the interaction, some of your recipients can't reach it at all. That's the same reasoning that makes the fallback question central rather than incidental.

Where AMP is genuinely worth it

Having been blunt about the constraints, there's a real case for it in a narrow band — and the published examples are consistent about where.

The pattern across brands using it successfully is that the interaction removes a concrete step in a moment where intent already exists and timing matters:

• Confirming or changing a booking without a round trip to a website
• Updating delivery or preference settings where the alternative is a login
• Short surveys and feedback, where every removed click costs you responses
• Live order or delivery status that updates when reopened rather than going stale
• Cart interactions where the item and the intent are both already established — the same logic driving cart recovery flows

What isn't on that list is ordinary promotional email. Browsing a catalogue inside an inbox sounds appealing and mostly isn't — people don't open marketing email expecting to shop in it, and the interaction competes with a simple, well-placed link that works for everybody.

The costs teams underestimate

Four, and they're operational rather than technical — which is why they surprise people who evaluated the format on capability alone.

You build twice, forever. Not just at launch. Every subsequent edit, every seasonal update, every offer change happens in two places. The maintenance cost compounds in a way the initial build estimate never captures.

Whitelisting is per-provider and slow. Each supporting provider requires separate registration and approval of your sending domain, with its own requirements. This takes weeks and has to be maintained.

QA expands substantially. You're now validating two experiences across a client matrix that was already awkward. Every bug is potentially two bugs.

Reporting gets harder to read. The subtlest cost and the most damaging. Gmail recipients get the rich version; everyone else gets the fallback — and if the fallback underperforms, that reads in your dashboard as a creative problem when it's actually a support problem. Teams have redesigned campaigns to fix results that were only ever a client-mix artefact.

There's a fifth worth watching: sending a second document format changes your message structure, and anything that changes structure can interact with filtering. It isn't that AMP harms deliverability by design — it doesn't — but a build error in the AMP part can affect how the whole message is handled, which makes an inbox placement problem harder to diagnose. Any AMP rollout should be staged and monitored rather than switched on across a full list.

That reporting point deserves emphasis because it compounds an existing difficulty. Email measurement is already strained by the privacy changes that broke open rates — covered in our piece on what Apple and Gmail's updates changed for email marketers — and adding a second experience with different tracking behaviour on top of that makes the numbers harder still to interpret honestly.

If you do it, do the fallback first

The single most useful piece of practical advice in this area, and the one most often reversed.

Design and build the static HTML version first, to full production standard: clear hierarchy, obvious call to action, tracking aligned to the goal. Then add the AMP layer on top for the recipients who can use it.

Teams that build the interactive version first almost always end up with a fallback that feels like a downgrade — a thinner layout, a weaker call to action, an afterthought. Given that the fallback is what the majority of your list receives, that's precisely backwards. If your HTML version isn't good enough to send on its own, the AMP build shouldn't start.

The bigger point about interactivity

Worth stepping back, because the enthusiasm for interactive email often skips the question of whether recipients want it.

People don't generally open marketing email to spend time in it. They open it to find out whether something is relevant and, if so, what to do about it. An email that's genuinely useful in eight seconds beats an email that rewards two minutes of interaction, because the eight seconds is what's actually on offer.

Which means the highest-return work in most email programmes isn't interactivity at all. It's the unglamorous foundation: the core automated flows firing at the right moments, a list built from people who genuinely want to hear from you rather than bought or scraped — the substance of owned audience fundamentals — and messages that are clear about what they're offering.

A brand with a well-built welcome sequence and a clean list will out-earn a brand with an AMP carousel and neither. That's not an argument against interactivity; it's an argument about order of operations.

What to do this quarter

1. Pull your own client mix. Most ESPs report it. If Gmail and Yahoo are a small minority of your opens, the AMP question is already answered.
2. Add CSS interactivity where it helps. An accordion in a long newsletter, a carousel in a product email. One build, graceful degradation, no whitelisting.
3. Invest in server-side dynamic content instead. Works everywhere, no caveats, and delivers the relevance interactivity is usually standing in for.
4. Reserve AMP for repeated transactional and lifecycle messages where the interaction removes a genuine step — and where you'll send it for years.
5. Fix the fallback before anything else. It's what most of your list sees regardless of what you build on top.

If the constraint is capacity rather than strategy — flows to build, templates to maintain, two versions to keep in sync — that's exactly the sort of ongoing work an e-commerce and lifecycle marketing partner absorbs more efficiently than a small internal team learning it once.

The short version

AMP for Email is eight years old, supported by three providers, and used by roughly 2% of tracked programmes. It's genuinely good for repeated transactional messages where an interaction removes a real step — and a poor fit for almost everything else, because you build twice and most of your list sees the fallback. Interactive email is rising, but through CSS techniques and server-side dynamic content rather than AMP. Build the static version to production standard first; the majority of your recipients will only ever see that one.