Email designer and reusable content blocks

What it does

The email designer is the drag-and-drop canvas where you build real-time journey emails, backed by a raw HTML editor for anything the canvas won't do. Content blocks are saved fragments — an element, or a whole laid-out section — that you drop into multiple emails instead of rebuilding the same footer twenty times.

Key facts

The designer has four panes you'll actually use: Toolbox (drag elements onto the canvas), Properties (style the selected element), General styles (message-wide fonts, colours, background) and the theme pane behind the brush icon, which styles every element of a given type at once.
The HTML button gives you the raw source. Microsoft supports the designer; they explicitly do not support custom HTML you paste in.
Size limits are real and enforced at different points: keep the message source under 100 KB, Gmail clips anything past 102 KB, and the journey error check fails the email outright at 128 KB. Referenced images don't count towards this — only the text and markup.
Email header fields (To address, From address, From name, Reply-to address, Email template, Email type, Content type, Language) sit on the canvas, not in the right-hand pane. Form customisations target the Email Header form.
Email type is commercial or transactional. Commercial email will not go live without a preference centre link.
Plain text is generated for you — Automatically generate plain text defaults to Yes, and turning it off means you own the plain text version from then on.
Templates are copied, not linked. Content from the template lands in the email and stays there; switching template afterwards discards the current content except the header.
Content blocks come in two shapes: element blocks (no layout, they take the shape of whatever column they land in and pick up the host email's theme) and section blocks (they bring their own layout with them).
Content blocks also come in two update behaviours: static (each email gets its own copy, updates never reach existing emails) and dynamic (the email stores a reference and the content is fetched at send time, so updates propagate everywhere). Dynamic content blocks are in preview and gated behind Settings > Feature switches > Email editor > Dynamic content blocks (preview).
Blocks have a Ready to send / Draft state. Ready to send means insertable but locked; you flip back to Draft to edit. Static blocks can additionally be marked Protected so nobody edits the copy after insertion. Dynamic blocks are always protected.

When to use / skip

Use the designer for everything and touch the HTML editor only when you have to — every time you hand-edit source, you hand yourself the support burden for that email forever. Clients arriving from a third-party ESP will want to paste their existing HTML wholesale; that usually works, and then breaks in an interesting way at the worst moment.

Content blocks earn their keep the moment more than one person is writing emails, or the moment legal text appears in more than three places. Static blocks are the safe default. Dynamic blocks are genuinely useful for content that must always be current — a weekly promotion panel, a product spec — but they're still preview and they change what "an email" means, because the content is resolved at send rather than at publish. On a first delivery I'd ship static blocks and revisit dynamic later.

Configuration decisions

Whether HTML editing is available to content authors at all, or restricted to a small group — designer feature protection exists precisely for this.
Static versus dynamic for each reusable block, decided per block, not as a blanket policy. Anything legal or regulated is a strong candidate for dynamic; anything used for journey branching cannot be.
Whether reusable content ships as a template (one per email, whole layout) or a section content block (many per email, composable). Most brands need both.
Protected or not on static blocks — protecting stops well-meaning marketers editing the footer, and also stops them fixing a typo without going back to the block.
Tagging convention for the block library. The picker searches name and tags, and an untagged library of forty blocks is unusable within a quarter.
Whether to keep automatic plain text generation, or write plain text by hand for high-volume sends.

Gotchas

Links inside a dynamic content block can't be used for journey branching. If your journey needs an "if clicked this link" branch, the link has to live in the email or in a static block.
Dynamic content blocks don't render in Preview and test or in test sends. Microsoft flagged a fix rolling out through 31 May 2026 — confirm behaviour on the environment in front of you rather than trusting the release note.
Updating a dynamic block while a live journey is mid-send means recipients get different versions of the same email depending on when they were processed. That is working as designed, and it is not what the client expects.
Static blocks don't propagate. The block's Settings pane lists which emails and templates use it, and updating those is a manual job.
Changing the template on an existing email throws away the body. People do this while "just trying something" and lose an afternoon.
The designer can't simulate Outlook. Test sends into the client's actual Outlook build are the only reliable check, and local add-ins can produce duplicated or mangled elements you'll never reproduce.

Consultant notes

Demo the block library, not the canvas. Everyone assumes drag-and-drop works; what sells the platform is showing a footer change landing in every email at once.
Agree the HTML policy in writing before build starts. "We'll just paste our agency HTML in" is a decision with a support consequence, and the client should own it.
Check the 128 KB ceiling early if the client's existing emails are image-map heavy or come out of a template engine that emits verbose markup.
Before go-live, run a test send to Outlook desktop, Outlook web, Gmail and one mobile client, and get someone on the client side to sign off on the rendering rather than doing it yourself.
Push back on building fifteen templates. Two or three templates plus a solid block library covers more ground and ages better.

Worth another look once dynamic content blocks leave preview, or if the designer's HTML support stance changes.