Design and Technical

Email design changed shape in 2026, and most of the trend content missed what actually moved. The listicles kept arguing about gradients and rounded corners. The real change is who reads your email first.

For a growing share of your list, a machine reads it before the person does. Gmail entered what Google calls the Gemini era on 8 January 2026, with AI Overview thread summaries, inbox question-and-answer, and writing tools rolling out across the inbox. Apple has been building Apple Intelligence summaries into Mail alongside that. A model now condenses and previews a portion of your sends before a human eye lands on them. Machine-readable opening text matters, but the rollout is uneven: Google’s is gated by account type and subscription tier, started US and English first, and puts the most capable pieces behind Google AI Pro and Ultra or trusted testers. What is true is that you are now designing for two readers at once, a person and a summariser, and the practices that serve one tend to serve the other.

This chapter is built around that. One rule does most of the work, and it wins three ways at once, so I will state it plainly: live HTML text beats text baked into an image, every time. After that comes the production system that gets you fast, on-brand, non-slop email at volume. Then dark mode, accessibility, the anti-default discipline, and the technical foundations underneath. The simplest emails still tend to win. What changed in 2026 is that “simple” now also means legible to a machine.

The Load-Bearing Rule: Live Text, Not Images of Text

Take one thing from this chapter, take this. Headlines, offers, and any copy that carries meaning must be live HTML text, never pixels in a JPEG. It is the single most consequential decision in an email build, because it pays off in three places that used to be separate problems.

Accessibility. A screen reader can read live text. It cannot read a headline inside an image unless you have written perfect alt text, and most teams have not: a 2025 Litmus figure found only 47% of companies use even basic alt text. Live text is read correctly by default.

Dark mode and images-off. Live text recolours and stays visible when a client inverts the palette or a reader has images switched off. An image headline either disappears against a dark background or shows nothing when images do not load.

AI summaries. This is the new payoff. Gemini and Apple Intelligence summarise the text they can parse. A headline baked into an image is invisible to the model. If your value proposition lives in a hero JPEG, the summary the recipient reads before they ever open the email may say nothing about what you are offering. The email that looks gorgeous in your preview can be a blank space to the machine that may shape the preview or summary a reader sees after delivery.

One discipline, three payoffs. That is why the rule sits at the top of the chapter rather than buried in an accessibility checklist. Put the offer in real text near the top, mark up structure with semantic headings and bullets, use bold for genuine emphasis, and never lead with an image-only block. Keep your subject line and preheader aligned with that opening text so the human, the summariser and the inbox preview all tell the same story.

A caution to carry through: treat any specific click-through uplift number attached to “design for the summary” as directional, not law. The mechanism is sound and already good practice. The precise percentages floating around are not measured against a stable, general inbox behaviour yet, because the rollout itself is not general yet.

The Production System: Tokens Plus Tested Modules

Most design advice skips the production reality. The teams shipping good email fast in 2026 are not designing each send from scratch, and they are not prompting an AI into a finished campaign cold. They run a system: a set of brand tokens plus a library of tested modules.

The speed shift is real and large. Litmus’ State of Email reporting tells one story across its own data: in 2024, 62% of teams took two weeks or more to send a single email; by 2026, 76% deploy within three days. That is a change in what email production is. The mechanism is mundane and powerful. You fix each rendering edge case once, at the module level, and never again at the campaign level. The Outlook background-image workaround, the dark-mode logo treatment, the bulletproof button, the tap-target sizing, all of it gets solved once inside a tested block and then reused. Brad Frost’s atomic design model is the clean way to think about it. Tokens are your atoms, modules are your molecules and organisms, and a campaign is just an assembly of pieces you have already proven render correctly.

This is also the bridge to building email with an AI agent, and where the slop-versus-craft split is decided. Context sets the split, not prompt cleverness. Figma’s own research found that 68% of designers and developers use AI to write code, but only 32% trust the output. The gap closes when the agent can read a real design system instead of guessing from a sentence. Figma’s framing is the one to remember: asking an AI to generate code without design-system context is like asking a new engineer to ship before they have onboarded.

