Email structure, inline styles, and useful fallbacks

By Gyata Tabiri · Revised October 30, 2026

Email code involves practical choices about structure, styling, and fallbacks. I am interested in what those choices preserve: a readable message, a recognizable design, and a source file someone else can update.

Use structure for the job

Layout tables remain common in HTML email. Where a table is used only for presentation, its markup should avoid implying that the content is tabular data. Keep the reading order understandable, particularly when a multi-column desktop layout becomes a single column.

Decide where styles belong

Important styling may need inline declarations for the target clients, while responsive adjustments can depend on supported embedded rules. Check how the sending platform processes both. Repeating a declaration is sometimes necessary, but the source template still needs a manageable way to maintain it.

Protect the content

Choose a fallback background and font stack that preserve readable contrast and hierarchy. Keep important instructions available as text where practical. If an image is decorative, it should not be the only way a reader can identify the action.

Test the complete message

A small working snippet does not establish that a whole campaign is ready. Real copy lengths, image dimensions, links, and platform transformations can introduce different problems. Review the assembled version and record the differences the team has agreed to accept.

A template is more useful to the team when the reasons for its structure are visible. That makes an ordinary content update easier to distinguish from a change that needs another rendering check.

Coded email examples · Discuss a role or project

Reference: Email compatibility reference.