Lesson 6. Background Images in Emails

When creating any kind of email campaign, it's important to think not just about the text but also the visuals: the email's design should reinforce brand identity. So that the moment a reader opens the email, they know exactly who it's from — from the very first second, the very first heading, the very first main banner.

That's why the following are important components of email design:

a consistent style for brand recognition;
unified fonts and styling;
the correct use of images.

Today we'll focus on that last point in more detail — let's talk about background images and the main banner.

The email background

Essentially, the email background is the table's background. And the table is the container we're going to fill with that background:

Here, the bgcolor attribute sets the cell's background to white. So our container's background will be white.

Another option is to fill the background with an image taken from Figma. For example, a gradient like this, sized 600x400:

By the way, gradients don't work in emails, so you can only add this effect to a campaign using an image.

Note: images need to be saved for web, but Figma already saves them in the right format.

We export the gradient from Figma at 2x size in PNG format and save it in the same folder as our code. Let's say we name it bg.png. Then our code looks like this:

Here, we use the max-width property to set the width of our table [and its background], and the height attribute on the <td> tag to set the cell's height [and its background]. Notice that we set the table's height because it has no content other than the background. In other cases, height adjusts based on content — we'll cover this in more detail a bit later [spoiler: using the height attribute is possible, but it can cause adaptation issues].

The background attribute points to the relative path of our image, but this notation [background="bg.png"] was used for older platforms, so it can be omitted.

Today, developers use style properties instead: background-image defines the background image for an element. Its value [url] points to the file's path — it can be written with quotes [double or single] or without them.

The next property — background-position — sets our background's position. Whenever we specify a background, we always define its position — this is needed so that on mobile adaptation, the background image doesn't shift to one side. The background-position property has two values: horizontal position [left, center, right] and vertical position [top, center, bottom]. Both are written separated by a space with no comma, and the order doesn't matter: top center means our background will "attach" to the top center of the email.

In mobile adaptation, layout elements stack, which increases the container's height and leaves empty space below it. We'll talk about stacking a bit later, but what do we do about the background? This is where the background-repeat property comes in, which determines how the background image repeats. A value of no-repeat sets a single background with no repetition. Another value [repeat] tiles the background infinitely both vertically and horizontally, trying to "pave over" all the empty space.

Our background is 600x400, but we exported it at 2x for Retina displays. So the image's actual dimensions are 1200x800. To make sure not a single precious pixel gets lost, we set the background-size property, which scales the background. A value of cover shrinks the image to fit the container's width and height while preserving proportions. This is essentially how Retina adaptation works for background images.

For the last property's value [bgcolor], you should specify a color as close as possible to the background image's color. Why does this matter: if the images in the email somehow fail to load, the browser will show this background color instead.

Picture this scenario: you receive an email with a white background, and one of the blocks has a black background image with white text on top of it. What happens if the image doesn't load? Nothing dramatic — you just won't see white text on a white background. To be more precise, you won't see any text at all. That's why it's better to specify the bgcolor property.

The campaign background for Outlook

The code above is enough to create the email's background. But a reasonable question comes up: will Outlook actually see all these background properties? No, it will only see bgcolor. So we use a construction like this:

<!—[if gte mso 9]>

<v:rect xmlns:v=»urn:schemas-microsoft-com:vml» fill=»true» stroke=»false» style=»width:600px;height:400px;»>

<v:fill type=»frame» src=»bg.png» color=»#d9544d» />

<v:textbox inset=»0,0,0,0″>

<![endif]—>

<div><table><tr><td>content</td></tr></table></div>

<!—[if gte mso 9]>

</v:textbox>

</v:rect>

<![endif]—>

</td></tr>

</table>

Let's break down the conditional comment: the first line [<!--[if gte mso 9]>], as always, indicates that this information is for Outlook. The next line draws a 600x400 rectangle in VML, and below it, the fill type element fills it with the background. The <v:textbox inset="0,0,0,0"> construction zeroes out this rectangle's inner padding. The second conditional comment essentially "finishes drawing" our rectangle with the background.

Essentially, this is the wrapper for our background. Now let's talk about how to create the main banner — it can also be built using a background image.

The main banner

This banner is called "main" for a reason — it's the first screen, which often reflects the essence of the entire campaign and grabs attention:

A banner is often more than just an image — it usually consists of several elements: an image, a heading, and a button. Sometimes a promo code is included right on the banner too.

You can make a banner like this fully clickable and build it as a single image. To do this, export the entire banner as one image from Figma: with the text, button, and all illustrations included. You already know the code:

</a>

The main advantage of building a banner as an image is that it's simple. You can use your brand fonts without worrying about whether they're web-safe. But the downsides outweigh that. At the very least, scaling gets distorted during adaptation to different screens [the whole image shrinks]. That's why we're in favor of layer-based markup.

Usually, the developer assembles the banner from layers that the designer, in turn, needs to plan for when drawing up the mockup. The image [in our case, the background image] is the first layer, with text, a logo, or other elements placed on top of it. This does take a bit more effort from the developer than building it as a single image, but it's nothing complicated. And look at all the advantages!

First, a banner like this adapts better. On an image-based banner, when it scales, the button shrinks a lot, and the heading or logo gets smaller too. We want them to stay noticeable.

Second, a banner split into layers is more versatile. If you need to make edits to one of the elements, it's much easier to do and doesn't require bringing in a designer.

Here's what layer-based markup for a banner like this looks like:

There's also another way to build a banner: using two columns. A banner like this can easily be adapted for the mobile version. But we'll cover that in the next lesson — let's move on to grids and stacking.

📸 Background images don't work everywhere. In Letteros, every template is tested for compatibility — the markup is safe!