For email, your design system is the onboarding. Give the agent a token set, a tested module library and a rules file, and the same prompt that used to produce generic filler now produces on-brand, production-ready output. This is the practical core of the email-marketing-bible-as-a-skill idea, and it is why “AI emails look generic” is almost never a prompt problem. The agent fell back on its defaults because you gave it nothing else to work from. Feed it the context and the defaults stop showing up.

What goes in the token set

Tokens are the constants you decide once and reference everywhere:

• Primary and secondary brand colours, as hex values, with at least one committed accent that is genuinely yours.
• Your font stack, written fallback-first (more on why below).
• Spacing units on a consistent scale (8px, 16px, 24px, 32px).
• Button corner radius, border treatment and the colours for primary, secondary and text-link variants.
• Approved imagery rules: real photography and product captures, no AI-generated stock fills.
• The banned-tells list (the anti-default ban list later in this chapter).

What goes in the module library

Modules are the building blocks, each already solved for responsiveness, dark mode and accessibility:

• Header with logo and optional navigation.
• Live-text hero: image, headline as real text, subhead, CTA button.
• Text block: heading, body, link.
• Product card: image, title, price, button.
• CTA button in each variant.
• Footer: socials, legal text, physical address, unsubscribe.

When the tokens are the input and the modules are the vocabulary, distinctive and compliant become the default and slop becomes the exception. Without them you land in the opposite place, fighting the model toward something brand-safe on every send. Tools like nitrosend’s Brand Kit and AI Memory exist to persist exactly this, your colours, voice and goals, so the agent designs on-brand from the first prompt rather than after three rounds of correction.

Tell the agent what to emit

One more rule that saves you from the classic trap. Do not have the agent generate raw HTML from a prompt, because then it has to reinvent every Outlook workaround on the fly and will get some wrong. Have it emit a structured intermediate that compiles to inbox-safe HTML instead: MJML, where the syntax is predictable enough that models are noticeably better at it; React Email, where you write JSX and get render-safe output; or Maizzle for Tailwind-native stacks. The agent drafts into the framework. The framework handles the client quirks. You keep the speed without inheriting the rendering bugs.

Designing for the Summary, Concretely

The live-text rule is the foundation. Here is how to build the rest of the email so the summariser and the human get the same message.

Lead with text that states the value proposition. The first block a model parses should say what the email is for, in words, not in a banner graphic. Use semantic <h1> to <h3> headings to mark hierarchy, because a model reads structure the same way a screen reader does. Use real bullets and real bold for the points that matter. Keep one email to one message. A summariser handed three competing offers will flatten them into mush, and so will a human skimming on a phone.

Align the subject line, the preheader and the opening text. These are the three things most likely to be surfaced before the open, whether by the inbox preview, the AI summary, or the reader’s own quick scan. If they disagree, you have wasted your best real estate. If they agree, you have told the same clear story in the three places that decide whether the email gets opened.

None of this is exotic. It is good semantic practice that email teams have under-invested in for years because nothing forced the issue. The machine reader forces it now.

Mobile-First Design

Mobile is the floor under everything else, and it has not stopped being the floor. Over 60% of opens happen on mobile, that number has climbed for years, and it is not reversing. And a majority of mobile users will delete an email that does not display properly on their phone. Not “looks imperfect”. Delete.

Design for the smallest screen first, then scale up.

Single column is the safe default. Multi-column layouts that look fine on desktop collapse unpredictably on mobile, stacking in the wrong order or forcing side-scroll. A single column with properly sized text, images and buttons works everywhere. Keep the width to 600 to 640px maximum.

Tap targets at least 44 to 48px. That is Apple’s minimum for a comfortable touch target, and it doubles as an accessibility requirement for readers with motor impairments. I push mine to the upper end.

Body text 16px minimum. Anything below 13px on iOS triggers auto-zoom and breaks your layout, so 13px is the hard floor, but the comfortable minimum for body copy is 16px. Set headlines larger and lead with size. The bold, oversized, high-contrast headline is a genuine 2026 hero pattern, and it works precisely because it is live text doing the job photography used to do.

The numeric type spec to lint against. Body text 16px minimum. A measure of 45 to 75 characters per line, roughly a 600 to 700px content width. Line-height 1.5 to 1.6. Left-aligned body copy. Tap targets 44 to 48px. Concrete, checkable numbers. Bake them into your module library and rules file so the agent hits them by default rather than by luck.

