AMP for Email: What It Is and How to Use It
AMP for email turns a static message into an interactive web app inside the inbox, letting subscribers submit forms, browse carousels, and update data without leaving Gmail. Support is limited to Gmail, Yahoo, and Mail.ru, so fallback HTML still matters.
AMP for email is an open spec from Google that lets you send interactive, dynamic messages (forms, carousels, live inventory) that render inside supported inboxes. Subscribers can RSVP, submit a review, or browse products without clicking through to a website. Support is narrow: Gmail, Yahoo, and Mail.ru only.
The format debuted in March 2019, when Google launched dynamic email in Gmail on the AMP for Email spec. Seven years later it's still a niche move, and I'd argue that's the correct outcome rather than a marketing failure; the build cost is real, and the payoff concentrates in a handful of use cases. The spec is still maintained and all three supporting providers still honor it, so niche is not the same thing as dead.
What AMP for email actually is
AMP for email is a subset of the AMP framework adapted for inbox rendering. It's a MIME part you bolt onto a regular email; mailbox providers that support it render the AMP version, everyone else falls back to standard HTML. The spec lives with the AMP Project on GitHub.
Think of it as a tiny sandboxed web app inside a message. You don't get arbitrary JavaScript; Google blocks that outright for security. You get a set of pre-approved components (amp-form, amp-list, amp-carousel, amp-bind, amp-selector, and a handful more) that buy you interactivity without exposing the recipient to XSS risk.
A regular HTML email is a snapshot of data at send time. An AMP email can call a live endpoint every time the reader opens it, so the product list, flight status, or calendar slot is current. That's the actual unlock; everything else is decoration. The AMP email glossary entry has the one-paragraph definition if that's all you needed.
What you can build with it
The allowed components cover most of what a real product page needs. Patterns that show up in production:
- RSVP confirmation inside the invite itself, with the response written straight back to a calendar API. If you're writing the copy around it, the event invite swipe file has the surrounding structure.
- Product carousel pulled from an
amp-listendpoint, so prices reflect the live catalog rather than what the catalog said at send time. - Embedded review form that posts to your reviews platform on submit.
- Flight or hotel status blocks that re-fetch on open.
- Accordion FAQs, so a long product-education email collapses into a scannable index.
- Single-question survey with radio buttons and a submit button; no landing page required.
Really Good Emails keeps a gallery of AMP examples if you want to see what senders actually ship.
The practical ceiling is lower than the spec suggests. amp-list fetches are rate-limited, and every third-party endpoint your email touches has to be CORS-configured for email origins. Forms and lists work well; anything needing complex state will frustrate whoever builds it.
Which mailbox providers support AMP
Three, as of April 2026: Gmail, Yahoo Mail, and Mail.ru. Apple Mail, Outlook (desktop, web, and mobile), Fastmail, ProtonMail, and everything else renders the HTML fallback. Whether that leaves you addressing most of your list or a sliver of it depends entirely on audience composition; consumer lists skew Gmail, and US B2B lists skew Outlook and Apple Mail hard.
| Mailbox provider | AMP support | Fallback behavior |
|---|---|---|
| Gmail (web, Android, iOS app) | Yes, since March 2019 | Renders HTML if sender isn't whitelisted or AMP MIME is missing |
| Yahoo Mail | Yes, since 2020 | Renders HTML fallback in unsupported clients and apps |
| Mail.ru | Yes, since 2019 | Renders HTML fallback |
| Apple Mail (macOS, iOS, iPadOS) | No | Always renders HTML part |
| Outlook (all versions) | No | Always renders HTML part |
| Fastmail, ProtonMail, Hey, others | No | Always renders HTML part |
Source: Google Developers AMP for Email docs, Yahoo's AMP support page, and Mail.ru's AMP implementation guide.
Gmail also retires the AMP version after 30 days; the message rolls back to its HTML snapshot. Don't design a workflow that assumes a 90-day-old email is still interactive.
Building the message
You send one message with three MIME parts: plain text, HTML, and text/x-amp-html. Mailbox providers pick the richest part they understand. If the AMP part fails validation, Gmail falls back to HTML silently; the recipient never sees a broken render, but they don't see your interactive version either.
Here's a minimal AMP body (the text/x-amp-html part). Every AMP email must declare the doctype, load the AMP runtime, and pass the official AMP validator:
<!doctype html>
<html ⚡4email data-css-strict>
<head>
<meta charset="utf-8">
<script async src="https://cdn.ampproject.org/v0.js"></script>
<script async custom-element="amp-form"
src="https://cdn.ampproject.org/v0/amp-form-0.1.js"></script>
<style amp4email-boilerplate>body{visibility:hidden}</style>
<style amp-custom>
.card { padding: 16px; border: 1px solid #eee; border-radius: 8px; }
button { background: #0b5fff; color: #fff; padding: 10px 14px; border: 0; }
</style>
</head>
<body>
<div class="card">
<h2>Can you join us Thursday?</h2>
<form method="post"
action-xhr="https://yourdomain.com/rsvp"
target="_top">
<input type="hidden" name="eventId" value="evt_842">
<button name="rsvp" value="yes" type="submit">Yes, I'll be there</button>
<button name="rsvp" value="no" type="submit">Can't make it</button>
<div submit-success><template type="amp-mustache">Thanks, saved!</template></div>
<div submit-error><template type="amp-mustache">Something broke, try again.</template></div>
</form>
</div>
</body>
</html>
The MIME wrapper looks roughly like this, simplified:
Content-Type: multipart/alternative; boundary="boundary42"
--boundary42
Content-Type: text/plain; charset="UTF-8"
[plain-text body]
--boundary42
Content-Type: text/html; charset="UTF-8"
[HTML fallback body]
--boundary42
Content-Type: text/x-amp-html; charset="UTF-8"
[AMP body from above]
--boundary42--
If you send through Mailneo, the AMP email validator pre-flights that part against the spec, so missing boilerplate, disallowed tags, and CORS problems surface before the send rather than after it.
Every action-xhr endpoint your form hits has to return two headers: AMP-Access-Control-Allow-Source-Origin matching the sender domain, and Access-Control-Expose-Headers: AMP-Access-Control-Allow-Source-Origin. Email on Acid's AMP guide has a complete header cheat-sheet; budget half a day if your backend team hasn't done CORS for email origins before.
Getting whitelisted as an AMP sender
You register with each provider separately, and Gmail's process is the strictest of the three. For Gmail:
- Get SPF, DKIM, and DMARC in place on the sending domain, with DMARC at
p=quarantineor stricter. The email deliverability guide covers those DNS records if they aren't done yet. - Send a fully-formed AMP test message from your production sending domain to
ampforemail.whitelisting@gmail.com. The AMP part has to pass the validator on the first try. - Fill in Google's AMP sender registration form, linking your privacy policy and sample campaigns.
- Wait five to ten business days for review. Rejections usually point at DMARC alignment or invalid AMP markup.
Yahoo wants an email to amp-for-email@yahoo.com with sample campaigns and volume figures; Mail.ru runs an online registration form with a similar turnaround.
Whitelisting is per-domain, not per-IP. If you send from marketing.acme.com and transactional.acme.com, each needs its own approval; forgetting that is a common reason an AMP campaign renders beautifully in QA and falls back for production traffic.
The trade-offs nobody puts in the demo
Message size grows. AMP adds another MIME part, typically tens of kilobytes of markup plus boilerplate, and Gmail clips messages over 102 KB (Google's documentation). If your HTML fallback is already heavy, you can cross the clip threshold the moment you attach AMP.
Accessibility usually gets worse, not better. amp-carousel and amp-selector don't reliably announce state changes to screen readers. Test with VoiceOver and NVDA before shipping an AMP-heavy template to a broad list, because the fallback HTML often has better a11y than the AMP version replacing it.
Engineering friction is the thing that actually kills these programs. Every campaign with a new interactive component needs a new endpoint, CORS setup, and a validator pass; "design and send" becomes "design, build the backend, deploy, whitelist the origin, send, monitor errors." I've watched teams pilot AMP on one flagship campaign, ship it, and then quietly never do it again, because the per-campaign engineering cost never penciled out.
Measurement gets murkier too. Standard pixel tracking doesn't behave inside the AMP part the way it does in HTML, and amp-analytics isn't supported by every ESP. If you want an honest read on whether the interactive version moved anything, instrument it separately and compare conversion rate against a matched HTML control rather than trusting a single dashboard.
AMP earns its cost on transactions, not broadcasts
AMP pays back when the interaction you're embedding would otherwise require a landing-page round trip most recipients will skip: RSVPs, review submissions, meeting confirmations, single-question surveys. It doesn't pay back on content-heavy marketing email where the interactive element is ornament.
Three questions before greenlighting a build:
- Does your audience skew Gmail? Consumer lists usually do. A Fortune-500 B2B list usually doesn't, and AMP will reach a small minority of it.
- Is the interaction worth a quarter of engineering time? Wiring CORS, whitelisting, and fallback testing is a month-long project, not a week-long one.
- Can the fallback carry the email by itself? If the HTML version is weaker, a chunk of your list gets the worse experience by default. Design AMP as an enhancement, never as the only path.
For most senders the honest starting point is transactional mail. Google's own case studies lean on Booking.com, Doordash, and Pinterest, and all three used AMP for transactional or confirmational flows rather than broadcast marketing.
If AMP feels like overkill for what you're trying to do, interactive HTML email built on CSS checkboxes and accordions covers a good share of the same ground at a fraction of the cost. Start there, and upgrade to AMP only when the interaction genuinely needs live data or a form POST.
Explore: Email Design & Content
Related Articles
Email Plain Text vs HTML: The 2026 Decision Guide
Plain text and HTML email each work in different contexts. This guide compares deliverability, engagement, tracking, accessibility, branding, and AI spam-filter behavior so teams can choose the right format for each campaign.
HTML Email Basics: Examples, Structure, and Testing
HTML email is an email built with markup, inline styles, and layout patterns that email clients can render. It is not the same as a web page. Tables, fallbacks, accessibility, image handling, and client testing matter more than modern CSS tricks.
Best Fonts for Emails: Practical Guide for Marketers
The best fonts for emails are readable, widely supported, brand-appropriate, and tested across inboxes. Use safe font stacks first, size body copy at 16px or more, reserve custom fonts for supported clients, and validate accessibility before sending campaigns.
Mailto Link HTML Guide: Syntax, Examples, and Pitfalls
A mailto link opens the user's email client with a prefilled recipient, subject, body, cc, or bcc field. It is useful for simple contact actions, but it is not a form replacement. This guide shows the exact HTML syntax, encoding rules, and mistakes to avoid.
Ready to supercharge your email marketing?
Start sending smarter emails with AI-powered campaigns. No credit card required.
Get Started Free