Open any modern web page and you'll find CSS Grid, custom properties, container queries, and smooth animations. Open an email in Outlook and you're in a different decade entirely. This is not an accident — it's the result of a fundamental divergence that happened almost 20 years ago and has never been corrected.
The frozen clock problem
In 2007, Microsoft shipped Outlook 2007 with a significant architectural change: it replaced Internet Explorer as the HTML rendering engine with Microsoft Word. The rationale was that Word offered better fidelity for rich document formatting. The consequence for email developers was catastrophic.
Word's rendering engine does not support CSS floats, flexbox, CSS Grid, CSS animations, SVG, or most of the features that define modern web design. Every version of Outlook since — 2010, 2013, 2016, 2019, and the current Microsoft 365 desktop client — uses the same engine. That's nearly two decades of email developers coding around a rendering limitation that was introduced as a "feature."
Why table-based layouts are still necessary
The correct way to build an email layout in 2026 is with nested HTML tables — the same technique that web designers used in 1999 before CSS became reliable. This is not nostalgia. It is the only layout model that works consistently across Gmail, Outlook, Apple Mail, Yahoo Mail, and the dozens of other clients and webmail environments that real users open email in.
Every table should have cellspacing="0", cellpadding="0", and border="0" set explicitly. Layout must live in <tr> and <td> elements, not <div> containers. CSS must be inlined on every element that needs it, because many email clients strip or ignore <style> blocks entirely.
This is tedious to write by hand. It is also precisely the kind of structured, rules-based output that AI generates well.
The 102 KB trap
Gmail silently clips any email that exceeds 102 KB of HTML. The clipped portion is replaced with a "[Message clipped] View entire message" link. Most recipients never click it. If your footer, unsubscribe link, or legal disclosure lives below the fold — and below the clip — your users never see it.
Many drag-and-drop email builders export bloated HTML that regularly exceeds this limit. Inline styles get repeated hundreds of times. Embedded web fonts add tens of kilobytes. The visual editor looks beautiful; the actual output is a deliverability hazard.
The Outlook VML problem
Want a rounded button in your email? In a web page, that's one line of CSS: border-radius: 4px. In Outlook, CSS border-radius is ignored entirely. The only way to render rounded buttons in Outlook is to use VML — Vector Markup Language, an XML-based format from 2001 — wrapped in conditional comments:
<!--[if mso]>
<v:roundrect xmlns:v="urn:schemas-microsoft-com:vml"
href="https://example.com" style="height:44px;width:160px;v-text-anchor:middle;"
arcsize="10%" fillcolor="#3ab8c4">
<w:anchorlock/>
<center>Book a demo</center>
</v:roundrect>
<![endif]-->
<!--[if !mso]><!-->
<a href="https://example.com"
style="background:#3ab8c4;border-radius:4px;padding:12px 32px;color:#fff;
text-decoration:none;display:inline-block;">
Book a demo
</a>
<!--<![endif]-->Every CTA button in a professionally built email requires this dual implementation. There is no shortcut. Omitting the VML means Outlook users see a plain underlined text link, not a button.
Why drag-and-drop builders underperform
The visual email builders that marketers rely on — built into most ESPs — share a common architecture: a WYSIWYG editor that generates HTML from a proprietary template schema. The output is designed to look correct in their own preview renderer, not to be portable, clean, or compatible.
Common problems with builder-generated HTML include:
- Excessive CSS repetition — the same
font-familydeclaration inlined fifty times because every cell is treated independently - Missing VML fallbacks — buttons look sharp in the editor preview but are plain links in Outlook
- Non-portable HTML — proprietary attributes and class names that only work inside the builder's renderer, not when exported to another ESP
- Files over 102 KB — especially common with image-heavy templates or builders that embed preview CSS
The result is that marketing teams often have emails that look fine in the platform preview, pass QA, and then break in real inboxes.
What AI-driven generation actually changes
AI email generation is most useful not as a way to avoid design work, but as a way to produce correct code at speed. The hard parts of email HTML — table nesting, inline CSS coverage, Outlook conditionals, file size discipline — are all rule-based. They are exactly the kind of problem that a well-trained model can solve consistently.
The right output from an AI email tool is not a pretty visual. It is clean, table-based HTML with inline CSS on every element, VML fallbacks for buttons, a total file size under 102 KB, and conditional comments that handle the known quirks of each major client. HTML that a developer would have written by hand — and that you can paste directly into any ESP.
That gap between the email you can imagine and the email you can build is what Mailcode was built to close. Upload your brand assets, describe your campaign, and get production-ready HTML in seconds — with all the compatibility work already handled.