A guide

What are modular email templates?

Modular email templates replace the rebuild-from-scratch loop with a small library of approved blocks (hero, centred text, product grid, CTA, promo, social) that snap together to make any campaign. Not one-off designs.

The idea

One-off emails versus a module library

Most email programmes still treat each campaign as a one-off. A new brief lands, a designer draws a new layout, a developer codes the HTML, and the team ships it. Next week, it happens again: different content, often a similar shape, always the same effort.

A modular template flips that round. Instead of designing each campaign, you design the building blocks once. Hero, centred text, two-up image, product grid, CTA, promo code, social row, footer. Each block is a self-contained module with its own structure, responsive behaviour, and editable content fields.

A new campaign then becomes assembly: pick the blocks you need, drag them into order, fill in the content, pick from any variants the module exposes (button colour, layout option, image alignment). The HTML never changes. Only the content does. The first campaign is a small win; the hundredth campaign is the whole programme moving faster.

When you apply this approach at scale, modular email templates become the foundation of an email design system: a governed library of tokens, blocks, and rules that keep every campaign on-brand. To manage those templates day-to-day without touching code, see how an email CMS sits on top of the module system.

A typical module library

Six modules cover most campaigns; twelve cover almost everything

A module is a self-contained, tested HTML block with editable content fields. Here are the ones most teams build first.

Hero

An image, headline, supporting copy, and a primary CTA. The opening shot of every campaign. Defined once; reusable across promos, newsletters, and announcements.

Centred text block

Headline + paragraph, centred. Used for openers, sign-offs, and editorial moments. Variants for size, alignment, and emphasis.

Product grid

Two, three, or four product cards with image, name, price, and link. Variants for grid count, card style, and price layout.

Promo code / banner

Promo code, expiry, and rule line. Variants for solid colour, gradient, or image background.

CTA button

A single primary action. Variants for colour (from approved brand list), size, and full-width vs inline.

Social row

A small icon row linking to your channels. Defined once at the brand level; reused everywhere.

How they work

From one-off HTML to a working module library

Three stages: mark up the template, define the modules, hand the editor to marketers.

  1. 01

    Mark up the template

    A developer takes your existing HTML email and adds simple `mm-editable` tags to mark which areas are content. The structure stays exactly as it was. Only the editable surface changes.

  2. 02

    Define the modules

    Group repeating blocks into modules: hero, centred text, product grid, CTA, promo, social row. Each module gets a name, a set of fields, and any allowed variants.

  3. 03

    Marketers assemble campaigns

    Pick the modules you need, drag them into order, fill in the fields, pick variants, preview, export. See how the editor works.

A module library replaces 'every campaign is a project' with 'every campaign is a fill-in-the-blank.'
In context

Modular templates versus the alternatives

Different ways teams handle email production, and the trade-offs of each.

Approach
Pros
Cons
Approach One-off HTML emails
Pros
  • Total design freedom on each send
  • No pre-work needed
Cons
  • Every campaign is a custom build
  • Easy to drift off-brand
  • Cleanup required after each send
Approach ESP drag-and-drop builder
Pros
  • Easy entry point
  • Built into the platform
Cons
  • Templated, generic look
  • Locked to one ESP
  • Limited custom design
Approach Comment tags in raw HTML
Pros
  • Flexible for developers
  • Works with any pipeline
Cons
  • Marketers can still break things
  • No visual preview
  • Versioning lives in source control
Approach Modular email templates Recommended
Pros
  • Structure protected, content flexible
  • Reuse modules across every campaign
  • Brand consistent by construction
  • ESP-agnostic export
Cons
  • Requires initial template setup
Who uses them

Teams who benefit most from going modular

Marketing teams

Teams who send weekly or monthly campaigns and rebuild similar layouts every time. Modules eliminate the rebuild.

A retailer sends three promo emails a week. Hero, two products, promo code, footer. With modules, the only work each week is the new content.

Agencies

Agencies running multiple clients. Each client gets their own module library; campaigns assemble cleanly without revisiting design every time.

