AMP for email embeds a third, interactive version of your message—forms, carousels, live-updating content—alongside the HTML and plain-text parts. The demos are genuinely impressive. The economics mostly aren’t.
Why this is a no
- The audience is one inbox. Gmail is the meaningful surface for AMP; support elsewhere is niche to nonexistent, and Apple Mail—a giant share of real-world opens—will never render it. You’d be building an experience most of your list can’t see.
- The toll booth is real. Gmail requires per-sender registration and approval before your AMP parts render, with quality and authentication bars to clear first. Miss any condition and recipients silently get the fallback.
- You must build the fallback anyway. Every AMP email still needs a complete HTML version for everyone else—so the AMP part is additive work on top of a finished email, not a replacement. Dynamic AMP content also expires (stale messages fall back too), which means testing two experiences forever.
- It solves a problem the web already solved. A well-labeled link to a page you control works in every client, needs no approval, and is where your form/survey/checkout probably lives anyway.
The narrow yes hiding in the depends
If your audience is measurably Gmail-heavy, you send high-value interactive flows (think booking confirmations with live seat maps, or in-email RSVP at serious volume), and you have the engineering appetite for a third rendering pipeline—AMP can genuinely lift completion rates by removing a click. Companies in that exact position make it work. If you had to check whether you’re in that position, you’re not.
The honest framing
AMP is a hype-check classic: real technology, real demos, and a cost/reach ratio that only pencils out for a sliver of senders. Ship great HTML, keep the plain-text honest, and put interactivity on the other side of a fast link.