AMP for Email: What It Is and How to Use It

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 using the AMP for Email spec (amp.dev). Seven years in, adoption is still a niche move; Litmus's 2023 State of Email research put AMP usage at roughly 2% of tracked senders. The reason is effort; the reason to care is the lift when it lands in the right mailbox.

Table of contents

What is AMP for email?

AMP for email is a subset of the AMP framework (the same one behind AMP web pages) adapted for inbox rendering. It's a MIME part you add to a regular email; mailbox providers that support it render the AMP version, and everyone else falls back to standard HTML. The spec is maintained by the AMP Project on GitHub.

The short version; it's a way to ship a tiny, sandboxed web app inside an email. You don't get arbitrary JavaScript (Google blocks that for security); you get a set of pre-approved AMP components (amp-form, amp-list, amp-carousel, amp-bind, amp-selector, plus a handful more) that give 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 user opens it, so the product list, flight status, or calendar slot is current. That's the actual unlock here.

What can AMP for email actually do?

Plenty, if you accept the constraints. The allowed components cover most of what a real product page needs: forms that POST to your server, carousels for product browsing, accordions for FAQs, and bound state for simple interactivity.

Concrete patterns I've seen shipped in production:

• RSVP confirmation inside the invite email (one-click accept, dates sync back to a Google Calendar API).
• Product carousel pulled from a amp-list endpoint so prices reflect the live catalog, not what the catalog said at send time.
• Embedded review form that writes to Trustpilot or Yotpo when the user submits.
• Flight or hotel status blocks that re-fetch on open (Booking.com and Doordash both shipped public case studies on this in 2019–2021).
• Accordion FAQs so a long product education email collapses into a scannable index.
• Survey with radio buttons and a submit button, no external landing page required.

Really Good Emails keeps a gallery of AMP examples if you want to see what real senders ship, from Pinterest's board previews to Ecwid's cart-abandon carousel.

[MY EXPERIENCE: an AMP email use case you shipped — the interaction that mattered and what lift it drove]

The practical ceiling is lower than the spec suggests. amp-list fetches are rate-limited, you can't run arbitrary JS, and every third-party endpoint your email hits has to be CORS-configured for email origins (more on that below). The components that work well are forms and lists; the components that frustrate teams are anything needing complex state.

Which mailbox providers support AMP emails?

Three, as of April 2026: Gmail, Yahoo Mail, and Mail.ru. Apple Mail, Outlook (desktop, web, and mobile), Fastmail, ProtonMail, and every other major client render the HTML fallback. That's a meaningful chunk of your list; US B2B inboxes skew heavily Outlook/Apple, so the AMP version may reach 30–60% of a typical list depending on audience composition.

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 AMP support page, and Mail.ru's AMP implementation guide.

Gmail also hides the AMP version after 30 days (the message rolls back to its HTML snapshot), so don't design workflows that assume a 90-day-old email will still be interactive. Litmus's 2023 AMP deep dive called this one of the most-missed gotchas in the spec.

How do you build an AMP email?

You send a single 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 also don't see your interactive version.

Here's a minimal AMP email body (the text/x-amp-html part). Every AMP email must declare the doctype, include 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, our AMP email validator tool pre-flights the AMP part against the spec so you catch missing boilerplate, disallowed tags, or CORS issues before you send; it runs the same checks as the AMP Project validator but formats the errors for non-developers.

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 to wire this up if your backend team hasn't done CORS for email origins before.

How do you get whitelisted to send AMP emails?

You register as an AMP sender with each mailbox provider. Gmail's process is the strictest; Yahoo and Mail.ru are lighter but still require approval.

For Gmail, the flow runs roughly like this:

1. Set up SPF, DKIM, and DMARC on the sending domain (DMARC must be p=quarantine or p=reject). If you haven't done this yet, our email deliverability guide walks through the DNS records.
2. Send a fully-formed AMP test email from your production sending domain to ampforemail.whitelisting@gmail.com. The AMP part has to pass the validator on first send.
3. Fill in Google's AMP sender registration form, linking to your privacy policy and sample campaigns.
4. Wait five to ten business days for Google's review. Rejections usually point to DMARC alignment issues or invalid AMP markup.

For Yahoo, you email amp-for-email@yahoo.com with sample campaigns and sender volume; they reply in three to seven business days. Mail.ru has an online registration form with a similar turnaround.

Whitelisting is per-domain, not per-IP, so if you send from multiple subdomains (marketing.acme.com, transactional.acme.com), each needs its own approval. That's easy to forget and a common reason an AMP campaign renders fine in QA but falls back for production traffic.

What are the deliverability and design trade-offs?

This is where teams usually discover that AMP costs more than the demo suggested. A few honest downsides:

