How to publish AI-generated emails to Account Engagement (the table-layout HTML problem)

If you've ever drafted a beautiful email in ChatGPT, Jasper, or Claude, pasted the HTML into Account Engagement's email builder, and watched it render as a stack of unstyled paragraphs in Outlook, you've met the Pardot HTML email problem. Account Engagement (formerly Pardot) renders email through one of the strictest pipelines in B2B marketing automation — table-layout-only, inline-CSS-only, no flexbox, no grid, no SVG icons, no max-width, no modern CSS at all. AI tools generate modern CSS by default. The two don't meet without a translation step, and that translation is what burns 30 minutes per email for most marketing teams.

This guide explains why AE's renderer is so unforgiving, the five specific things AI-generated HTML breaks in AE, and the step-by-step fix that gets you from "drafted in an AI editor" to "rendered correctly in Outlook + Gmail + Apple Mail" without learning email-development from scratch.

Why Account Engagement is so picky about HTML

AE doesn't render email itself. AE pushes the email body to your recipients' email clients — Outlook desktop, Outlook on the web, Gmail, Apple Mail, Yahoo, mobile-app variants of all of the above — and each one parses HTML differently. AE's job is to ship HTML that survives the worst-case client.

The worst case is Outlook desktop, which uses Microsoft Word's HTML rendering engine under the hood. Yes, Word. Not a browser. Word. Word's renderer was last meaningfully updated in the early 2010s and ignores anything it doesn't understand — including flexbox, grid, CSS variables, modern transforms, viewport units, and most of CSS3.

So AE recommends — and effectively requires — table-layout-based email HTML: nested <table> elements with explicit width attributes, inline CSS on every element, no external stylesheets, no script tags, no SVG, no fancy fonts. The pattern was the email-dev standard from 2002–2015 and is still the only thing that renders consistently across the corporate inboxes that B2B marketing actually targets.

Modern AI tools generate semantic, accessible, modern HTML — <div>, <flex>, <section>, <grid>, classes referencing CSS variables, sometimes inline SVG icons. All of which look great in a Chrome preview and shatter in Outlook desktop. That's the gap.

The five things AI-generated HTML breaks in AE

When you paste AI-generated email HTML into AE's email builder and send a test, the same five problems show up in roughly this order:

1. Layout collapses to a single column in Outlook. Your two-column hero with image left and text right renders as text-then-image, full-width, because display: flex doesn't exist in Word's renderer. Anything that depends on flex or grid for layout becomes a vertical stack.

2. Spacing gets weird. Margins on <div> elements behave differently in Outlook than they do in Gmail. AI tools generate margin: 1.5rem auto or padding: 24px 16px shorthand that Outlook partially honours. The result is uneven gaps that look broken.

3. SVG icons disappear. Inline <svg> tags don't render in Outlook. AI tools love SVG icons (Lucide, Heroicons, custom marks) because they're crisp and small. None of that survives. You see a blank space where the icon should be.

4. Fonts fall back to Times New Roman. AI tools reference web fonts by name (font-family: 'Inter', sans-serif) without including the @font-face rule and a hosted font URL. Outlook can't fetch the font, doesn't have it locally, falls back to its default — Times New Roman — and your modern sans-serif design becomes a serif Word document.

5. The max-width trick fails. Modern responsive design uses max-width: 600px; margin: 0 auto to centre an email body. Outlook ignores max-width entirely. The email renders edge-to-edge on a 1920px monitor, looking like a 1990s newsletter.

There's a sixth, more subtle issue: AE's content store strips some HTML on save. Things like <style> blocks in the body, data-* attributes, and class-only references to undefined CSS get silently removed when you save the email template. So even if the HTML rendered correctly in a preview, it might not survive the save → fetch round-trip.

Now: how to fix it.

How to convert AI-generated HTML to AE-ready email

The translation is rule-based and mechanical. You can do it manually for one email; it's painful at the cadence of a real marketing team. Either way, here's the recipe.

Step 1 — Wrap everything in a 600-pixel-wide outer table

The outer container should be a <table> with explicit width="600", centred via align="center", and given a fixed pixel width. No max-width. No margin: 0 auto on a div.

<table align="center" cellpadding="0" cellspacing="0" border="0" width="600" style="width: 600px; margin: 0 auto;">
  <tr>
    <td>
      <!-- Email content goes here -->
    </td>
  </tr>
</table>

The style="width: 600px" is belt-and-braces — Outlook reads the HTML attribute, Gmail reads the inline style, and the redundancy means both render correctly.

Step 2 — Convert every flex/grid layout to nested tables

A two-column hero in modern HTML:

