How to turn email brand guidelines into styles your team can’t accidentally break

Email brand guidelines can be precise and still produce inconsistent campaigns when five people build emails from different sources. In our scenario, marketers, a designer, a lifecycle specialist, and a support teammate work from the same approved PDF and Figma file, yet the values reach the editor in different ways. One person copies a HEX code from Figma, another checks the PDF, and someone else duplicates an older email. Fonts may match, while button styles, padding, margins, and backgrounds differ from one campaign to the next.

The team manages a growing library of emails and templates, so the brand manager has to compare every new campaign with the PDF and Figma files. Problems often appear during final review, when correcting an outdated color, font, or spacing value creates another approval round. The rules are already documented; the gap sits between those documents and the settings used in production. We tested how shared-style systems close that gap, then applied the same five criteria to Stripo Themes.

Why email brand guidelines drift when five people build emails

An approved PDF or Figma file records brand rules, but it does not apply them inside the email editor. Each contributor still has to find, copy, and enter the correct values manually.

This creates several common mismatches:

• one person copies the approved HEX code from Figma, while another samples a similar color from the PDF;
• one contributor uses 16 px padding from an older template, while another follows the latest 24 px value;
• a marketer duplicates an old campaign and carries its previous button style into a new email;
• correct colors and fonts appear alongside different margins, line heights, backgrounds, and button shapes;
• every template, campaign copy, and localization becomes another place where outdated styles may remain.

The brand manager usually finds these differences during the final review or after the email reaches subscribers. Correcting one value means reopening the email, checking its desktop and mobile versions, and sending it through another approval round.

The workload grows with the email library. A rule changed in the brand guide still has to be found and corrected in every affected email. The team needs a shared style source inside the production tool, not another document that everyone must remember to open.

What a shared email theme needs to control

A shared theme should collect the design settings that repeat across emails and make them available from one source. It should cover the style layer without trying to store complete email content or replace testing.

Define the styles a theme should store

An email theme is a reusable set of shared email design settings. When a team applies one, emails receive the same baseline rules instead of requiring contributors to enter each value again.

The main groups are:

• canvas and layout: Global email background, background image, content width, message alignment, default structure padding, and margins around the message;
• stripe styles: Background colors or images for the header, content, footer, and other message areas;
• typography: Body font, fallback font, font size, line height, link styles, and separate heading rules;
• buttons: Font, text color, background, borders, radius, internal padding, and hover state;
• output-specific settings: Separate desktop and mobile values, custom font links, and controls that add Outlook/VML markup where supported.

Platforms store different combinations of these settings. Some themes contain only colors, fonts, and logos. Others include layout, spacing, responsive settings, and email-client-specific code. A team should check the stored values before treating a theme as the main source for its email styles.

Separate themes from components and assets

A theme controls shared design values, not every part of an email. 

The following items normally sit in other tools or libraries:

• logos, product images, illustrations, and icons;
• copy, tone rules, links, sender details, and legal text;
• complete headers, footers, navigation, product cards, and other reusable components;
• accessibility checks, link tests, mobile previews, and email-client rendering tests.

For example, a theme may store the default button colors and radius, while a reusable module stores the complete button placement, copy, URL, and surrounding content. Keeping these layers separate makes it clearer which changes belong in a theme and which require a module, asset, or content update.

Compare solutions using five criteria

We use the same five criteria for every shared-style system:

A product may store many style values but still require manual work when the guide changes. The comparison must also show how clearly the system reports old styles, who can modify shared rules, and how the team can recover from an incorrect update.

How Stripo Themes handles the same workflow

Now return to the brand manager responsible for keeping five team members aligned. The goal is not simply to save a set of General Styles. It is to turn the decisions already approved in PDF and Figma into a shared source that the team can use without copying values manually or requesting another approval after every routine edit.

Store approved General Styles in a project theme

Each theme exists as a separate entity within a project, and one project can contain several themes. Stripo connects the selected theme to the ID of an email or template rather than storing it as a visual reference only.

Applying a theme replaces the relevant Default CSS and updates supported values in the email HTML. 

In your email, the confirmed set covers:

• global layout styles, including Message Content Width, Message Alignment, Email Background, and Background Image;
• spacing rules, including Default Structure Padding and Margins Around Message;
• body, stripe, and heading styles;
• button styles and Support for Outlook, which adds the required VML code;
• custom font links used by the selected web fonts.

