Jul 02, 2026 · 8 min read
AMP for Email Tracking Explained (And How to Stop It)
A live product carousel inside an email looks like a convenience. It is also a server call that fires every time you open, reopen, or scroll the message.
AMP for email tracking works differently than the tracking pixel you already know about. A normal spy pixel fires once, when you open a message, and goes quiet. AMP for email, also called dynamic email or amp4email, embeds a live app inside the message itself, one that reaches back out to the sender's server every time the email renders, whether that is the first open, the fifth reread, or a scroll three weeks later. Gmail, Yahoo Mail, and Mail.ru all render these live components today, so a meaningful slice of the email you get in 2026 is not a static document. It is a small client application phoning home on a schedule you do not control.
Here is what AMP for email actually does under the hood, why it produces a more persistent tracking signal than a pixel, and what you can turn off today.
Key Takeaways
- AMP for email, built on the amp4email specification, embeds a live app fragment in a message using a text/x-amp-html MIME part sent alongside the normal HTML and plain text versions.
- Components like amp-list pull fresh content from the sender's server every time the email is opened or scrolled into view, generating a new server request on each rendering rather than a single pixel fire.
- Only Gmail, Yahoo Mail, and Mail.ru render the AMP part in 2026, and senders must register each sending address individually with Google before their AMP emails are displayed to recipients.
- Google's amp4email spec explicitly blocks the amp-pixel and amp-analytics components and strips cookies from proxied requests, but any user initiated data fetch still tells the sender the message was actively viewed.
- Gmail's "Enable dynamic email" toggle in Settings turns AMP rendering off entirely, and pairing that with a tracking pixel blocker like Gblock covers both the live component channel and the older static pixel channel.
What Is AMP for Email?
AMP for email is a format that lets a sender embed interactive, app like components inside a message: image carousels, live product listings, RSVP forms, and comment threads that update without you leaving your inbox. It is built on the AMP HTML framework Google originally shipped for fast mobile web pages, adapted into an email specific subset documented at amp.dev.
Every AMP email is actually three emails stitched into one MIME message: a text/plain part, a text/html part, and a text/x-amp-html part. Clients that support dynamic email render the amp4email part; every other client, including Outlook, Apple Mail, Proton Mail, and Fastmail, falls back to the plain HTML version and never knows the AMP content existed. A minimum viable AMP part requires the <html amp4email> root tag, a boilerplate style block, and the AMP runtime script, following the structural rules in the official AMP for Email format spec.
Before any of that renders for a real recipient, the sending address has to be individually approved. Google requires SPF, DKIM, and DMARC to all pass, with DMARC set to a quarantine or reject policy, then requires the sender to email a live, production quality AMP message to Google's whitelisting address for manual review, per amp.dev's sender registration documentation. Each address must be registered separately, and Yahoo and Mail.ru run their own approval processes on top of Google's.
How Does AMP for Email Enable Real Time Tracking?
AMP for email enables real time tracking because its interactive components fetch live data from the sender's own server every time the message is displayed, not just once at first open. The component doing most of that work is amp-list, which pulls JSON from a CORS endpoint the sender controls and renders it into the message using a template. A product email showing current stock and pricing, or a flight status card that updates automatically, is running amp-list under the hood, and each render is a fresh outbound request.
A conventional tracking pixel is a single 1x1 image request that fires once, typically on first open, then goes quiet unless the recipient forwards the email or reloads images. A dynamic email component does not go quiet. Reopen the message next week to check a detail, and the amp-list block can fire another request for fresh content. Scroll a carousel back into view and it can trigger another fetch. Each request is functionally an open and engagement signal, arriving on a schedule set by how often the recipient revisits the message rather than a single moment in time.
Google did build in real constraints. The amp4email format documentation explicitly excludes the amp-pixel and amp-analytics components, so the classic invisible tracking beacon has no direct equivalent inside AMP email. Requests are proxied through Google's or the client's infrastructure, and cookies are stripped from those proxied calls, limiting cross-site identity linking. None of that changes the core fact: a legitimate, user facing component like amp-list still tells the sender's server, in real time, that a specific message was opened or rendered again, and it can carry a unique identifier in the endpoint URL to tie that event back to one recipient. The tracking signal moved from a dedicated spy pixel into the plumbing of a feature the recipient actually wants, and it can outlive a blocked pixel entirely: if a mail client blocks remote images, the classic pixel never fires, but a live AMP content block is not an image, so an image blocking rule does nothing to stop its fetch.
Which Email Providers Support AMP in 2026?
Support for AMP for email in 2026 is still limited to three providers: Gmail, Yahoo Mail, and Mail.ru. Outlook, Apple Mail, Proton Mail, and Fastmail have never adopted the format, so every AMP campaign has to ship a complete static HTML fallback anyway, which is part of why adoption among marketers has stayed a niche practice nearly eight years after Gmail introduced it. If you read mail through Gmail's web interface or mobile app, AMP content can render for you. If you use Outlook, Apple Mail, or most third party clients, you only ever see the fallback HTML, which, as our guide on how Gmail proxies tracking pixels explains, may still carry a conventional tracking pixel even though it never renders a live amp4email component.
Why Email Users Should Care
This is not an abstract engineering detail, it changes what a sender can infer about your behavior. A marketing platform running amp-list product cards does not just learn that you opened a promotional email once. It can learn that you came back to it twice, when, and roughly how long the message stayed relevant enough to reread, a denser behavioral profile than a single open timestamp, built from a component most recipients assume is just a nicer looking email.
It also means Gmail tracking now needs two different defenses. Static tracking pixels, the kind covered in our guide on how tracking pixels work and how Gmail proxies them, are blocked by preventing the image request or routing it through a privacy respecting proxy. AMP components are a different code path entirely, rendered by the client rather than requested as an external image, so a pixel focused defense alone will not stop them. Anyone who has already set up click tracking protection in Gmail has solved for redirect links, not for a live component that fetches on every open. The distinction between open tracking and click tracking gets blurry here too: a live list fetch is effectively an open signal, while an embedded amp-form submission is a click and data event rolled into one, all without leaving Gmail.
How Do You Turn Off Dynamic Email in Gmail?
You turn off dynamic email in Gmail from the General tab in Settings. Open Gmail on the web, click the gear icon, choose "See all settings," scroll to "Dynamic email," and uncheck "Enable dynamic email," then save changes. According to Google's own support documentation, disabling dynamic email causes Gmail to render only the static HTML fallback for every message, so no amp4email part ever executes, no matter who sent it.
Enabling "Ask before displaying external images" also disables dynamic email automatically, since both settings govern whether Gmail auto loads remote content on your behalf. Google Workspace administrators have a parallel control at the organization level, under Admin console, Apps, Google Workspace, Gmail, User settings, Dynamic email, which disables AMP rendering for every user in the domain.
Turning off dynamic email is a real, effective step, but a blunt one. It also disables uses you might want, like RSVPing to a calendar invite from inside the inbox, and does nothing for the ordinary tracking pixel sitting in the fallback HTML part of every marketing email you receive, registered sender or not.
How Should You Actually Defend Against This?
The most complete approach layers two things: disabling dynamic email for the AMP channel, and blocking pixels for the static channel. Extensions built for Gmail privacy, including Ugly Email, PixelBlock, Trocker, and Gblock, focus primarily on the pixel problem, catching the invisible image request that fires when a marketing email opens. None of them intercept an amp4email component, because that content is not a remote image request, it is client side AMP markup rendered directly by Gmail itself.
That is why the two controls are complementary rather than redundant. Gblock runs inside Gmail and automatically blocks tracking pixels before they load, stripping the open and location signal out of every message without you having to think about which senders to trust. Pairing that with dynamic email turned off in Settings closes the AMP shaped gap, since that setting is the only lever that stops an amp-list block from fetching in the first place. Neither control alone gives you the full picture; together they cover both the request based tracking Gblock was built for and the render based tracking that AMP introduced. If you send email yourself, the same logic runs in reverse: every amp-list endpoint your campaigns call is a place where recipient behavior gets logged, and it deserves the same consent scrutiny as a tracking pixel vendor.