Compress everything. Keep individual images under 200KB and total email weight under about 800KB. Use lossless compression before upload. Serve smaller images to mobile with media queries where you can, because a hero that loads in a second on wifi can take five on a weak mobile connection, and the reader will not wait. Export at 2x for retina screens (a 1200px image displayed at 600px) and lean harder on compression to pay for the extra pixels.

Preview on real devices. Browser previews lie. The email that looks perfect in Chrome can have overlapping text on an iPhone SE or cropped images in the Gmail Android app. Use Litmus or Email on Acid, or at the very minimum send yourself a test and open it on your phone before you hit send.

Fonts: Pick for the Fallback

Custom web fonts and variable fonts are still a trap if you rely on them, and 2026 did not change that.

Web fonts render reliably only in Apple Mail, Outlook for Mac and the new Chromium-based Outlook, and partially through @import in Gmail and Yahoo web. Outlook on Windows uses Word’s rendering engine: it registers the @font-face name, cannot load the font, and silently swaps to a default. Variable fonts do not render in email at all. The variable axes simply do not apply, so never design around a weight or width that only exists as a variable axis.

The rule is straightforward. Pick the typeface for its fallback first, because the majority of your readers will see the fallback. Declare an MSO-conditional fallback stack so Outlook lands on something you chose rather than something it picked. Write the stack fallback-first in your token set. Then, if the custom font loads for the lucky clients that support it, treat that as an enhancement rather than the plan.

Email Client Compatibility

The uncomfortable truth has not changed: you are still building emails with tables in 2026. The web moved on to Grid and Flexbox years ago. Email did not, because Outlook on Windows renders HTML through Word’s engine, and Word’s engine handles tables predictably and modern CSS unpredictably. Outlook holds enough share, especially in B2B, that you cannot design as though it does not exist.

Inline your CSS. Most clients strip external stylesheets and many strip <head> styles. Inlining on each element is the only reliable way to make your styles apply. Every serious build tool does this on export.

Media queries work in most modern clients (Apple Mail, iOS Mail, the Gmail app, Outlook mobile, Yahoo) but fire inconsistently in webmail because the email renders in a preview pane rather than the full viewport. Gmail web technically supports them, yet the preview-window sizing means they often do not activate. Build mobile-first so the base layout is already right, and use hybrid design as the safety net.

Hybrid design (also called spongy design) is the fallback. Fluid layouts, percentage widths and conditional comments let the email adapt to screen size without depending on media queries. Mark Robbins generally recommends a div with a ghost table over real layout tables, which sidesteps a lot of the spacing problems tables cause. Robbins, now Developer Advocate for Email Experience at Customer.io, has done more than anyone to push CSS-only techniques in email, and if you build at a technical level his work is the reference.

Rendering differences worth testing for. Outlook desktop (2019, 2021, 365) gives you no CSS background images, limited padding control and unpredictable table spacing. VML was the traditional fix for Outlook background images, but Robbins has flagged that VML creates serious accessibility problems, so prefer a solid fallback background colour instead. Gmail web silently drops <head> styles past roughly a 16KB threshold, so keep your CSS lean or watch styles vanish. Apple Mail is the most standards-compliant client and supports nearly everything, which makes it a lovely place to develop and a dangerous place to assume the rest of the world behaves the same. Yahoo and AOL have improved but still have quirks around media queries and margins. Test, do not trust.

Dark Mode: Sensible Defaults, Not Universal Law

Dark mode is a baseline viewing condition, not an edge case. Over 40% of opens happen in dark mode (Litmus puts it at 41% in its own audience), and an unbriefed build will cheerfully hand you black text on a black background, a logo with a white rectangle smeared around it, or links that vanish into the surface.

The important nuance is that dark mode is not one behaviour. Clients handle it three ways: some invert your colours, some swap backgrounds, some do both, and some honour your instructions while others overrule them. So treat the rules below as sensible defaults you reach for, not a lint rule you enforce blindly.

