mailinapp
Documentation menu

Why not AMP for Email?

AMP for Email is Google's technology for running real interactive components — carousels, forms, live pricing — natively inside a message, no tap-through required. It's a legitimate technology, and a natural question: why doesn't MailInApp build on it instead of (or alongside) kinetic HTML/CSS? This page lays out the trade-off explicitly, because it's a deliberate bet, not an oversight.

What AMP for Email actually is, and its two costs

AMP messages ship as an extra MIME part alongside the regular HTML, built with a constrained set of amp-* components (Google's AMP framework, repurposed for email). Where it renders, it's genuinely native — no static fallback needed for that inbox.

It comes with two costs that don't show up in a feature-comparison table:

  1. Per-sender approval. Every sending domain must register with Google and pass a review before any recipient ever sees an AMP message from it — a gate outside your control, with its own timeline and rejection risk, sitting in front of every campaign.
  2. Narrow rendering support. Only Gmail, Yahoo Mail, and Mail.ru render AMP at all. Every other client — Apple Mail, Outlook (classic and new), Fastmail, Proton, Samsung Mail — ignores the AMP part entirely and falls back to whatever plain HTML part shipped alongside it.

The reach math

Using Litmus's email client market share data (~1B tracked opens, May 2026):

| | Share of opens | | --- | --- | | Apple Mail | 64.7% | | Gmail | 24.1% | | Outlook (all versions) | 6.9% | | Yahoo Mail | 2.6% | | Everything else | 1.7% |

Gmail and Yahoo together — the only real-world AMP audience — account for roughly 27% of opens. The other ~73%, led by Apple Mail alone at nearly two-thirds of all opens, would never see an AMP component no matter how well it was built. And even within Gmail, AMP for Email requires the recipient to be reading a Gmail account through Gmail's own client — the mobile app reading a non-Gmail (IMAP) inbox doesn't qualify either.

Any list of real recipients is going to be majority-Apple-Mail. Betting the interactive experience on AMP means most of that list never sees it.

Why kinetic HTML is the better bet for a typical list

MailInApp's kinetic tier — :checked-driven CSS state machines for carousels, accordions, polls, spin-to-win, plus real in-email <form> posts where supported — reaches Gmail (web and mobile), Apple Mail, Yahoo Mail and Samsung Mail: the large majority of consumer inboxes, Apple Mail included. See Email client support for the full matrix and How fallbacks work for how the three tiers compile from one design.

That's the core of the trade-off: the same fallback-engine investment pays out across effectively the whole list, not just the ~27% AMP could ever reach — and it ships without a per-sender approval gate sitting in front of every campaign. AMP's ceiling is higher in the one place it renders (truly native components, no tap-through at all), but it can't be the primary interactive layer for an audience that's overwhelmingly not Gmail.

Does this rule AMP out permanently?

Not architecturally. Kinetic HTML/CSS and Tier 2's plain-link fallback are already the safe baseline every client falls back to — the same three-tier model this page describes could carry a fourth, AMP-specific part for Gmail/Yahoo recipients on top of it someday, without touching how the other tiers work. It's just not where the fallback engine's effort goes first: reaching every inbox with one dependable technique beats reaching a quarter of inboxes natively and the rest not at all.