Interactive Email Elements: AMP, CSS, and What Works
What is actually supported where, the fallback that has to exist, and whether the effort returns anything measurable.
On this page
The short version
- Support is narrow and the failure is silent. Anything interactive needs a static fallback that delivers the whole message on its own.
- AMP for Email requires registration with each provider and a separate message part, which is real engineering work for a feature a minority of your list will see.
- The honest test is whether the interaction removes a step. A carousel that replaces a scroll does not; an in-email survey that replaces a landing page does.
Interactive email covers three quite different things: CSS-driven interactions that work by exploiting hover and checkbox states, AMP for Email, and simple animation. They have different support profiles and very different build costs.
All three share one requirement. The version a reader sees when the interaction does not work has to carry the whole message, because in every case the failure is silent — nothing tells the reader they are missing anything.
The three approaches
| Approach | How it works | Build cost | Reach |
|---|---|---|---|
| CSS interactions | Hover states, checkbox and radio tricks | Moderate, fiddly | A minority of clients |
| AMP for Email | A separate AMP part in the message | High, plus registration | A few major providers |
| Animation | Animated GIF | Low | Broad, with first-frame fallbacks |
The bottom row delivers most of the perceived benefit of the top two at a fraction of the cost, which is why most "interactive" commercial email is in fact a GIF.
What AMP actually requires
AMP for Email is a third message part alongside HTML and plain text. It allows genuinely dynamic content — live data, forms that submit from inside the message, content that updates when the email is reopened.
The requirements are substantial: you register as a sender with each participating provider, you pass their review, your messages must be authenticated, and you maintain an AMP version of any email that uses it alongside the HTML version that everyone else receives.
That is a real engineering commitment for a feature a minority of your list will see. It is justified where the interaction removes a whole step from a workflow — approving something, choosing a delivery slot, answering a survey — and hard to justify for presentation.
The test worth applying
Ask whether the interaction removes a step the reader would otherwise take. An in-email rating widget that saves a click through to a form does. A carousel that lets the reader page through four products instead of scrolling past four products does not — it replaces a scroll with a tap and hides three of the four from anyone whose client does not support it.
Applied honestly this rules out most of what gets built. That is the correct outcome: the cost is real, the reach is limited, and the fallback work is the majority of the effort either way.
Worth building, and not
Removes a step
- One-tap rating or feedback, submitted in place
- Choosing a delivery slot without a round trip
- Approving or declining a request inline
Replaces one gesture with another
- Product carousels
- Accordions hiding content the reader wanted
- Hover effects on a device with no hover
Building the fallback first
The discipline that makes any of this safe is building the static version first and completely, then layering the interaction on top. Done in that order the fallback is the real email and the interaction is a bonus.
Done the other way round — building the interactive version and then producing a fallback — the fallback is always an afterthought, and it is what most of your list receives.
Before shipping anything interactive
- The static version delivers the entire message on its own
- The static version was built first
- The interaction removes a step rather than replacing a gesture
- Hover-dependent behaviour has a tap-or-nothing equivalent
- If AMP: the HTML fallback is in the review checklist
- Tested in a client that does not support it, deliberately
Frequently asked questions
Do interactive emails improve engagement?
Published case studies say so and they are self-selecting — nobody publishes the interactive email that did nothing. Measure it against the static version on your own list before committing to a template.
Is AMP for Email still worth learning?
For most senders, no. It is worth understanding so you can recognise when a workflow genuinely justifies it, which is a narrower set of cases than the marketing around it suggests.
Are CSS interactions a deliverability risk?
Not inherently. Some of the techniques rely on markup patterns that also appear in obfuscation, so unusually elaborate implementations can attract attention. Simple ones are fine.