The QA work is code-level. Add a <meta name="color-scheme" content="light dark"> so clients know your email is dark-mode aware. Use @media (prefers-color-scheme: dark) to supply explicit dark styles where it is honoured, mainly Apple Mail and the new Outlook. Use the [data-ogsc] and [data-ogsb] selectors to target Outlook’s own dark-mode colour swaps. And know the Gmail gotcha: Gmail force-inverts on its own terms and is far less controllable than Apple Mail, so you cannot rely on your custom dark styles there. Test both Apple Mail and Gmail, because they will not agree.

Softer near-black and off-white, not pure values. As a default rather than a law, avoid a pure #000000 background and pure #FFFFFF surfaces. Pick a softer near-black (around #121212) and an off-white body so logos and borders do not disappear when a client inverts, and so the light-mode version does not flash blindingly bright. The same logic applies to body text: avoid pure #000000, use a dark grey like #222222 or #333333, because slightly off-black inverts to a comfortable off-white rather than a harsh pure white.

Protect logos and images. Supply transparent-PNG logos, and where a logo sits on a light fill, add a thin stroke in your brand colour so it survives inversion. Where you can, supply a light-version asset for dark mode rather than hoping the inversion is kind. Put a subtle border or shadow around images with white or light backgrounds so they do not float disconnected in dark mode.

Check the buttons and the section fills. A CTA that pops on white can disappear on a dark surface, so give buttons a border that holds them visible regardless of background. Coloured section backgrounds (a tip box, a banner) may be stripped or recoloured in dark mode, so make sure the content reads even if that fill reverts to the client’s default dark surface.

Make the dark-mode pass part of the module build, not a panicked fix after the first test send.

The Anti-Default Ban List

When everyone can generate a clean, functional email in thirty seconds, clean and functional stops being a differentiator. The defining design risk in 2026 is not an ugly email. It is a forgettable one. AI design tools converge on a statistical mean, and the email-specific tells of that mean are now everywhere. The credible analysis behind this is the “visual echo” argument: generated design trends toward the average of its training data, so the more people generate, the more the outputs look alike. Apply to design the test you apply to copy. If the email could have come out of any template, it failed.

So keep an explicit ban list, and put it in your rules file so the agent routes around it:

No reflexive purple-to-blue gradient. This is the visual signature of AI-default design, dominant in SaaS especially. It is the design equivalent of the giveaway em dash: the moment you see it, you know nobody made a real decision. Even Really Good Emails’ own 2026 trend write-up self-flags gradients as overdone.

No unprompted beige or earth-tone wash. The muted earth-tone palette is what every generator reaches for when it wants to look “premium” and “calm”. The instant everyone’s generator reaches for it, it stops reading as either.

No default Inter-plus-rounded-card combo. Inter and system sans on a rounded card is the house style of the statistical mean. Rounded corners and tasteful neutrals are not wrong in themselves; defaulting to them because the model defaulted to them is the problem.

Own one committed brand colour, pulled from your tokens. Colour drives a large share of brand recognition and is usually the first thing a reader recalls. Claim an ownable hue and run it confidently across a meaningful share of the design, the way Absolut owns its blue. Do not accept a palette of six tasteful neutrals with a timid accent. One committed colour used boldly does more for recognition than a careful scheme used cautiously, and it should come from your brand tokens, not the model’s mean.

The anti-default work is subtraction as much as selection. AI over-decorates by reflex, filling every section because filling sections is the safe move. A single clear message with real negative space beats a busy layout that crams three offers above the fold. Whitespace that is there on purpose reads as confidence. Whitespace that is there because a section wrapper doubled its padding reads as unfinished, so check spacing in the rendered email, not the editor.

The Milled Lesson: Steal the Structure, Not the Execution

The best way to learn distinctive design is to tear down real sends, and Milled makes that easy. It archives real emails from roughly 102,000 brands, rendered as full-height thumbnails, filterable by date and keyword, with subject line and preheader shown under each. One scroll reads a brand’s whole design system. The method is repeatable and an agent can run it: pick a category, pull three to five brands, scan the grid, name the structural move. (Milled skews US ecommerce and promo, and is thin on luxury restraint, so source minimal-lux exemplars from Really Good Emails or brand sites instead.)

