Whether AMP for email is worth building depends almost entirely on where your audience opens mail. Gmail, Yahoo Mail, AOL, and Mail.ru render AMP’s interactive components: forms, carousels, live pricing panels that update in place inside the message. Apple Mail and Outlook do not, and between them those two clients account for a large share of most inbox opens, so every AMP email still needs a complete, standalone HTML version behind it. Technically, that means adding a third MIME part, text/x-amp-html, next to the text/html and text/plain parts a normal message already carries, then getting your sending domain approved by each supporting provider before any of it renders. The build cost is real. So is the ceiling on how much of your list will ever see the interactive version.
What AMP for Email Actually Does
AMP for email is Google’s format for embedding a subset of AMPHTML components inside a message, letting supporting inboxes render carousels, accordions, and forms that accept input, instead of a static image-and-text layout (amp.dev). The interactive layer sits on top of a conventional email, not instead of one. Google frames the goal as letting recipients “engage with content and quickly take action such as RSVP to events, fill out questionnaires and personalize their content” without leaving the inbox, and notes that “AMP emails are always up to date” because the content can refresh after the message was sent (amp.dev).
AMP for email embeds a third MIME part, text/x-amp-html, alongside the HTML and plain-text parts a normal message already carries. Supporting inboxes render the interactive version; every other client falls back to the standard HTML email, which means the fallback is not a backup plan, it is the version most recipients will actually open.
Which Email Clients Actually Render It
Support is narrow and concentrated in a handful of webmail providers. Per caniemail.com’s AMP feature tracker, current support looks like this:
| Client | AMP Support | Supported Since |
|---|---|---|
| Gmail (web, iOS, Android) | Yes | April 2020 |
| Yahoo Mail (web, iOS, Android) | Yes | October 2019 |
| AOL Mail | Yes | October 2019 |
| Mail.ru (web) | Yes | October 2020 |
| Apple Mail (macOS, iOS) | No | n/a |
| Outlook (desktop, web, mobile) | No | n/a |
| Samsung Email, Thunderbird | No | n/a |
Caniemail puts overall support at roughly 16% of tested clients. That number is the real constraint on this feature: Apple Mail and Outlook, absent from the list, are two of the most heavily used clients in most B2C sending programs, which is exactly why a full non-AMP fallback is not optional.
How the Multipart Message Is Built
Structurally, an AMP email is a multipart/alternative message with one extra branch. Per amp.dev’s specification, “the multipart/alternative must contain at least one non-AMP (text/plain or text/html) node in addition to the text/x-amp-html node,” and the recommended order places the AMP part before the HTML part, “since some email clients will only render the last MIME part” (amp.dev). A minimal structure looks like this:
Content-Type: multipart/alternative; boundary="boundary42"
--boundary42
Content-Type: text/plain
Plain-text fallback for clients with no HTML support.
--boundary42
Content-Type: text/x-amp-html
<!doctype html>
<html amp4email>
...AMP markup...
</html>
--boundary42
Content-Type: text/html
<html>...HTML fallback, same content as the AMP version...</html>
--boundary42--This is the same multipart/alternative pattern behind any correctly built HTML email, just with a third branch instead of two; see How to Send HTML Email the Right Way for the base two-part version most sends already use. Because the HTML branch is what most recipients see, it needs to hold up as a standalone message on its own merits, not read like an afterthought. Email Design Best Practices covers the layout and rendering rules that fallback should follow.
Getting Whitelisted: The Sender Registration Requirement
Sending AMP email requires approval you do not need for a normal HTML send. Per amp.dev, a compliant message must “pass SPF/DKIM/DMARC with matching TLD with ‘From:’ address,” “have a fallback text/html MIME part,” and “comply with all client sender requirements” before registration is even considered (amp.dev). Registration itself is a single shared form covering Gmail, Yahoo Mail, and Mail.ru, submitted alongside a real production email that includes the AMP MIME part. Each client then evaluates the request independently and, per amp.dev, “will notify you of your allowlist status via email.” Budget lead time before a launch date: this is not an instant, self-serve toggle, and each provider can take its own path to a decision.
Where the Complexity Pays Off
AMP for email earns its build cost in a narrow set of cases, not as a general-purpose upgrade to every campaign. The use cases that actually show up in practice: surveys and NPS collection built directly into the message, since AMP “allows marketers to send surveys and collect data” without a click-through (Litmus); RSVP and booking widgets that let a recipient “book meetings for product demos, register for webinars or conferences, request support calls or appointments” from inside the inbox (Litmus); and live pricing or inventory panels, where “an email using AMP can provide up-to-the-minute, accurate information on inventory and pricing” days after the original send (Litmus).
Post-purchase review requests fit the same pattern: a rating widget the recipient can submit inline, triggered by a specific action like a completed order. That triggered, single-recipient framing is closer in spirit to transactional email than to a bulk marketing send, even when a growth or lifecycle team owns the build.
The Trade-offs Nobody Advertises
The reach ceiling is the first cost: with AMP rendering in roughly 16% of tested clients, the majority of any list sees the plain HTML version, meaning the interactive build serves a minority audience by design, not by accident. Litmus reports a second, less obvious constraint on the tooling side: “far too few ESPs actually support it,” according to Jaina Mistry, Litmus’s Director of Email Marketing, which limits how many teams can even ship an AMP send without custom MIME handling (Litmus).
The AMP layer is also more restricted than it might look. Ad components are not permitted inside AMP email, and requests the AMP markup makes back to your servers are proxied and stripped of cookies to protect recipient data (amp.dev). That is a reasonable security trade for an inbox context, but it means AMP components cannot do everything a normal web form can.
Then there is ongoing maintenance: every AMP send is really two builds, the interactive version and the HTML fallback, that need to stay in sync as copy and design change. Teams already managing templates as components, for example with React Email, have an easier time keeping both versions aligned, since shared layout logic can feed the fallback markup and the structure the AMP version mirrors. If you are already sending multipart HTML through Coldletter’s API, adding the text/x-amp-html branch is an additional part in the same message rather than a new pipeline; start a free trial to see how the sending API and template layer handle multipart builds.
None of this is hypothetical skepticism. In a Litmus poll of 333 email professionals asking which trend “has got to go,” AMP for email received the most votes of any option, ahead of trends with far less enterprise investment behind them (Litmus).
Should You Build AMP for Email in 2026?
Build it when three things line up: your domain already sends at meaningful volume with clean SPF/DKIM/DMARC alignment, a large share of your list opens mail in Gmail or Yahoo (common for B2B SaaS audiences using Workspace accounts), and the use case is narrow and high-value, an NPS survey, an event RSVP, a recurring pricing update, rather than a one-off campaign. Skip it when your audience skews Apple Mail or Outlook, which is typical for many consumer B2C lists, or when the interactive behavior can be delivered just as well with a plain HTML email that links to a fast landing page. A click-through to a web form costs a fraction of the engineering time and reaches every recipient, not the 16% AMP currently covers.
Frequently Asked Questions
Does Outlook or Apple Mail support AMP for email?
No. Neither renders AMP components as of 2026. Recipients on those clients, and on any other unsupported client, see the standard text/html fallback part of the same message, which is why that fallback must be a complete, standalone email rather than a placeholder.
What happens if an AMP email is opened in an unsupported client?
The client ignores the text/x-amp-html MIME part entirely and renders the next usable part in the multipart/alternative structure, normally the text/html version. The recipient sees a regular email with no indication that an interactive version existed.
How do I get approved to send AMP emails?
Submit a single sender registration form that covers Gmail, Yahoo Mail, and Mail.ru, along with a real production email containing the AMP MIME part. Your domain needs aligned SPF, DKIM, and DMARC and a compliant HTML fallback before registration is considered. Each provider evaluates and notifies you separately, so approval is not immediate.
Can I test an AMP email before sending it?
Email testing tools like Litmus and Email on Acid can render a preview of the AMP markup, but previews are static; you cannot interact with live components like accordions or forms inside them. Full functional testing requires sending to real Gmail, Yahoo Mail, or Mail.ru accounts on an approved sending domain.
Is AMP for email still worth building in 2026?
For most teams, only for specific, high-value sends, not as a default format. Support is limited to a handful of webmail providers, ESP tooling support is inconsistent, and the format has drawn public skepticism from working email professionals. It earns its cost for narrow use cases like inline surveys or recurring pricing updates where the audience is known to sit on a supported client.
Do I need to rebuild my whole email pipeline to add AMP?
No. AMP adds one MIME part to a message that already needs text/html and text/plain parts. If your current sending setup already produces a proper multipart message, the change is additive: one more branch to build, test, and keep synchronized with the fallback version, not a replacement for your existing pipeline.
I’ve spent my career building software at scale with a soft spot for email: deliverability, lifecycle campaigns, and getting messages to actually land. I started Coldletter to fix what bugged me about transactional and marketing email tools. I’m based in Vancouver.