What this changes for your team: As the brand manager, you no longer need to check whether all five team members copied the same content width, typography, spacing, backgrounds, and button settings. You maintain the supported values in one project theme, while modules, assets, copy, and local styles remain controlled through their respective workflows. 

Create a theme from one approved email

Start with an email or template whose styles have already been reviewed:

1. Open the approved email in the editor.
2. Confirm that the Theme section displays No Theme.
3. Set the final General Styles.
4. Select Save theme.
5. Enter a theme name and select Save.
6. Check for the Theme created and applied message.

The name is required and can contain up to 100 characters. General Styles remain editable while the email has no theme. Saving creates the theme and links it to the open email, but it does not connect other emails automatically.

What this changes for your team: The approved reference email becomes the starting point for shared styles instead of another example that contributors must reproduce manually. Because creating the theme links only the open email, you can begin with a controlled pilot and decide which additional emails or templates should use it.

Caption: An email without a theme keeps its General Styles editable and can be used as the source for a new project theme.

Preview and apply a theme

Open Select theme or, if the email already has a theme, select Replace. Stripo displays the themes available in the current project, with the active theme shown first and the remaining themes sorted by update time.

To apply a theme:

1. Open the project theme list.
2. Click a theme tile to apply its styles to the email immediately.
3. Keep the selector open to check the result or click another theme.
4. Hover over the selected tile and select Apply to keep that theme applied and close the selector.

Clicking a tile is not a temporary preview. It applies the theme while keeping the list open. Selecting Apply applies the selected theme and closes the selector. Closing the selector after clicking a theme does not restore the previous theme automatically.

Caption: Clicking a theme applies it while keeping the selector open; selecting Apply keeps the theme applied and closes the selector.

What this changes for your team: If the project contains several approved themes, you can keep the selector open and see how each one affects the current layout. Because clicking a theme applies it immediately, compare options with an approved pilot file or test copy. When the correct theme is selected, use Apply to close the selector and continue working.

Edit a theme and update linked emails

After a theme is applied, its General Styles controls become read-only. Hovering over them displays: To change theme styles, click the “Edit” button above.

Selecting the Edit theme unlocks the controls and opens the theme name field. 

You can:

• change the stored General Styles;
• select Save to update the theme;
• select Cancel to return to the styles stored before editing;
• use Undo/Redo while editing.

Theme creation and editing are controlled by the separate Themes permission, not by General Styles = manage. Standard roles include this access by default. If the team uses custom roles, enable Themes only for the members responsible for creating and maintaining shared styles.

Caption: General Styles become read-only after a theme is applied and are open for changes through Edit theme.

Detach, delete, or restore a theme

Selecting No Theme detaches the theme from the current email. The applied styles remain, and General Styles become editable again.

Deleting a theme removes it from the project and detaches it from connected emails and templates. Their visible styles remain in place. If a connected email is closed during deletion, the relationship is removed when that email opens or compiles.

Version History gives the user two recovery paths:

• keep original styles restores the historical email styles and removes the theme;
• use theme styles restores the selected version and then applies the current theme values.

Theme application and removal also appear as separate events in Version History.

Caption: Version History can restore the historical design without the theme or combine the restored version with the latest theme styles.

What this changes for your team: A campaign-specific exception does not require changing the shared source for everyone. You can detach the email, keep its current appearance, and edit its General Styles locally. If an unwanted change has already been made, Version History provides a recovery path without forcing the team to rebuild the email.

What themes do not replace

Themes provide one source for shared style defaults, but they do not hold every part of a brand system. Stripo keeps styles, repeated content, edit protection, brand documentation, assets, and testing in separate tools.

Themes manage shared defaults. They can set the approved appearance of headings and buttons, but they do not store a header, footer, navigation bar, or product card. Build those repeated structures as modules, using synchronized modules when one saved change must reach every connected instance.

Element Lock protects selected elements, settings, or styles from edits. A theme supplies shared values; it does not stop every local change by itself. The Brand Guidelines Kit records the wider brand system in a PDF and supporting materials, including approved assets and examples outside General Styles.

You might also like

Scaling the email design process without losing governance is easy with Element Lock

Local settings, inline CSS, custom CSS, and module-specific styles may retain their own values rather than inherit the theme default. Check this when converting existing templates, especially if a module uses Keep Module Styles.

Exported HTML is a static copy outside the theme relationship, so later theme changes do not reach it. After updating a theme, update the email in Stripo, run the accessibility and rendering tests, then export or push the revised version again.