Two brands map the real 2026 spectrum. At the craft-and-restraint end, Graza, the olive oil brand, owns one saturated chartreuse and drenches nearly every send in it, pairs it with hand-drawn illustration and a bold condensed wordmark, and writes subject lines with personality baked into the numbers (a deliberately odd “20.74% off everything”). It is instantly recognisable in a thumbnail grid and effectively un-fakeable by a generic AI pass, because the craft is the moat. At the velocity-and-urgency end, Chubbies runs photo heroes with overlaid headlines and CTA pills, a persistent storefront nav bar in every email, live countdown timers, and a relentless promo voice.

Here is the lesson, the most important design instruction in this chapter for an AI agent. Steal the structural move. Never steal the execution that breaks the rules. Owning a colour, building a recognisable voice, committing to a single urgency device, those are the moves to copy. But the successful DTC senders quietly violate the load-bearing rule, because they bake their headlines into the hero JPEG. That buys visual punch and it costs you live text, dark mode, image-blocking fallback, accessibility, the AI summary, and a sane image-to-text ratio for deliverability. So tell the agent explicitly: copy Graza’s own-a-colour discipline and Chubbies’ single-urgency-device instinct, and render every headline as live HTML text with real alt text. The slick examples are evidence of the structural move worth stealing and a caution against the execution worth avoiding, in the same email.

Motion and Interactivity: Set Expectations Honestly

Interactivity sells well in vendor decks and underdelivers in real inboxes, so set your expectations from support data, not from the brochure.

AMP for email never revived. Worth saying flatly, because people keep planning around it. The AMP-for-email spec has been untouched since a 2023 typo fix, its working group has been inactive since 2021, Microsoft killed the Outlook.com preview, and it is supported in only Gmail, Yahoo and Mail.ru. For almost every sender, AMP is not worth the build cost. Do not architect a programme around it.

CSS animation is a minority feature. Client support sits at roughly 31.7% (about 24% full plus 7% partial). Outlook Windows from 2003 through 2019, older Apple Mail and Outlook.com render none of it. Treat motion as optional enhancement only, with a fully functional static fallback underneath. The widely quoted “97% use an interactive element” figure is 2025 data, and it mostly counts countdown timers and dynamic blocks, not AMP, so do not read it as proof that rich interactivity is mainstream.

The safe options that actually work. Animated GIFs render almost everywhere (some Outlook desktop versions show only the first frame, so make that frame self-sufficient). Countdown timers generated server-side as animated GIFs work in nearly every client and are genuinely useful for real deadlines, with one rule: only ever count down to a real one. A timer to a sale that quietly extends afterwards trains your list to ignore your urgency. CSS hover effects are low-risk where supported and harmless where not. Build the fallback first, always, then layer enhancement on top for clients that can take it. Any specific conversion-lift number a vendor attaches to interactivity should be read as directional and caveated, not as a promise.

Accessibility

Paul Airy has carried the email-accessibility message for years, and the core of it holds: accessible emails are not only the right thing, they perform better for everyone. Roughly 15 to 20% of people have some form of disability (visual, motor, cognitive, or situational, like reading one-handed while holding a baby), and designing for them tends to improve the email for the other 80% too.

The stakes are now legal, not just ethical. The European Accessibility Act took effect on 28 June 2025 across all 27 EU member states, with WCAG 2.1 AA, via the EN 301 549 standard, as the benchmark, and member-state penalties that in some countries reach a percentage of turnover. If you send into the EU, this is enforceable.

The WCAG 2.1 essentials for email:

• Colour contrast of at least 4.5:1 for normal text and 3:1 for large text. Check it with a contrast tool, because what reads fine on your monitor can be illegible on a cheap screen in sunlight.
• Descriptive alt text on every meaningful image, and an empty alt="" on purely decorative ones so screen readers skip them. Only 47% of companies use even basic alt text, which is the easiest competitive edge in the chapter.
• A logical reading order, because screen readers follow source order, not visual layout.
• A lang attribute and a dir attribute on the html element for correct pronunciation and text direction.
• Link text that makes sense alone. “Download the 2026 Email Benchmarks Report” beats “click here”.
• Never rely on colour alone to carry meaning. If red signals a sale price, say “Sale price” or use a strikethrough too.
• role="presentation" on every layout table, so screen readers treat it as layout rather than parsing it as data.
• Tap targets of at least 44px, an accessibility requirement and not only a mobile nicety.