Increased message size; AMP adds another MIME part, typically 15–40 KB of markup plus boilerplate. Gmail already clips messages over 102 KB (Google's own documentation confirms this), so you're eating into your HTML budget. If your HTML fallback is already 80 KB, you're probably over the clip threshold once you add AMP.

Accessibility gaps; amp-carousel and amp-selector don't always announce state changes cleanly in 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 that replaces it.

Engineering friction; every campaign with a new interactive component needs a new endpoint, CORS setup, and validator pass. What used to be "design and send" becomes "design, implement backend, deploy, whitelist origin, send, monitor errors." I've seen teams pilot AMP for one flagship campaign, ship it, then quietly never do it again because the engineering cost per campaign didn't pencil out.

Analytics blind spots; you can't use standard pixel tracking inside the AMP part the same way you do in HTML. amp-analytics exists but isn't supported by every ESP, and Apple Mail Privacy Protection already pre-loads images on the HTML side, which muddies open-rate comparisons.

[ORIGINAL DATA: percentage of Mailneo customers using AMP and observed engagement differences]

Litmus's 2023 research found that marketers who shipped AMP campaigns reported click-to-conversion lifts of 20–500% versus their HTML fallback, but they also reported 3–4x the build time. The spread on that number is wide because use case matters; one-click RSVPs and embedded surveys convert much better than embedded carousels.

Is AMP for email worth the engineering effort?

Depends on the use case and the audience. AMP pays back when the interaction you're embedding would otherwise require a landing-page round-trip that most recipients will skip (RSVPs, review submissions, meeting confirmations, single-question surveys). It doesn't pay back for content-heavy marketing emails where the interactive element is decoration.

Three questions I'd ask before greenlighting an AMP build:

1. Does your audience skew Gmail? If you're B2C with a consumer list, probably yes. If you're B2B with a Fortune-500 list that lives in Outlook, AMP reaches maybe 15% of readers.
2. Is the interaction worth an engineering quarter? Wiring CORS, whitelisting, and fallback testing is a one-month project, not a one-week project.
3. Can the fallback carry the email on its own? If the HTML version is weaker than the AMP version, half your list gets a worse experience. Design AMP as enhancement, never as the only path.

For most senders, the honest answer is "start with transactional." Google's own case studies on the AMP site lean heavily on Booking.com, Doordash, and Pinterest. All three used AMP for transactional or confirmational flows, not broadcast marketing.

If AMP feels like overkill for what you're trying to do, interactive HTML email using CSS checkboxes and accordions covers 70% of the same use cases with 20% of the engineering. Start there; upgrade to AMP only when the interaction genuinely requires live data or a form POST.

[SCREENSHOT: Mailneo or a compliant ESP previewing both the AMP and fallback HTML rendering of the same message side by side]

Key takeaways

• AMP for email is a MIME part (text/x-amp-html) added alongside plain text and HTML; supporting clients render AMP, everyone else falls back to HTML.
• Only Gmail, Yahoo Mail, and Mail.ru support AMP as of 2026; Apple Mail and every Outlook version fall back to HTML.
• Gmail whitelisting requires DMARC at p=quarantine or stricter, a validated test email to ampforemail.whitelisting@gmail.com, and a registration form review of five to ten business days.
• Litmus's 2023 research found AMP campaigns drive 20–500% conversion lift versus HTML, with 3–4x the build time per campaign.
• AMP pays back on one-click RSVPs, embedded forms, and live-data blocks; it rarely pays back on broadcast marketing emails.
• You can't run arbitrary JavaScript in AMP email; you get a fixed set of components like amp-form, amp-list, amp-carousel, and amp-bind.

Frequently asked questions

Does AMP for email work in Apple Mail or Outlook?

No. Apple Mail, Outlook (desktop, web, Microsoft 365, and mobile), Fastmail, ProtonMail, and Hey all render the HTML fallback. Only Gmail, Yahoo Mail, and Mail.ru render the AMP part, per Google's developer docs.

How long does Gmail AMP whitelisting take?

Typically five to ten business days after you submit the registration form, assuming your first test email to ampforemail.whitelisting@gmail.com passes the validator. Rejections usually point to DMARC alignment or invalid AMP markup.

Can I track clicks inside an AMP email?

Partially. You can use amp-analytics to ping an analytics endpoint on component events, but standard pixel tracking and most ESP link-wrapping behaves differently in AMP than HTML. Expect to instrument AMP campaigns separately from your HTML baseline.

Is AMP for email dead?

Adoption is slow but the spec is still actively maintained; Google shipped updates to amp-email-format through 2025, and Yahoo relaunched its AMP support page in 2024. It's niche, not deprecated.

Do I need AMP for email as an AI email platform user?

Not for most campaigns. AI-generated personalization already works in standard HTML; AI email marketing and AMP solve different problems. Use AMP when live data or in-inbox forms are the goal, not when the goal is better copy.

Related resources

• AMP email validator tool
• AMP email glossary entry
• HTML email glossary entry
• Email templates that convert: design patterns that work
• Email deliverability guide: SPF, DKIM, DMARC, and BIMI
• What is AI email marketing, and how does it compare?