MailInApp
Documentation menu

Interactive Email Fallbacks: How They Work in Every Inbox

The fallback engine is the heart of MailInApp. It exists because email clients disagree about everything: some run modern CSS, some drop the CSS rules that drive interactivity, and classic Outlook renders email with Microsoft Word's engine. Instead of designing for the lowest common denominator, you design once — and the engine compiles every block into three tiers.

The three tiers

Tier 1 — Kinetic

Full CSS interactivity: carousels that slide, accordions that expand, reveals that animate. Kinetic markup is built on CSS state machines — hidden checkboxes and radio inputs whose :checked state drives what's visible — because that's the interactivity email clients actually support. No JavaScript is ever used; every email client strips it.

MailInApp measures this in real inboxes (latest run: October 2026). The tap-to-reveal blocks (accordion, flashcards, scratch-off, spin-to-win) run in Mail on iOS, iCloud Mail on the web, Thunderbird and Yahoo Mail. The carousel slides in all of those but Yahoo.

Every Gmail app, Outlook.com and the Outlook apps show the fallback instead. Apple Mail on macOS and Samsung Email aren't measured yet. The per-app picture is in Email client support.

Tier 2 — Static

Every email app measured keeps the <style> block, but Gmail, Outlook.com and the Outlook apps drop the rules that drive interactivity (:checked and the selectors around it). For them, every block collapses to clean, stacked content with a call-to-action link — to vote, to open the gallery, to submit the form — pointing at the hosted live view. Nothing stays hidden: accordion answers are open, both sides of each flashcard show, and the scratch-off prize shows. Plain links work in every email app tested, which makes this tier universal.

Tier 3 — Outlook

Classic Outlook for Windows renders with Word, which supports neither kinetic CSS nor most modern layout. The engine emits a dedicated table-based version of each block inside Outlook conditional comments — markup only the Word engine sees. Recipients on classic Outlook get a clean, intentional email, never a broken one.

One email, every inbox

All three tiers ship inside the same HTML file. Which tier a recipient sees is decided by their client's own rendering rules, not by fragile client-detection:

  • clients that support kinetic CSS render Tier 1 and hide the static variant;
  • clients that drop the interactive CSS rules naturally render Tier 2;
  • the Word engine only sees Tier 3, via conditional comments.

Interaction follows the same philosophy

One-tap choices (polls, ratings, RSVPs, booking times) are plain links in every email app — a tap opens a short page that confirms and records the response — because links are the one primitive that works everywhere. Typed answers (forms, quizzes) keep their form in the email, and sending from inside the email is a progressive enhancement in the apps that can post a form (Gmail on the web and the Outlook apps for iOS and Android). Every form also shows an Answer on the web link underneath, so readers in other apps answer in the live view. Details in Interactions & analytics.

What the engine refuses to do

Part of the engine's job is saying no. Techniques with poor or inconsistent client support — JavaScript, embedded video, <details> elements, CSS variables — are not used, ever, no matter how tempting the demo would look. If a technique can't degrade gracefully, it doesn't ship. The full support picture is in Email client support.

AMP for Email gets its own explicit call-out, not just a mention in that list: it's a deliberate trade-off, not a missing feature. See Why not AMP for Email?