An agency runs eight clients. Eight module libraries. Producers build campaigns from approved blocks; designers only get pulled in for new modules.

Global enterprises

Multi-region brands needing consistency across markets. Shared modules; per-market localisation through content fields.

A SaaS brand across EMEA, APAC, and Americas runs the same module library; every region's localised version stays on-brand by construction.

For the developers setting it up

Plain HTML, with editable regions marked

Your existing HTML stays exactly as it is. Add an mm-editable attribute to mark the regions a marketer can edit. The platform reads the markup and presents a content-field editor for those regions.

See the full tag reference

<table mm-module="hero">
  <tr>
    <td mm-editable mm-label="Headline" mm-type="text">
      Welcome to our summer sale
    </td>
  </tr>
  <tr>
    <td mm-editable mm-label="Body" mm-type="rich-text">
      Up to 40% off across the new collection.
    </td>
  </tr>
  <tr>
    <td>
      <a mm-editable mm-label="CTA" mm-type="link"
         mm-variants="primary,secondary"
         href="https://example.com/sale"
         class="btn btn-primary">Shop now</a>
    </td>
  </tr>
</table>
Best practices

Designing a module library that lasts

Audit your last six months of campaigns first. Most teams find they can cover roughly 80% of their sends with eight to twelve modules. Look for the layouts that recur. That's your starter library.

Design each module to stand alone. Padding, background colour, responsive breakpoints: all bound to the module itself, not to the campaign around it. Keep widths consistent (600px is the safe default for email client compatibility) and use shared design tokens for colour, type, and spacing so updates propagate cleanly.

Test every module across email clients before letting it into the library. Once a module is validated, it never has to be QA'd again. Only the content does. That's the leverage. Read our practical getting-started guide for a step-by-step walkthrough.

FAQ

Modular email templates, in detail

  1. What is a modular email template?
    A modular email template is an email built from reusable blocks: modules like hero, centred text, product grid, CTA, promo code, social row. Each module is a tested HTML block with editable content fields. Campaigns are assembled by selecting modules and filling in fields, not by editing HTML. Read our getting started guide.
  2. How are modular emails different from one-off emails?
    A one-off email is a custom build for a single send. A modular email reuses approved blocks. One-off gives you total freedom but requires design and dev attention every time; modular trades that freedom for speed and consistency. Most teams sending more than four campaigns a month benefit from going modular.
  3. What modules should we build first?
    Audit your last six months of campaigns and look for the patterns. Most teams find they can cover 80% of sends with eight to twelve modules: hero, centred text, image + text, two-up image, product grid, promo banner, CTA, social row, footer. Start there; add more as needed.
  4. How do modular templates work technically?
    Your developer marks up an HTML email with `mm-editable` attributes on the regions you want to be editable. They group repeating blocks into modules and define any variants (colour, layout, size). Modular Mail reads the markup and presents your team with a content-field editor over the top. The HTML never changes; only the content does.
  5. How are they different from ESP drag-and-drop editors?
    ESP editors give you their templates and their building blocks. Modular templates give you your design and your blocks. With an ESP-agnostic approach, you build once and send through any platform.
  6. Do modular templates work with Mailchimp, Klaviyo, Salesforce, and others?
    Yes. Modular Mail exports clean HTML you can paste or upload into any ESP: Mailchimp, Klaviyo, HubSpot, Salesforce Marketing Cloud, Marketo, anywhere. We are not an ESP; we are the CMS layer over the top.
  7. How long does it take to set up a modular template?
    Initial setup by a developer typically takes a few hours: upload your HTML, mark editable regions, define modules and variants. After that, marketers build campaigns independently. Most teams ship their first modular campaign on day one.
  8. Are there limitations?
    Modular templates are best for repeatable campaigns. They are less suited to one-off bespoke designs that need a totally custom layout. For most teams sending regular email, the upfront setup pays for itself within weeks.
Get started

A module library for your email programme.

See how Modular Mail works for your templates and your team.