Most signatures are designed for the desktop inbox. The mockups are reviewed in Figma at 1x, the QA happens in Outlook on a 27-inch monitor, the brand team approves it on a laptop. Then the signature ships, and somewhere between 40% and 65% of the people who read it are reading it on a 4.7-inch phone screen, in portrait orientation, on a network with intermittent connectivity, while doing something else.
The signature that was designed for desktop is not the signature that lands on those phones. The horizontal layout that fit elegantly in a 600-pixel cell becomes a horizontally-scrolling mess. The 80x80 logo that sat next to the contact details now consumes a third of the visible signature area. The carefully balanced two-column structure collapses, sometimes gracefully, often not. The end result is that for the majority of recipient impressions, the signature looks like a broken artifact — and the company on the sending end has no idea, because they only ever look at it on desktop.
This article is about designing for the mobile inbox specifically: not "responsive email" in general, not "mobile-first" as a slogan, but the concrete design and engineering decisions that determine whether your signature reads as branded and intentional on a phone. It is opinionated, it is pragmatic, and it is informed by reviewing several thousand signatures across the customers I work with — most of which fail the mobile test in identifiable ways.
A small confession before we begin: the version of this article I would have written two years ago would have spent more time on what is technically possible — every fancy CSS technique, every dark-mode workaround, every clever hack to coerce iOS Mail into rendering closer to a marketing email than a 1996 plain-text footer. The version I am writing now spends more time on restraint. Across enough customers and enough rounds of mobile rendering, the signatures that consistently look great are the ones that did less rather than more — fewer columns, fewer images, fewer tricks, more hierarchy and air. The discipline is closer to print typography than to web design, and the artifacts that emerge from that discipline land more cleanly on the small screen than the more ambitious alternatives I used to advocate for.
The mobile inbox is the majority inbox now
Before discussing design, the volume picture is worth grounding. In 2026, mobile devices account for somewhere between 40% and 65% of business email reads, depending on the role and the industry. Sales replies on a phone. Customer-facing executives reply on a phone. Support teams reply on a phone, often as their primary device. The categories of email that are still primarily desktop-read — internal collaboration, transactional notifications, content-heavy marketing — are increasingly the minority. The signature that ships on every reply and every introduction email is, statistically, going to be read on a phone more often than on a laptop.
This shift was gradual, and the design discipline of email did not catch up evenly. Marketing emails — newsletters, transactional confirmations, drip campaigns — adopted responsive design over the last decade because the consequences of not doing so were visible (low click-through, complaints). Signatures did not, because the consequences are invisible: the recipient does not write back to say "your signature was unreadable," and the sender does not see what the recipient saw. The cost is real but silent.
The anatomy of a mobile-correct signature
A signature designed for the mobile inbox follows a different structural pattern than the desktop equivalent. The two-column "logo on left, info on right" layout that works at 600px wide does not survive the trip down to 320px. The right pattern is single-column, vertically stacked, with deliberate visual hierarchy.
The single-column structure
The structure I recommend, top to bottom: a small logo (32–40 pixels tall), the employee name in 16–17px bold, the role in 14px in a muted color, a horizontal divider (a thin 1px line in brand color), the contact details on a single line if they fit (email, phone, calendar link separated by middots), the company URL on its own line, and the legal disclaimer in 11px at the bottom. This stack reads naturally on a small screen, takes up about half the vertical space of an unoptimized signature, and renders consistently across iOS Mail, Gmail mobile, and Outlook mobile.
The logo: small, hosted, retina
On mobile, the logo is doing less brand work than on desktop because the screen real estate it consumes is proportionally larger. Reduce the logo to 32–40 pixels in height, host it as a 2x retina PNG (so the actual file is 64–80 pixels tall and the rendered display is 32–40), and make sure it has a transparent background. Avoid full-color logos with gradients or complex shading; on a small screen at low DPI, they become muddy. A monochrome or two-color version of the logo, designed specifically for the signature use case, consistently looks better than the full marketing logo shrunk to 32 pixels.
Employee photos: skip on mobile, or use carefully
Employee photos are an open design question on mobile. They take up vertical space, they often look pixelated at small sizes, and they double the visual weight of the signature header. My recommendation is to either omit the photo from the mobile variant entirely or to use it small (40–50 pixel diameter circular crop) and consistently across the company. The cumulative effect of "headshot 40px circle" repeated across every employee's signature is recognizable and pleasant; the cumulative effect of "headshots ranging from 30 to 80 pixels at varying crops" is messy.
Typography for the mobile inbox
Type sizes that look fine on a Retina laptop screen often become unreadable on a small phone screen. The reason is partially physical (a 12px character on a 13-inch laptop occupies a different visual angle than the same 12px character at arm's length on a phone) and partially environmental (phones are read in worse lighting, in motion, with split attention). Compensate by sizing up.
Specific size recommendations
- Employee name: 16–17px, bold (font-weight 600 or 700). The name is the signal recipients use to confirm the sender; it should be unmissable.
- Role and company: 14px, regular weight, in a muted color (`#5A554F` works well on the Mail Brand cream canvas; on a white background, `#444444` or `#555555`).
- Contact line: 13–14px, with each piece (email, phone, calendar) separated by middots (`·`) and rendered as links. Larger than I would suggest for desktop because the tap targets need to be finger-friendly.
- Disclaimer: 11px minimum. Smaller than 11px is unreadable on small screens regardless of how light the color is. Use a slightly muted color (`#888888`) but do not go below 11px.
Line height and tracking
Line height matters more on mobile than desktop because the screen is narrower; tight line height makes mixed-size text feel cramped, while loose line height creates space that the eye can rest in. Use 1.45–1.55 for the body of the signature, with the disclaimer at 1.4 (slightly tighter to keep it visually distinct as a footer). Avoid letter-spacing changes; on the mobile-rendering engines that support it, the effects are unpredictable, and on the ones that do not, the styling is silently dropped.
Font stacks that work
On iOS Mail, the system font stack (`-apple-system, BlinkMacSystemFont`) renders as San Francisco, which is excellent. On Gmail mobile (Android), the system stack falls back to Roboto, which is also excellent. On Outlook mobile, the system stack works on iOS but on Android sometimes falls back to a less elegant default; specifying `Arial` or `Helvetica` as a secondary fallback covers the edge case. The stack I use as a default for signatures: `font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Helvetica Neue", Arial, sans-serif`. It is verbose but it covers the cases.
The engineering: rendering quirks of iOS Mail and Gmail mobile
Even with a good design, the rendering of mobile email clients introduces engineering issues that need to be solved deliberately. iOS Mail and Gmail mobile are, in 2026, the two clients that account for the vast majority of mobile email reads in B2B contexts. They behave differently in important ways.
iOS Mail: WebKit-friendly with caveats
iOS Mail uses the WebKit rendering engine, which is the same engine that powers Safari. In principle, it supports almost everything you would expect a modern browser to support — flexbox, grid, modern CSS, web fonts via @import. In practice, iOS Mail is conservative: it strips `<style>` blocks more aggressively than Safari, ignores `@media` queries in some contexts, and has its own opinions about font rendering at small sizes. The pragmatic answer is to inline all CSS via `style=""` attributes (the same advice that applies to Outlook) and not rely on media queries to switch between desktop and mobile variants — instead, use a managed platform that serves different signatures based on User-Agent.
Gmail mobile: stricter than Gmail web
Gmail mobile (the official Gmail app on iOS and Android, not "Mail" on iOS configured for a Gmail account) is stricter than Gmail web. It strips more styles, applies a wider set of default styles, and sometimes overrides specified colors with its own theme defaults (particularly in dark mode). The defensive practices: specify every color explicitly (do not rely on browser defaults), use absolute pixel sizes for everything (no em or rem), and test in both light and dark mode before shipping. Dark mode is the most common rendering issue: a signature designed for white backgrounds becomes invisible on Gmail mobile dark mode if the text colors are set to dark grey or black without a background contrast fallback.
Outlook Mobile: a separate beast
Outlook Mobile (the Microsoft app, not Apple Mail configured for an Outlook account) maintains its own per-device signature setting, which is not synced from the desktop signature. This is the single biggest reason that mobile signature deployment requires server-side rewriting or MDM configuration: Outlook Mobile does not honor the signature you set in your desktop Outlook, so a user who replies from their phone gets the default Outlook Mobile signature ("Sent from Outlook for iOS"), not your branded one. The fix is at the platform level, not the design level — but it is worth understanding the constraint, because designing a mobile signature that never reaches the inbox is wasted effort.
The two-variant approach: desktop and mobile signatures from the same source
The cleanest solution to the mobile-vs-desktop tension is to maintain two variants of the signature — a desktop variant and a mobile variant — and have the system serve the appropriate one based on the originating device. This requires a managed signature platform that supports User-Agent-aware rendering. Most modern platforms do; the implementation is invisible to the user and produces dramatically better mobile rendering than a single one-size-fits-all signature.
How to maintain two variants from one source
The right model is a single source of structured data (employee name, role, contact info, banner reference) plus two rendering templates — one for desktop, one for mobile. Both templates draw from the same data; only the layout, sizing, and image dimensions differ. This avoids the failure mode of having two parallel signature systems that drift out of sync. When an employee's phone number changes, it changes once in the source; both templates pick it up automatically.
When the two-variant approach is overkill
For small companies (under 50 employees) without a managed signature platform, the two-variant approach is overkill. The right answer at that scale is to design a single signature that is mobile-first — single column, conservative sizing, careful typography — and accept that the desktop rendering will inherit the mobile-friendly constraints. The trade-off is real but acceptable; a slightly less elaborate desktop signature is a better outcome than an unreadable mobile one.
Testing: the mobile QA process that catches issues before they ship
The single most common reason that a mobile signature ships broken is that nobody tested it on a real phone before shipping. The mockup looks fine in Figma. The desktop test in Outlook looks fine. The signature ships, and the people who QA it are the recipients. This is preventable with a 15-minute testing protocol added to the design process.
The minimum mobile test matrix
- iOS Mail on the latest iOS version (currently iOS 18 in 2026), in light mode and dark mode.
- Gmail mobile app on iOS, in light and dark mode.
- Gmail mobile app on Android, in light and dark mode.
- Outlook Mobile on iOS (note: separate signature configuration required).
- Outlook Mobile on Android.
Five clients, in two color modes each, equals 10 visual checks. The whole matrix can be tested in under 15 minutes with a single test phone (or two — one iOS, one Android), or via a tool like Litmus or Email on Acid that produces screenshots at scale. For small teams, the manual approach is cheaper; for large teams shipping signature changes monthly, the automated tool pays for itself.
What to look for during the test
Specific things to check: text legibility (can you read every line at arm's length without squinting?), layout integrity (is anything overflowing the viewport, requiring horizontal scroll?), image rendering (is the logo crisp, is the photo at the right size?), color contrast (is anything invisible against the background, in either light or dark mode?), tap targets (are the linked elements at least 44 pixels tall, the iOS minimum?), and load time (does the signature render quickly even on a slow connection?). A pass on all six dimensions across all five clients means the signature is shippable.
Banners on mobile: a different design problem
Banner campaigns inside signatures are an entire design discipline on desktop. On mobile, they become something else. The 600x100 banner that looks elegant on desktop becomes a strip that consumes a full third of the visible signature area on a phone. The headline that fits comfortably on desktop overflows or wraps awkwardly. The image that anchors the banner is sized for desktop viewing distance and looks coarse at the closer mobile viewing distance. Designing banners that work on both desktop and mobile is its own constraint puzzle, and it is the part of signature design that most teams underinvest in.
Aspect ratios that work in both contexts
The desktop convention for signature banners is 600x100 pixels (a 6:1 aspect ratio). On mobile, this stretches awkwardly across the full width of a 320px viewport, becoming small and squat. The variants that work better on mobile are 4:1 (e.g., 320x80), which still feels banner-shaped at narrow widths, or 3:1 (e.g., 320x107), which gives the headline more vertical breathing room. The cleanest approach is to design two banner versions for every campaign: a desktop 6:1 and a mobile 4:1, sharing visual elements but composed differently. The signature platform serves the appropriate variant based on the same User-Agent detection that selects the desktop or mobile signature template.
Typography on small banners
Banner copy on mobile needs to be shorter than on desktop. A six-word headline that fits comfortably on a 600px banner often wraps to two lines on a 320px banner, breaking the visual hierarchy. The discipline I push: write the mobile banner copy first, get it to four to five words, and then expand for desktop if needed. The reverse order — write for desktop, then "shorten for mobile" — usually produces awkward truncations that read like the team did not care about the mobile variant.
Tap targets and link area
On desktop, a banner is clicked with a precise mouse pointer; the entire banner area is the link. On mobile, the banner is tapped with a finger, and the recipient often has the screen at an awkward angle. The full banner image should be the tap target, which is usually the case by default since the banner is a single linked image. But check: on some mail clients, the tap target shrinks to the actual image dimensions if you use HTML padding around it. Wrap the image in a `<a>` tag with explicit `display: block` styling, and the tap target reliably covers the full banner area.
Image weight and load time
Mobile recipients are often on cellular connections, sometimes slow ones. A heavy banner image (over 50KB) noticeably delays the rendering of the signature, which on Gmail mobile appears as a "loading" placeholder for several seconds before the actual content appears. The discipline: compress aggressively, target under 30KB per banner image, use modern formats (WebP where supported, JPEG with quality 75–80 elsewhere), and serve from a CDN that has good edge presence in your customer regions. The 30KB target is achievable for almost any banner design once you stop using oversized stock photography and switch to vector-derived illustrations or carefully compressed photographs.
Contextual targeting based on device
Once the platform is serving different banners by device, an interesting capability emerges: serving different campaigns based on the recipient's likely context. A mobile-read email might warrant a "save for later" banner ("Bookmark our weekly newsletter →") rather than a "act now" banner ("Book a demo today →"). A desktop-read email might warrant a more involved CTA. This level of contextual sophistication is overkill for most programs, but it is worth knowing the option exists once your mobile design discipline is mature; it is one of the marginal optimizations that separates programs producing 1% CTR from programs producing 2.5% CTR on the same audience.
Accessibility on mobile: the signature that works for every reader
Accessibility is rarely the first design constraint that signature designers think about, but on mobile it should be near the top. The mobile signature is read by people with low vision squinting at small type in low light, by people with motor impairments tapping with thumbs that miss small targets, by people using VoiceOver or TalkBack to listen to the email rather than read it, and by colorblind people who cannot distinguish the brand red from the brand orange. A mobile signature that works for everyone reading it requires a few specific design choices that overlap with — but go beyond — the general typography and layout principles already discussed.
Color contrast: the WCAG bar and the practical bar
WCAG 2.2 specifies a minimum contrast ratio of 4.5:1 for body text and 3:1 for large text (18px+ or 14px+ bold). On mobile, where viewing conditions are often worse than the WCAG conditions, I recommend a higher practical bar: 5.5:1 for body text. The brand red used in many signatures (`#C32F27` or similar) on a white background sits around 5.0:1, which technically passes WCAG but feels marginal in real use. Reserve the brand red for accents — divider lines, the company name, the banner CTA — and use a near-black (`#14110F` or `#222222`) for body text. The typography looks better, the contrast is comfortable, and the brand color does more work where it actually matters.
Screen reader semantics
A signature read by VoiceOver should produce a coherent narrative: name, role at company, a contact line, links. The screen reader follows the DOM order, which means the structure of your HTML determines the listening experience. Order the signature top-to-bottom by importance, mark up links with descriptive `aria-label` attributes (`aria-label="Email Elena Marchetti"` is dramatically better than `aria-label="email"`), and ensure the company logo image has meaningful `alt` text (`alt="Mail Brand"`). Decorative dividers and spacer images should have `alt=""` so the screen reader skips them entirely. The result is that a recipient using a screen reader hears a clean, professional signature rather than a list of unlabeled icons followed by a sea of "image, image, image" announcements.
Tap target discipline: 44 pixels minimum
Apple's Human Interface Guidelines specify a minimum tap target size of 44x44 pixels for any interactive element. Google's Material Design specifies 48x48dp. Both are higher than what a small signature naturally produces if you let the icons size to the text. To meet the threshold, wrap small icons (LinkedIn, calendar, Twitter) in `<a>` tags with explicit padding so the tappable area extends beyond the visible icon. The padding is invisible to sighted users but enormous for users with motor impairments or for anyone tapping while in motion (walking, on a train, on a treadmill). The cost is a few lines of CSS; the benefit is a signature that is usable rather than frustrating for a meaningful slice of recipients.
Language attributes for multilingual signatures
For employees whose role is multilingual — sales reps in Quebec, customer success in Switzerland, executives in Belgium — the signature may contain text in multiple languages (English title, French disclaimer, etc.). Mark up the language transitions with `lang` attributes (`<span lang="fr">Mentions légales...</span>`) so screen readers pronounce the text correctly. Without the `lang` attribute, French text gets read with English pronunciation rules, producing something between unintelligible and accidentally comedic. The fix is small markup change with significant payoff for screen reader users.
Animated banners and reduced motion preferences
Some signature platforms support animated GIF banners. If you use them, respect the `prefers-reduced-motion` media query: provide a static fallback for users who have requested reduced motion at the OS level (a setting that is increasingly common as awareness of vestibular and attention-related conditions grows). The implementation is to include both an animated and a static asset, and to serve the static asset to clients indicating reduced-motion preference. Most signature platforms do not support this directly yet; in 2026, the practical advice is to use animated banners sparingly, in shorter loops (under 5 seconds), and to avoid high-contrast strobing or rapid flashing under any circumstances. The combination of accessibility and good taste is to use animation as a small accent, not as the primary engagement driver.
Accessibility as a proxy for design quality
A useful reframe to take from this section: accessibility constraints are not a tax on design — they are a forcing function that produces better design across the board. The signature that meets WCAG contrast standards is also the signature that reads cleanly in poor lighting. The signature with comfortable tap targets is also the signature that does not produce mistaps for sighted users on a moving train. The signature with thoughtful screen reader semantics is also the signature with cleaner HTML, which renders more consistently across mail clients. Designing for the demanding case — the small phone screen, the low-vision user, the screen-reader listener — produces an artifact that lands well for everyone. Most of the design constraints that genuinely improve typography, color, and layout discipline come from accessibility considerations rather than from aesthetic preference alone.
The mobile inbox is the primary inbox for the majority of business email recipients in 2026, and signature design has not fully caught up. Most signatures are still designed primarily for the desktop experience, with mobile rendering treated as a fallback that "should be fine." It usually is not.
The good news is that the gap between an unreadable mobile signature and a well-designed one is small in design terms — a single-column structure, larger type, smaller logos, a hosted retina image, careful color and contrast, and a 15-minute testing protocol. The work is not glamorous, but it produces a result that lands correctly on the phones where most of your recipients now read.
A useful closing observation: of all the design decisions a brand team makes, the mobile signature is the one most likely to be seen by the largest number of customers, by the largest number of times each. The website is visited occasionally. The marketing email is read once. The product UI is used by customers but not necessarily by prospects. The mobile signature, embedded in every reply from your team, is seen by every person your organization has ever had a real conversation with, dozens or hundreds of times each. The design choices made in this small surface compound across that audience for years. Choosing to take it seriously, even before the rest of your design system catches up, is one of the highest-leverage moves available to a small brand team.
If you do nothing else from this article, do this: the next time you design or update a signature, test it on a real phone in both iOS Mail and Gmail mobile, in light and dark mode, before you ship it. The first time you do this, you will probably find at least one issue you would not have caught any other way. That alone is worth the discipline. The second time you do it, you will find that the issues you caught the first time are mostly gone — which is what design discipline looks like in practice: invisible improvements that the recipient never has to think about, accumulated quietly across every email your team sends.
