The mobile email checks a desktop preview can miss
Check a mobile marketing email in the actual inbox as well as the platform preview. Review the subject and preview text, reading order, text size, images, dark mode, links and the destination after the main action. Test personalisation through the platform’s supported method, and keep a record of the clients and conditions checked rather than treating one screenshot as complete approval.
Put the advice into practice
Give the first enquiry a useful follow-up
Plan campaigns, nurture and customer emails with clear triggers and review.
Plan your email programmeChoose tests that reflect the actual audience
A mobile preview is a useful first inspection of a narrow layout. It is not the same as receiving the message in a particular email app. Different apps can interpret the same HTML differently, and a reader may use dark mode, larger text or blocked images. Select a manageable test set that reflects known audience needs and the importance of the message.
Start with the actual sending platform and approved template. Record the version, subject, preview text, sender and intended audience. If a major layout or platform change has occurred, allow a broader review than for a routine text amendment. Keep one accountable person responsible for deciding whether the relevant checks are complete.
Mailchimp’s preview and testing guidance distinguishes previewing from sending tests and explains limits around contact-specific merge tags. Use the platform’s supported live-data preview or a controlled test segment where required; an ordinary test email may not reproduce personalisation exactly.
Run a reading and interaction checklist
| Area | What to inspect | What a screenshot alone misses |
|---|---|---|
| Inbox introduction | Subject, preview text, recognisable sender and reply route | Whether the reply reaches the intended person or queue |
| Reading order | The main point, section order and comfortable text size | How the message behaves with larger text or image blocking |
| Images and contrast | Crops, meaningful alternatives, logo visibility and dark mode | Whether an image conveys essential information with no usable text equivalent |
| Links and buttons | Descriptive labels, separation and intended destination | Redirects, forms, downloads and actions after the click |
| Dynamic content | Names, optional blocks and missing-field fallbacks | The rules that select content for different permitted records |
| Preferences | Visible and usable preference and unsubscribe routes | Whether the resulting status is honoured by the sending process |
Treat each failed interaction as an issue to resolve, not a note beside an otherwise approved design. A button that looks correct but leads to the wrong service page can change the meaning of the whole message.
Inspect dark mode without assuming one universal result
Check whether the logo, body text, dividers and buttons remain distinguishable when the receiving app changes colours. A transparent logo designed for a light background can become difficult to see. Border-only buttons or subtle dividing lines may also lose definition under some rendering conditions.
Mailchimp’s dark-mode guidance describes differences in client rendering and recommends testing on an actual device. Avoid assuming that one CSS rule can force every email app to display identical colours. Use a design that remains understandable when exact presentation varies.
Test with images disabled as a separate condition. The headline, explanation and primary action should still make sense. Where a chart or visual contains important detail, provide an appropriate text explanation rather than rely on the reader being able to recover it from a small image.
A hypothetical event email illustrates the distinction: the mobile screenshot shows an attractive invitation, but the date exists only inside the image and the registration link opens an unrelated page. The layout review passed while the message and interaction review did not. This is an invented teaching example.
Keep the approval tied to the message that will be sent
After corrections, recheck the affected parts and any dependent elements. A changed button label may need a new destination check. A revised personalisation rule needs both matching and non-matching test records. A new hero image needs crop, alternative-text and dark-mode review where relevant.
Record which template and message version was approved, which email clients and devices were inspected and any remaining limitations. The record need not be elaborate; it should make clear what the team actually tested. Keep the final review separate from an earlier draft screenshot so a late amendment does not inherit approval automatically.
Follow the primary action through to the mobile destination. If the email asks for a booking, enquiry or download, the next page needs to explain and complete that task. A campaign is experienced as a sequence, not as separate design files.
For an example of planning the message around its next interaction, our guide to post-purchase emails is a useful companion. The same testing discipline applies whether the email is seasonal, editorial or part of an ongoing service journey.
Add one real-inbox test and one complete destination check to the next email approval. Use the findings to improve the shared email template and campaign process.
