Building interactive emails that actually reach users is possible

Interactive emails let users take action—like completing a survey or booking—without leaving the inbox. Fewer clicks mean less friction, better results, and a more enjoyable experience. From polls and quizzes to gamified product carts, interactive emails feel like mini apps people actually want to use.

To enable this, most teams turn to one of two technologies:

  • AMP for Email – rich, app-like experiences
  • Kinetic HTML – broader support via HTML5 and CSS3

Naturally, teams have different preferences:

  • Some lean toward AMP
  • Others stick with kinetic HTML
  • Some avoid interactivity, seeing it as too complex or time-consuming

Each of these choices makes sense depending on the situation. But if we focus too much on the tools, we risk losing sight of the bigger goal: creating useful, smooth, and enjoyable emails for all users.

That’s why we believe in a user-first approach—one that doesn’t choose sides, but combines the best of both technologies when possible. Because what matters most isn’t what’s under the hood—it’s how the email works for the person opening it.

Why neither AMP nor kinetic HTML alone is enough

AMP’s limitations

AMP brings real-time updates, carousels, and in-email forms. It works with Gmail, Yahoo, and FairEmail, which together cover about 30% of global email client usage. But it’s far from universal.

Even when recipients use a compatible client, not all ESPs can send AMP properly. Some strip it out, others don’t render it as intended. That makes AMP powerful—but unreliable if used on its own.

I used to believe AMP, as an open-source standard, would open the door to collaboration and push email toward a more interactive future. But that vision hasn’t fully materialized. Too many obstacles—technical, organizational, and platform-related—stand in the way. Instead of pushing for adoption, we need to reduce the friction that stops teams from embracing it.

Kinetic HTML’s reach and roadblocks

Kinetic content uses HTML5 and CSS3 to simulate interactivity without JavaScript. Techniques like checkboxes and radio buttons help create interactive elements that work across Apple Mail, Samsung Mail, and Thunderbird—roughly 55–60% of users.

But just like AMP, kinetic HTML has limits. Some clients don’t support the required CSS, and some ESPs don’t process kinetic content correctly. It’s more flexible than AMP in some ways, but still not universal.

So what about those who use other email clients? Or if the ESP or CRM has no support for AMP?

A combined solution: interactive emails for all

We can’t control which email client our recipients use—and that’s a big deal when it comes to interactivity. Some use Gmail that supports AMP, some use Apple or Samsung Mail that support kinetic HTML, and some email clients like Outlook don’t support either fully.

06 Dmytro Picture1

(Stats collected on Email Client Market Share. May 2025)

That’s why it’s crucial to enable interactivity across as many email clients as possible. The more accessible the experience, the more users we reach.

If we want as many people as possible to enjoy interactive content, we need to layer technologies and build fallback options. Here’s what that looks like:

Step 1. Start with building a kinetic email

Start by using HTML5 and CSS3 to create the interactive experience as it offers the broadest support across modern email clients.

We used to be strong AMP advocates. But over time, we shifted our focus. While AMP is powerful, kinetic HTML simply reaches more people. That’s why it makes sense to start here.

Step 2. Add fallback for those that don’t support kinetic email

Older and enterprise-focused clients like Outlook often can’t display kinetic content properly. They may strip out interactive elements or break the layout.

A fallback helps solve that. It can be static content or a version that looks interactive but links to a web page upon interaction with it. Either way, it ensures users still get a working email experience.

Fallbacks are essential. Without them, thousands of users may receive broken or confusing messages.

The challenge with kinetic and fallback coexistence

Here’s the tricky part: both kinetic and fallback content live in the same HTML version of the email. That means email clients don’t automatically choose between them like they do with AMP. Instead, we have to use special coding techniques—like CSS tricks and conditional comments—to show the right version based on what the client supports.

By default, the static fallback is shown. The kinetic version is only revealed if the email client supports advanced HTML and CSS.

Step 3. Enriching emails with AMP

As mentioned, AMP brings dynamic, interactive content directly into emails. When a subscriber’s email client supports AMP, they’ll see that version—which offers even richer interactivity than kinetic HTML.

Here’s the good news: recipients only see one version. Their email client decides automatically. If AMP is supported, it displays the AMP (text/x-amp-html) version. If not, it falls back to the HTML (text/html) version, which may include kinetic content or a static fallback that mimics interactivity.

In short, AMP is prioritized when supported. Otherwise, email clients display the HTML version—either kinetic or fallback.

Word of advice

When you create an interactive email that works well across your entire contact base, save it as a module. You can then easily reuse it—just replace the content or tweak it through a visual editor. With modular email design, this kind of efficiency is absolutely possible.

Final thoughts

Let me repeat myself: No single technology covers everyone. But if you combine AMP, kinetic HTML, and static fallback into one strategy, you can build interactive emails that actually reach users—wherever they are.

So let’s stop asking whether AMP is still relevant. It is.

Let’s stop thinking HTML5 and CSS3 are enough. They aren’t.

Each technology has its mission. And only together can they bring interactivity to life in a way that’s reliable, inclusive, and future-ready.