The email builder

This page covers building the body of an email: the drag and drop editor for people who do not want to write HTML, the plain HTML route for people who do, and the handful of things that reliably break an email once it leaves your screen.

Two ways to build#

Drag and drop. You assemble the email from blocks. You never touch markup, and the output is table-based HTML that holds together across mail clients. This is the right choice unless you have a specific reason not to use it.

Your own HTML. You paste a full HTML document and IGSendMail sends it as written. Choose this when you have a hand-built template, when your design team ships you finished markup, or when you are reusing a layout from elsewhere. Nothing is added to your markup except the tracking and unsubscribe handling, so everything else is yours to get right.

You pick the approach when you start building the campaign's content. Switching from drag and drop to raw HTML after you have built a layout will generally lose the block structure, so decide early.

Working with blocks#

In the drag and drop editor, the email is a stack of blocks. Common ones are text, image, button, divider, spacer, and a container that holds two or more columns side by side.

A few things that make block layouts hold up:

• Keep the email one column on mobile. Multi-column blocks stack vertically on narrow screens. Two columns is usually fine. Four columns stacked into four full-width rows rarely reads the way you pictured it.
• Set a background color on the outer body, not only on blocks. If the email body is transparent, dark mode in some clients will paint whatever it likes behind your text.
• Do not put important text inside an image. See below.
• Use padding, not empty text blocks, for spacing. Empty paragraphs collapse inconsistently between clients.

Images

Upload images at roughly twice the width you want them displayed, then set the display width in the editor. That keeps them sharp on high-density screens without shipping a file that is four times larger than it needs to be.

Always set alt text. Many mail clients block images by default until the reader clicks to load them, and a lot of readers never click. Alt text is what those people see instead.

Buttons

Use a button block rather than an image of a button. A real button renders when images are blocked, scales with the reader's font size, and stays tappable on a phone.

Give the tap target some room, roughly 44 pixels of height including padding, so it can be hit with a thumb. Write the label as the action, "Book a call" rather than "Click here", so it makes sense read out of context.

Preview on mobile#

More than half of most lists will open on a phone. Use the editor's mobile preview before every send, and check three things:

1. The subject line and preview text are not truncated in a way that changes their meaning.
2. Nothing scrolls sideways. A fixed-width image or a wide table is usually the culprit.
3. The main call to action is visible without a long scroll.

Previewing in the editor tells you about layout. It does not tell you how a specific mail client will render it. Send a test to a real address at a provider your audience actually uses, and open it on a phone.

The unsubscribe link#

Every campaign must include a working unsubscribe link. This is not optional and it is not a formality. Mailbox providers treat a missing or broken unsubscribe path as a strong spam signal, and the alternative for an annoyed reader is the "report spam" button, which does far more damage to your sending reputation than an unsubscribe.

Put it in the footer, in a readable size, in a color that has contrast against the background. Do not use white text on white, and do not bury it under three lines of legalese. If you edit a template's footer, confirm the unsubscribe link survived the edit by clicking it in a test send.

Pasting from a word processor#

The same applies when you paste a block of copy into an HTML template. Strip it to plain text first, then mark it up.

If something goes wrong#

Fonts look different in the sent email. Mail clients support a narrow set of fonts and ignore most web fonts. Always specify a fallback stack ending in a generic family, and expect that some readers see the fallback.

The layout breaks in one client only. This is nearly always a CSS feature that client does not support. Move layout onto tables and inline the styles rather than fighting it in a stylesheet.

The email is slow to load, or gets cut off. Check total image weight and compress anything oversized. Some providers also clip long messages, adding a "view entire message" link partway down, so keep the important content near the top.