<div style="display: flex; gap: 16px;">
  <div style="flex: 1;"><img src="hero.jpg" /></div>
  <div style="flex: 1;"><h1>Headline</h1></div>
</div>

Becomes:

<table cellpadding="0" cellspacing="0" border="0" width="100%">
  <tr>
    <td width="50%" valign="top" style="padding-right: 8px;">
      <img src="hero.jpg" width="280" style="display: block; width: 280px;" />
    </td>
    <td width="50%" valign="top" style="padding-left: 8px;">
      <h1 style="margin: 0; font-family: Arial, sans-serif;">Headline</h1>
    </td>
  </tr>
</table>

Two cells in a single row, fixed pixel widths, explicit valign so the column tops align. The padding goes on the cells, not on the children.

Step 3 — Inline every CSS property

Every <class="..."> and every external stylesheet has to go. CSS that lives in a <style> block inside the <head> will be stripped by AE on save (and ignored by Outlook anyway). The only CSS that survives is style="..." attributes on individual elements.

Use font-family: Arial, sans-serif; as the default — Arial is the only sans-serif font installed on every Outlook desktop client globally. If you really need a brand font, use a font-family stack with the brand font first and Arial as a guaranteed fallback (font-family: 'Inter', Arial, sans-serif).

Step 4 — Replace SVG icons with hosted PNG images

Strip every <svg> tag. Replace it with an <img> referencing a hosted PNG from your CDN or AE's file library. Use width and height attributes (not just CSS) — Outlook needs both.

<img src="https://yourcdn.com/icons/check.png" width="16" height="16" alt="" style="display: inline-block; vertical-align: middle;" />

Make sure the PNG is sized for retina displays — generate at 2x resolution (32x32 source for a 16x16 display target), then reference at the display size in HTML. Otherwise icons look fuzzy on Mac and modern Windows displays.

Step 5 — Test in Litmus or Email on Acid before pushing to AE

Don't trust AE's preview. Paste the converted HTML into Litmus (or Email on Acid) and render it across the matrix: Outlook 2016 / 2019 / 365 desktop, Outlook on the web, Gmail web, Gmail app, Apple Mail desktop, Apple Mail iOS, Yahoo, AOL. The first time you do this you'll find at least three issues you didn't anticipate. From the second email onwards your conversion ruleset gets sharper and the test is a 30-second sanity check rather than a debugging session.

If you don't have a Litmus / EoA budget, use AE's built-in render previews — they cover Outlook 2016 + 365, Gmail, and Apple Mail, which catches 80% of issues. The remaining 20% comes from quirks in mobile clients and corporate Outlook versions that don't update on a schedule.

Step 6 — Save in AE, send a real test, view source

After saving the email template in AE, send a test send to yourself and view the email source in your client. Verify that:

• The HTML AE actually delivered matches what you saved (some attributes get stripped or reformatted)
• All inline styles survived
• Image URLs resolved (relative URLs become absolute via AE's CDN — make sure the absolute URLs work)
• Tracking pixels and unsubscribe footers were appended correctly without breaking your layout

This is the step most teams skip and is the single biggest source of "it looked fine in preview, it broke in production" stories.

Why crm.care handles this automatically

The translation rules above are mechanical. They don't require creative judgement; they require discipline and attention to detail across hundreds of small decisions per email. That makes them perfect for automation.

crm.care generates emails directly into AE-compatible HTML on the first pass. The generator's prompt has the AE renderer constraints baked in — it doesn't produce flexbox, grid, SVG, or max-width-based layouts because the system prompt tells it not to. Every email gets nested-table layout, inline CSS, explicit pixel widths, and PNG icons referencing your AE-hosted file library. The output goes straight into AE's email template object via the API; no copy-paste, no translation step, no Litmus debugging session.

For teams currently doing the manual translation, this is the largest single time-saver in the product. A typical 7-email nurture sequence used to take a day of email-dev work after the AI drafts came back; in crm.care the same sequence drafts AE-ready in under 10 minutes. The brand voice is consistent across the sequence (because it's a workspace setting), and the campaign tagging happens automatically (because the email is generated against a Salesforce Campaign object, not a blank page).

If you're spending hours per email translating modern HTML to AE's table-layout requirements, the automation is worth more than the rest of the product combined. The free 7-day trial is enough to ship a real campaign end-to-end, including AE publish.

For the broader frame on why we built it this way, see Why crm.care exists. For the comparison with the AI-copy tool that doesn't talk to your CRM, crm.care vs Jasper. And for what happens after the email sends, Three Degrees of Attribution in Salesforce — the closing of the loop on the post-send side.