And notice the through-line one more time, because it is the whole argument of this chapter compressed: live real text is the accessibility fix, the dark-mode fix and the AI-summary fix at once. The single decision to keep meaning in text rather than in pixels resolves three otherwise separate problems.

Make accessibility a standing QA step, not a one-time pass. Before every send: every image has alt text, the reading order is logical, buttons and links have size and contrast, and the email still makes sense if you can only read the headings and link text. Test with a real screen reader at least quarterly on your most-used templates: VoiceOver on Mac and iOS, NVDA on Windows, TalkBack on Android, all free. Hearing the email read aloud surfaces problems no visual inspection will.

Match Design Intensity to the Email

Not every email wants a maximal build, and treating them all the same is a waste. Match the intensity to the type and the relationship stage.

A live-text hero with bold type and a committed colour belongs on brand and promotional broadcasts, where the job is to stop the scroll and be recognised. Near-plain-text belongs on founder notes, relationship emails, win-backs and B2B nurture, where a heavily designed template can undercut the “this is a real person writing to you” effect. The plain-text-versus-HTML performance percentages that circulate are vendor-sourced and directional, so treat them as a nudge rather than a rule, and choose by the job the email is doing.

Design diverges by category too, over a universal mobile-thumb-first single-column floor. Newsletters lean editorial and typographic. DTC leans segmented and product-photo-led. SaaS leans lifecycle and transactional. These are heuristics, not data claims, but they point your effort in the right direction. And the place where design effort pays off most is your automated flows. Klaviyo’s 2026 benchmarks attribute roughly 41% of email revenue to flows from only about 5.3% of sends, on the order of 18 times the per-recipient revenue of campaigns. Your welcome, abandoned-cart and post-purchase modules will send for months or years. Build those properly, version-control them, and let one-off campaigns borrow from the same module library.

No-Code, Coded, or Both

This is not an either-or. No-code builders like Beefree or Stripo are several times faster for a one-off campaign: a single promo in thirty minutes instead of three hours. Coded templates earn their keep on recurring flows, where version control, pull-request review and systematic updates across a whole automation matter. Most mature programmes run both: coded, tokenised templates for the flows, and no-code for one-off sends, all drawing on the same brand tokens and tested modules so the output stays consistent whoever builds it and however fast.

The Anti-Slop Business Case

I will close on the commercial argument, because the craft case only matters if it shows up in the numbers, and it does.

The backlash against AI slop is measurable, not just a mood. In one trade survey, 18% of consumers said they had unsubscribed from an email because they suspected it was AI-written, and 50% said their trust in a brand drops if they learn AI wrote the email. There is a genuine paradox in the same data, where roughly 70% said they would trust a brand more if AI use were disclosed, which suggests the problem is concealment as much as the AI itself. “Slop” was Merriam-Webster’s 2025 Word of the Year, which tells you the wider culture has named the thing your subscribers are reacting to. When Gucci used AI-generated imagery for its Milan Fashion Week 2026 campaign, the backlash was immediate and specifically about a craft house looking like it had stopped caring.

The constructive side of that backlash has a name. “Anti-AI Crafting” was coined by Graham Sykes, global executive creative director at Landor, in December 2025: human craft as the deliberate antidote to AI’s hyper-slick sameness, with hand-built sets, visible imperfection and analogue surfaces. The dollar and engagement figures attached to it in some write-ups are content marketing rather than studies, so I will not quote them, but the movement is real and the underlying logic is sound. When the machine output trends to the mean, the visibly human choice is the differentiator.

So the synthesis for 2026 is this. AI is a breadth tool, not a finishing tool. Use it, with a token set and a tested module library as its context, to get a strong structural draft in front of you fast, which is where the Litmus speed shift comes from. Then direct it, cut, and keep at least one real human design choice in every send, because that choice is increasingly what your subscriber is unconsciously checking for. Own a colour. Keep meaning in live text so the human, the screen reader and the summariser all read the same thing. Ban the defaults. Test it where your subscribers actually open it, because an agent can produce a layout in seconds but getting that layout to render right across every client, Outlook included, is still the genuine craft.

The forgettable email is the expensive one now. Build the system so distinctive is your default and slop is the exception, and the inbox, both the human and the machine reading it, will reward you for it.

---