AMP for Email in 2024: Hype, Reality, and Whether to Bother

AMP for Email promised interactive inboxes. Six years after launch, here is who actually supports it, what it costs to run, and when the investment makes sense.

Google launched AMP for Email in 2019 with a bold pitch: emails that behave like small web apps, with live data, forms, and carousels rendered directly in the inbox. Five years on, the technology works, the demos are impressive, and adoption remains narrow. This article looks at what AMP for Email actually delivers in production, what it costs to operate, and which senders should care.

How AMP for Email actually works

An AMP email is a standard multipart MIME message with a third body part, text/x-amp-html, alongside the usual text/plain and text/html parts. Clients that support AMP and trust the sender render the AMP part; every other client falls back to the HTML part. The AMP part is written in a restricted markup dialect with a whitelisted component set: amp-form, amp-list, amp-carousel, amp-bind, and a handful of others.

multipart/alternative
├── text/plain          (plain text fallback)
├── text/x-amp-html     (AMP version, rendered by Gmail/Yahoo)
└── text/html           (HTML fallback, rendered everywhere else)

Dynamic behaviour comes from server endpoints. An amp-list component fetches JSON from your API at open time, which means the email can show current inventory, an updated delivery status, or live pricing. Form submissions post back to your endpoint with CORS headers specific to the AMP runtime. Your infrastructure is now part of the rendering path, and if the endpoint is down, the component fails.

The support matrix is short

Gmail supports AMP in the web client and mobile apps. Yahoo Mail supports it on the web. Mail.ru supports it. That is essentially the complete list. Apple Mail, Outlook, Thunderbird, and the entire business filtering ecosystem render the HTML fallback. Microsoft ran an AMP pilot in Outlook.com and ended it in 2020, which tells you where they landed on the idea.

Registration and the deliverability bar

You cannot simply start sending AMP parts. Gmail requires senders to register through its AMP registration form, demonstrate a history of low spam rates, and send authenticated production examples for review. Yahoo runs a separate registration. Both require SPF, DKIM, and DMARC to pass consistently, and both can revoke rendering if your reputation slips.

The registration requirement has a useful side effect: AMP is unavailable to poorly authenticated senders by design, so the feature itself has stayed largely free of abuse. It has also kept the adopter pool small, because the review process adds weeks to any rollout plan.

The operating cost nobody mentions

Every AMP campaign is two builds: the AMP part and an HTML fallback that must stand on its own. Testing doubles, because rendering bugs in the AMP dialect are their own category. ESP support is uneven; some platforms pass the extra MIME part through cleanly, others strip it, and link rewriting for click tracking can break AMP components in ways that only show up in production.

In addition, AMP content has a shelf life. Gmail stops rendering the dynamic version roughly 30 days after delivery and shows the fallback instead. Any recipient who opens an old message sees the HTML version, so the fallback is not an edge case. It is the long-term record of your message.

Where AMP earns its keep

The pattern in successful deployments is consistent: high-volume transactional or lifecycle mail where completing an action inside the message removes a landing page from the funnel. Single-question NPS surveys answered in the inbox see materially higher completion than link-out surveys. Appointment confirmations, RSVP flows, and account verification steps benefit for the same reason.

Marketing newsletters benefit least. A carousel of products is marginally nicer than a static grid, but it does not remove a step from any funnel, and the audience segment that can see it is capped by the support matrix. If your case for AMP is aesthetic rather than functional, the maintenance cost will outrun the return.

Treat AMP as a conversion optimization for specific transactional flows, not a platform strategy. Measure the share of your audience that can render it, pick one flow where an in-message action removes real friction, and let the results decide whether the second template is worth maintaining.