Mobile-First Email Design: Optimizing for 60% of Opens
Single-column by default, tap target sizes, and the font sizes iOS silently overrides when you go too small.
On this page
The short version
- Most opens happen on a phone, and phones apply their own corrections. iOS scales up text below roughly 13px, which breaks any layout that assumed the smaller size.
- Tap targets need real physical size. A link in a run of body text is not a tap target, and a stack of adjacent footer links is a mis-tap generator.
- Design at 320px and let it grow. The reverse — desktop first, then squeeze — produces layouts that only just fit.
The majority of email opens happen on a phone. That is stable enough across published measurements to plan around, even though the exact share varies a lot by audience — consumer lists skew far more mobile than business ones, and a B2B list mailed at ten on a Tuesday skews the other way.
What makes mobile email different from mobile web is that the phone intervenes. It rescales text it considers too small, it inflates the tap area of links, and it may invert the palette. Designing without accounting for those corrections means shipping something the device will then change.
The three numbers to design against
320px
The narrowest width to design for
Older and smaller devices, plus split-screen
16px
Minimum comfortable body size
Below ~13px iOS scales it up for you
44px
Minimum tap target, each dimension
Roughly the pad of an adult thumb
The scaling correction
iOS enlarges text it judges too small to read, and it does this per text block rather than uniformly. The visible result is a layout where one paragraph is suddenly larger than its neighbours and a table column no longer fits — a fault that looks like a rendering bug and is actually a correction.
The fix is not to disable the behaviour, which is user-hostile and unreliable anyway. It is to start above the threshold. If nothing in the email is smaller than about 14px, nothing gets rescaled and the layout you designed is the layout that arrives.
This applies to the parts people set small out of habit: footer text, disclaimers, image captions and the legal line. Those are exactly the blocks that get inflated, which is why so many emails have an enormous footer on a phone.
Two footers on a phone
Set at 11px
- Rescaled by the device to something larger
- Rescaling is per block, so the lines mismatch
- Address line wraps in an unplanned place
- Ends up visually louder than the body copy
Set at 14px
- Left alone by the device
- Renders as designed
- Wrapping is where you put it
- Reads as quiet because the colour is quiet, not the size
Tap targets
A thumb is imprecise. Anything you want tapped needs to be around 44 by 44 pixels with clear space around it, which means a button with real padding rather than a text link sitting in a paragraph.
Adjacent links are the specific failure. A footer with view-in-browser, preferences, unsubscribe and a social row stacked in a tight column produces mis-taps, and one of those mis-taps unsubscribes someone who did not mean to. Give each footer link its own line with vertical padding, or separate them with visible dividers.
What to cut on a small screen
The instinct is to hide things with media queries. That works where media queries are supported and does nothing where they are not, so anything hidden that way has to be acceptable when it stays visible.
A better approach is to not include it. If a decorative image, a secondary navigation row or a three-column feature grid is only there for desktop, ask whether the desktop version needs it either. Email is a short-form medium on every device, and the mobile constraint is usually a good editor.
Mobile check
- Nothing smaller than 14px anywhere, including the footer
- Body copy at 16px
- Primary button at least 44px tall with padding, not a bare link
- Footer links on separate lines with vertical spacing
- Layout holds at 320px with no horizontal scrolling
- Images have explicit width so they do not jump on load
- Opened on a real phone, not only in a preview tool
Frequently asked questions
Should I use media queries at all?
Yes, for enhancement — larger type, more padding, a wider layout on bigger screens. Not for anything load-bearing, because clients that ignore them will show the unqueried version and that has to be acceptable on its own.
What about dark mode on phones?
It is a separate problem with its own handling, and it interacts with this one: colours the phone inverts can drop contrast below readable, particularly on text you set in a light grey to look quiet.
Do preview tools show what the phone actually does?
Mostly, and not for the automatic text scaling, which some tools do not reproduce. Send a real test to a real device before shipping a new template — it is a two-minute step that catches the class of fault preview tools miss.