← All essays

Product · May 2026 · 4 min read

AMP4Email in 2026: what actually renders where.

Seven years in, the format has settled into a stable but strange shape. It renders in some inboxes. It vanishes in others. The honest coverage math is where every project decision starts.

Seven years in, AMP4Email has settled into a stable but strange shape. It renders beautifully in some inboxes. It vanishes entirely in others. The middle case, the one that governs every project decision, is the multipart fallback.

The state of coverage in 2026 is worth stating plainly. A lot of the guidance that circulates about AMP4Email is out of date, wishful, or both.

Here is the honest version.

Where it renders

Gmail supports it. That is the anchor tenant. Google turned on dynamic email in 2019 for consumer accounts, extended it to Workspace by default in 2020, and has not walked either back. If your recipient reads mail in Gmail on web, Android or iOS, and the sender is registered, the AMP part renders.

Yahoo supports it. Both the free tier and the business tier show dynamic email with the same sender registration requirement. Adoption is smaller than Gmail but not negligible, and Yahoo is still the second largest consumer inbox in North America.

Mail.ru supports it. Relevant if you send to Russian speakers or eastern European lists.

Fastmail supports it as of 2024. Small in absolute numbers, meaningful because a lot of technical audiences live there.

That is the list. Everything else falls to the HTML fallback.

Where it does not render

Outlook, in every form, ignores the AMP part. Desktop, web, mobile, all of it. Microsoft has not signaled intent to add support in the seven years since the format shipped.

Apple Mail ignores it. iOS Mail ignores it. This one hurts more than it should, because Apple is a significant slice of engaged audiences and the format degrades cleanly, so the loss is invisible.

Superhuman, Hey, Front, and most third party clients built on IMAP have no support. They render the HTML part the way any client would.

Yahoo on mobile is the tricky one. Yahoo on the web works. The iOS and Android apps are inconsistent. Assume the HTML fallback for anything you want to guarantee.

What the coverage math actually looks like

A B2C list skewing toward younger consumers with Gmail Personal and iOS Mail as the top two clients typically sees roughly a third of opens land in a dynamic capable inbox. An older skew or heavier Outlook presence pulls that number down fast.

B2B is worse. Corporate Outlook on desktop dominates most enterprise sends. Dynamic capable coverage on a typical B2B list sits closer to ten or fifteen percent.

None of this makes AMP4Email a bad bet. It makes the fallback the primary artifact. Which is exactly how the multipart MIME container was designed to work.

Graceful degradation, plainly

A well formed AMP4Email is a multipart alternative message. It carries three parts: a plain text version, an HTML version and the AMP version. The receiving client picks the first one it can render, starting from the AMP part.

The HTML part is not a placeholder. It is the message that most of your recipients actually receive. If it is a stripped down version of the AMP experience, most of your audience gets a stripped down version of the message. If it is a full, well designed email that stands on its own, then AMP4Email becomes the enhancement it was meant to be.

The teams that get real return from AMP4Email build the HTML first, ship it, then layer AMP on top for the audience that will benefit. The teams that get burned treat AMP as the primary and the HTML as an afterthought.

When to build it and when to skip it

Build it when the interactive gesture is worth the AMP part on its own. A live product grid that reflects inventory at open time. An RSVP that records without a click through. A preference toggle that updates the profile in place. These pay for themselves in the third of the list that sees them.

Skip it when the interaction is really just a link. If the AMP version is a fancier link to your site, you spent engineering hours to move the click from the email to the email. The HTML link would have done the same job.

Skip it also when the send is transactional and every recipient must see the same thing. A password reset does not need dynamic content. It needs to arrive.

“The interactive layer is an enhancement. The fallback is the message.”

Keep reading

Engineering · Aug 2026

SSJS and external APIs: the token hygiene checklist.

Engineering · Aug 2026

AMPscript error handling: catching the silent failures.