How do fallback versions work?

You send an AMP email with an interactive product carousel. A subscriber opens it in Gmail on the web, and the carousel works perfectly. Another subscriber opens the same email in Apple Mail. Apple Mail doesn't support AMP, so instead of breaking, the email quietly swaps to a standard HTML version the subscriber never knew wasn't the "real" email. That swap is a fallback version working exactly as intended.

Fallback versions exist because email clients support different feature sets. AMP for Email is the most common use case: you build an interactive experience, but you also include a plain HTML version and sometimes a plain-text version. The email is actually a MIME package containing multiple representations of the same content. The email client reads that package and renders the most capable version it can handle. If AMP works, it shows AMP. If not, it falls back to HTML. If HTML fails somehow, it falls back to plain text. Subscribers never see this negotiation happening.

The part that's easy to miss: your HTML fallback has to be a complete, fully functional email on its own. It can't be a placeholder that says "please view this in a supported client." Every piece of information in the AMP version needs to exist in the HTML version too, even if the interaction isn't there. If your AMP email shows a live countdown timer, your HTML fallback shows a static banner with the offer dates written out. If your AMP version lets subscribers select a product size before clicking through, your HTML version links them directly to the product page. The fallback is a backup, not a lesser option. AMP for Email only pays off when the fallback holds up on its own.

Testing fallbacks is a separate step from testing the main version. You need to check both: confirm the AMP version renders correctly in Gmail, then confirm the HTML fallback renders correctly in Outlook, Apple Mail, and whatever your subscriber mix leans toward. A rendering tool like Litmus or Email on Acid shows you both versions across clients before you send. Cross-client testing should cover both the interactive and fallback paths, not just the one you're most excited about.

If you're building your first AMP email, write the HTML fallback before you write the AMP version. It forces you to think through what the experience looks like without the interaction, which almost always leads to better AMP design too. Once the fallback works, layer the AMP content on top.