Key takeaway
An AMP email is a third MIME part: the message carries plain text, HTML, and an AMP document, and a client that understands the third renders an interactive version of it. Support sits at 16.28% of tracked clients, with Apple Mail and every Outlook outside that number. I build the HTML version as the email and treat AMP as the enhancement, because a part that expires 30 days after receipt and dies on forward can't be the one carrying the message.
What an AMP email actually is.
An AMP email is a third MIME part. The message you send carries a plain-text part, an HTML part, and a text/x-amp-html part holding an AMP document, all inside one multipart/alternative container, and a client that understands the third one renders it in place of the static version. Forms submit, lists refresh, and carousels swipe without the reader leaving the inbox.
It isn't a new kind of email. It's an enhancement layer on a message you're already sending, which means the interesting question was never what AMP can do. It's what happens to the reader who doesn't get it, and that reader is most of your list. Can I email's support matrix puts AMP for Email at 16.28% of the clients it tracks, and the ones on the wrong side of that number include Apple Mail and every version of Outlook.
So the HTML part isn't a safety net you hope never fires. It's the version most people open.
A complete AMP email you can paste.
An AMP document has five required pieces, and they're all in the sample below: the doctype, an <html amp4email> root, <meta charset="utf-8"> as the first tag in the head, the v0 runtime script, and the amp4email-boilerplate style that hides the body until the runtime has it ready. Anything past plain markup needs its own component script in the head, which is what the second script tag here is doing.
This one validates and it does something. It renders a heading and a two-section accordion, so a reader can open the part of a long message they care about and skip the rest. There's no arbitrary JavaScript in an AMP email and there can't be, so every behaviour on the page comes from a component the runtime already knows about.
All of your CSS lives in that single amp-custom block or in inline style attributes on the elements themselves. External stylesheets are out, and the boilerplate style isn't something to edit or reorder. Keep <meta charset="utf-8"> first in the head, because the validator requires it as the head's first child. The runtime script and the boilerplate style both have to sit in the head, and the order they take relative to each other is yours.
<!doctype html>
<html amp4email>
<head>
<meta charset="utf-8">
<script async src="https://cdn.ampproject.org/v0.js"></script>
<script async custom-element="amp-accordion"
src="https://cdn.ampproject.org/v0/amp-accordion-0.1.js"></script>
<style amp4email-boilerplate>body{visibility:hidden}</style>
<style amp-custom>
body { font-family: system-ui, sans-serif; margin: 0; padding: 16px; }
h1 { font-size: 20px; margin: 0 0 12px; }
section h4 { margin: 0; padding: 10px 0; }
</style>
</head>
<body>
<h1>Your order is on its way</h1>
<amp-accordion animate>
<section expanded>
<h4>What is in the box</h4>
<p>One kettle, one filter, one bag of beans.</p>
</section>
<section>
<h4>Where it is going</h4>
<p>12 Nationale, Lille, arriving Thursday.</p>
</section>
</amp-accordion>
</body>
</html>
Two hard limits sit around that, plus a recommendation. The spec sets a 200,000-byte document limit and 50,000 bytes for the style tag, and recommends a width of 800px or less. Both ceilings are generous for an accordion and tight for anything assembled out of a template library, so measure the output before you design against it rather than after.
The components you actually get.
The email format is a conservative subset of AMP rather than all of it. Six families cover almost everything worth building, and the restrictions they carry tell you what the format is for.
- amp-form: posts to an
action-xhrendpoint, and a redirect after submission isn't allowed. - amp-list: fetches JSON when the message is opened and renders it through
amp-mustache. - amp-bind and amp-state: expressions and stored state, with binding to
[href]or[src]prohibited. - amp-accordion: collapsible sections, which is the cheapest way to make a long message short.
- amp-carousel: a swipeable row, alongside
amp-selector,amp-fit-text,amp-sidebar, andamp-timeago. - amp-img and amp-anim: images and animated GIFs, again with no binding on
[src].
Two things aren't on that list and are worth noticing. There's no component for tracking, and there's no component for navigation that the reader controls after the fact. Read the prohibitions and you've got the shape of the whole thing. Nothing may change where the reader ends up, and nothing may load a resource the sender didn't name before the message left. That's why the supported component list is short, and why it stays short.
Four examples worth building.
Four shapes pay for themselves, and each one removes a click through to a page the reader was never going to load. I'd build none of them before the HTML version is right, because 16.28% support means the enhancement is the minority experience by a wide margin.
A survey answered in the inbox. An amp-form with an amp-selector for the options, submitted straight out of the message. The version everybody already sends is a row of star buttons linking to a form, and the drop-off happens between the click and the page. Take the page away and the drop-off goes with it.
Appointment or slot booking. amp-list fetches the free times when the message is opened, and amp-form books one. This is the case where interactive is genuinely better rather than merely faster: a static email shows the slots that were free when it was sent, which by the time anyone reads it is fiction.
Live order or delivery status. One amp-list pointed at your fulfilment endpoint, so a two-week-old shipping confirmation still shows where the parcel is today. It also removes the support ticket the stale version generates, which is usually the bigger saving of the two and the easier one to put a number on.
A product picker on an abandoned cart. amp-carousel for the items and amp-bind for the selection, in place of a static hero image and a link. The reader chooses the size in the message and lands on the checkout with it already chosen. Of the four, this one needs the most care, because the cart it describes can empty or reprice between the send and the open, and the AMP version has to handle that gracefully rather than book a phantom.
All four are yours to design, and none of them is what a send does. What the message owes them is an endpoint that's authenticated, reachable, and answering the request the AMP part makes, because a form posting into nothing is worse than the static version it replaced. Every shape here assumes a fulfilment endpoint, a catalogue, and a cart you already run.
Who renders it, and who quietly doesn't.
Support is the first thing to check and the last thing a gallery of screenshots mentions. The tracked-client matrix behind that 16.28% splits two ways.
- Renders it: Gmail on desktop webmail, iOS and Android, Yahoo Mail on desktop webmail, iOS and Android, and Mail.ru on desktop webmail.
- Doesn't: Apple Mail on macOS and iOS, every Outlook platform, Thunderbird, ProtonMail, Fastmail, HEY, AOL, Gmail's own mobile webmail, and the European webmail providers including Orange, SFR, Free.fr, GMX, and web.de.
Two entries on that second line are the ones that catch people out. Outlook doesn't render AMP on any platform, so a B2B list sits almost entirely outside the format. ProtonMail, Fastmail, and HEY don't render it either, which removes a slice of the developer audience a technical newsletter is usually aimed at.
The practical reading is that AMP for Email is a Gmail feature with a handful of other webmail clients attached. If your list skews consumer and Gmail-heavy, the enhancement reaches a real share of it. If it skews corporate, you're building for a minority of a minority, and the honest answer is usually to spend the same week on the HTML version instead.
How to send one: registration and authentication.
Five things have to be true before Gmail will render your AMP part, and they happen in this order.
- Build the MIME tree. One
multipart/alternativecarryingtext/plain, thentext/x-amp-html, thentext/html. The spec recommends placing the AMP part before the HTML part, because some clients render only the last one. - Get SPF and DKIM passing, with the DKIM signing domain aligned to your
Fromaddress on DMARC's relaxed model. A DMARC policy at quarantine or reject is recommended. - Send over TLS. An unencrypted connection fails the check on its own, whatever else is in place.
- Test before you register. In Gmail that's Settings, then General, then Dynamic email, then Developer settings, where you allowlist your own sending address and the playground's.
- Register. Send a production copy of the message to Google's AMP whitelisting address, submit the registration form, and wait: Google aims to respond within 5 business days.
None of that removes the HTML part. A message with an AMP part and no fallback isn't a valid AMP email, and the fallback is what every unsupported client, every forwarded copy, and every message older than a month falls back to. Build the static version first and treat the AMP part as something added to a message that already works.
Then comes the part that actually breaks builds. Every endpoint your document calls has to set an AMP-Email-Allow-Sender header, proxied requests arrive carrying no cookies, and a 3XX response fails outright. An endpoint that authenticates on a session cookie works in the playground, where you're signed in, and fails in the message, where you aren't. Sign the request or carry a token in the URL you send.
That sequence isn't a checklist somebody walks once. It's state: MIME order, DKIM alignment, TLS, the allowlist, the registration, and the sender header all have to be true again for the eleventh sending address exactly as they were for the first, and true again for every endpoint the document calls. The question a build has to answer isn't whether you can get one address through the sequence. It's what holds that state and re-applies it, so address eleven costs a minute rather than a morning.
What AMP can't carry, and what to send instead.
Four facts change whether the build is worth starting.
- It expires: Gmail shows the fallback when the client is offline, or 30 or more days after receipt. A month-old AMP email is an HTML email.
- AMP's own analytics don't work:
amp-analytics,amp-pixel,CLIENT_ID, and AMP variable substitution are all unsupported in the email format, so the AMP part is instrumented with the same tracking pixel an HTML email uses and nothing finer. - Registration is per sending address: each address registers separately, the domain has to serve a real site rather than a parked one, and letting third parties author and send is barred.
- It doesn't survive a forward: the client strips the
text/x-amp-htmlpart on reply or forward, so the copy that circulates an office is the static one.
The HTML part is the email. AMP is an enhancement that a minority of clients render, that stops rendering after a month, that AMP's own analytics components can't instrument, and that vanishes the second anyone passes it on. Build it where the interaction genuinely beats a click through to a page, which is the booking and the status cases above, and skip it everywhere else.
An AMP send is plumbing: the endpoints, catalogue, and cart stay yours, and our side is getting that message authenticated and out. Outlook now wants SPF, DKIM and DMARC aligned at p=quarantine or stronger before it trusts bulk sends. Nitrosend is an AI-native email platform, not a dashboard with an AI button bolted on: authentication and the send itself are agent commands, with BYO sending keys on Pro and above. Get the HTML version right on the free tier, then decide about the third part.
Sources
- AMP for Email format specification: the required markup, the 200,000-byte document limit, the 50,000-byte style limit, the 800px recommended width, and the ban on
amp-analytics,amp-pixel, andCLIENT_ID. - AMP for Email structure: the
multipart/alternativeMIME tree, the recommendation to place the AMP part before the HTML part, and the stripping of the AMP part on reply or forward. - Supported components in AMP for Email: the dynamic, layout, and media component lists, the ban on redirecting after an
amp-formsubmission, and the prohibition on binding to[href]or[src]. - Google, Register for dynamic email: the production send to the whitelisting address, the 5 business day response target, per-sender-address registration, the requirement that the domain serve a real site, and the bar on third-party authoring.
- Google, Dynamic email security requirements: SPF and DKIM passing with relaxed DMARC alignment to
From, DMARC at quarantine or reject, TLS, theAMP-Email-Allow-Senderheader, cookie stripping on proxied requests, and the failure of 3XX responses. - Google, Test dynamic email: the developer settings allowlist in Gmail, and the fallback shown when the client is offline or 30 or more days after receipt.
- Can I email, AMP for Email: the 16.28% support figure across tracked clients, and the client-by-client split behind it.
Common questions
It's an ordinary email carrying an extra MIME part. The message holds a plain-text part, an HTML part, and a <code>text/x-amp-html</code> part containing an AMP document, and a client that understands the third one renders an interactive version: forms, live data, carousels, and accordions inside the inbox. Every other client renders the HTML part instead.
Can I email's support matrix puts it at 16.28% of the clients it tracks. On the supported side: Gmail on desktop webmail, iOS and Android, Yahoo Mail on desktop webmail, iOS and Android, and Mail.ru on desktop webmail. Not supported: Apple Mail on macOS and iOS, every Outlook platform, Thunderbird, ProtonMail, Fastmail, HEY, AOL, and Gmail's own mobile webmail.
Start with <code><!doctype html></code> and an <code><html amp4email></code> root. The head needs <code><meta charset="utf-8"></code> first, then the v0 runtime script, then the <code>amp4email-boilerplate</code> style, then a component script for anything past plain markup. All your CSS goes in one <code>amp-custom</code> block, and the document has to stay under 200,000 bytes.
Yes, for Gmail. You send a production copy of the message to Google's AMP whitelisting address, submit the registration form, and wait: Google aims to respond within 5 business days. Registration works per sending email address, so a second address means a second application, and the sending domain has to serve a real website.
It does. Gmail falls back to the HTML part when the client is offline, and again 30 or more days after the message was received. So an AMP email is interactive for a month and static after that, which matters most for the messages people keep, like receipts, bookings, and shipping confirmations.
The client strips the <code>text/x-amp-html</code> part on reply and on forward, so the copy that gets passed around is the HTML one. That's worth planning for on anything a reader is likely to send to a colleague, because the forwarded version has to carry the full message on its own.
No. <code>amp-analytics</code>, <code>amp-pixel</code>, <code>CLIENT_ID</code>, and AMP variable substitution are all unsupported in the email format, so there's no tracking pixel and no measurement layer inside the AMP document. What you can instrument is your own <code>action-xhr</code> endpoint, which sees every form submission and every data fetch.
Yes, and it's the version most of your list will read. An AMP part with no non-AMP fallback in the same <code>multipart/alternative</code> tree isn't a valid AMP email, and the fallback is what unsupported clients, forwarded copies, and month-old messages all display. Build the HTML version first and add the AMP part to a message that already works.