How to roll out shared email styles across a team

Treat the rollout as a controlled production change. 

Start with one reference email and a small group of active files before connecting the rest of the library:

1. Assign an owner and a backup. Choose who maintains shared email styles, approves changes, and handles recovery when the main owner is unavailable.
2. Translate the brand guide into email rules. Record the approved HEX values, fonts and fallbacks, content width, spacing, backgrounds, heading hierarchy, and button styles from PDF and Figma.
3. Separate each brand layer. Put shared style defaults in Themes; repeated structures in modules; logos and imagery in asset storage; and copy, legal rules, and QA steps in their respective workflows.
4. Build one approved reference email. Use a real layout with headings, body copy, buttons, stripes, images, and common structures so the team can inspect each rule in context.
5. Save its General Styles as a theme. Name the theme clearly, confirm the saved values, and keep the reference email as the controlled source used for future reviews.
6. Preview the theme on several layouts. Try it on a newsletter, a promotional email, and a transactional layout without applying it first. Check whether each design keeps its intended hierarchy.
7. Test the rendered output. Review desktop and mobile versions, custom fonts and fallbacks, Outlook buttons, background images, padding, margins, and content width before linking production files.
8. Set theme access for approved roles. If the team uses custom roles, enable the Themes permission for the owner, backup owner, and approved designers. Standard roles include this access by default.
9. Apply the theme to a small batch. Start with a few active emails and templates. Check local styles, custom CSS, and modules that use Keep Module Styles before expanding the batch.
10. Verify automatic synchronization. Change one test value in the theme, then open, preview, and export several linked pilot files. Confirm that each action uses the current theme values without requiring a separate manual update.
11. Run the normal QA sequence. Check accessibility, links, desktop and mobile output, Outlook behavior, and rendering in the target ESPs after applying the theme.
12. Document detachment and recovery. Record how to select No Theme, what styles remain after detachment, and how to restore a version with Keep original styles or Use theme styles.

You might also like

Email accessibility checker: Find issues in your emails and fix them faster

Do not apply the theme to the entire library in one pass. Expand the rollout only after the pilot files have passed design review, rendering tests, and export checks.

Other situations where reusable themes help

Reusable themes also support style changes that go beyond a permanent company-wide guide:

• update an email library after a rebrand without rebuilding each design from the start;
• create a seasonal visual style for holiday campaigns while keeping the core brand intact;
• maintain separate themes for clients, product lines, or sub-brands within the same project;
• keep duplicated emails and localizations connected to the same shared style source.

For a seasonal campaign or sub-brand, Save as new creates an editable copy of the current theme and applies it after saving.

Wrapping up

For the brand manager in our opening scenario, the result is more than just another set of saved settings. It is one approved source for supported email styles, so five team members no longer need to copy every value from PDF and Figma files. This reduces style drift and lets final reviews focus on local exceptions, content, and rendering quality. 

FAQ

1. Can team members override a theme’s colors or fonts?

Linked General Styles are not edited directly from the email. Creating or changing the shared theme requires the Themes permission. Standard roles include this access, while custom roles must be configured separately. Local element styles, inline or custom CSS, and modules with Keep Module Styles may still retain their own values.

2. Will a theme update existing emails and templates?

Yes, but only when the email or template is linked to that theme. Stripo synchronizes the current theme values when the linked item is opened in the editor, previewed, or exported. No separate outdated-style confirmation is required.

3. What happens to copies and localized emails?

A duplicate of a themed email keeps the same theme. An email created from a themed template also inherits it. Localizations receive the theme from the main email, and detaching the main version also detaches its localizations.

4. What happens when a theme is removed or deleted?

Selecting No Theme removes the relationship but leaves the applied appearance in place, making General Styles editable. Deleting a theme also detaches connected items without removing their visible styles. Stripo warns when other emails or templates may use it.

5. Will theme changes update HTML already exported to an ESP?

No. Exported HTML is a separate copy outside the theme relationship. Changes do not reach emails already exported, pushed to an ESP, scheduled, or sent. Update the source in Stripo, test it, and export or push a new version.

6. Can a theme store customize fonts and Outlook button settings?

Yes. Themes can store custom font links and the Support for Outlook setting used for VML-based buttons, along with supported General Styles. Email-client support still varies, so test the final output in the target desktop, mobile, and webmail environments.