How to Build Responsive Emails


Want to build your email list? Click here to start the “Every Page Rule” training video!

Email has the best ROI of any marketing channel. For every dollar you spend on email, you stand to make up to $44 back. But that’s potential, not guaranteed. The majority of emails are opened on mobile devices now, and for some brands that figure is 70% or more, so email that works on mobile is an absolute must. 80% of your audience will delete an email that doesn’t look good on their mobile device.

Emails that won’t show on mobile? Don’t even bother sending them.

But mobile friendly email is hard to pin down. Think about the difference between mobile devices: are we really saying your iPad and my Samsung mini should be displaying exactly the same email? With the difference in screen size alone between big tablets, 2-in-1 devices and smaller smartphones that doesn’t sound like the smartest solution.

Responsive design allows marketers to send emails that display correctly on any device by altering themselves in response to the device they’re being viewed on. That way, your emails always look good.

What kind of responsiveness are we talking about here?

  • Changing hierarchy
  • Responsive fonts
  • Changing navigation
  • Colors
  • Layout
  • Responsively scale images
  • Add padding
  • Change, reveal or hide content

The same email viewed on two different devices will sometimes look very different.


How do Responsive Emails Work?


Responsive emails work by using something called a “media query.” Don’t code? Don’t look away. You don’t have to understand the technicalities to get the idea. It’s simple. Web stuff (see, we’re avoiding technicalities) runs on two sets of instructions, HTML and CSS. HTML tells a device what text and pictures to show you; CSS tells it how to display that information. A gross oversimplification, but you get the idea.


Which Device?


Media queries are a CSS element that asks the device what kind of device it is. In response, your email will select the right set of rules to display well on that device.


Under the Hood:


Here’s a sample media query:


@media screen and (max width: 480px)


This is a logic gate: if this, do that. In this case, if the screen is 480px or smaller, it will fork the app that’s viewing the email onto the next piece of code:


table [class=”wrapper”] {

width: 100% !important;


This is CSS — the code that tells things what to look like. Here, it’s instructing the app to resize the email —  to respond to the size of the screen. It’s the heading of a list of new parameters that resize and redesign the email, right down to font size and colors. In essence, you’re sending two emails in one and letting the screen size of the device select which email the user sees.

If you code, this isn’t tough: if you don’t it’s someone else’s job. So let’s talk about designing the emails themselves, now we’ve had a quick look under the hood.


Designing Responsive Emails: Single Column


The simplest way to design responsive emails is to use single column layouts. That way, all you have to worry about is rearranging the elements to scale: you can have one column that stays one column.

This is obviously the simplest approach. When done well, it will look good on any device. And there’s a lot to be said for simplicity, with simpler, high white space designs sweeping the web and some of the most successful emails being short and to the point, linking back to the actual content.

For instance, this from Hubspot:


And this from Spoon:


Are both single-column emails.

It’s well worth thinking if you could redesign your emails to be single column. Not only is the business of making them responsive a whole lot easier, but you’ll have an easier time


Under the Hood:


Single column layouts use standard adaptive layout coding where you just adjust table width. After the logic gate code, you’d just:


<table cellspacing=”0″ cellpadding=”0″ border=”0″ width=”600″>
<!– email content –>


Apart from fixing images and font size, you’re good to go.


Designing Responsive Emails: Multicolumn


When you have an email where you want to send several discrete pieces of information, multicolumn makes the most sense. For instance, anything with a sidebar, or an offset image, as well as a multibox newsletter or offer email.

If you’re advertising different products, for instance, you’ll probably want to go this way. And if you’re not asking for one thing, selling one thing, or pushing one call to action, this layout can make more sense, for one simple reason: more content ‘above the fold.’ You’ll get more content on the preview screen, and your side panel can contain a guide to the email’s content that will encourage the reader to view all the content.

However, with a smaller screen in multicolumn emails you’ll have to place one column above the other and convert the email to one long, scrollable email with separate boxes, something you’ll increasingly see in desktop email design too.


So weigh your audience and your campaign, and consider how you plan to resolve display issues before you jump down this route.


Under the Hood:


You can either use nested tables or changing table cells “display” property.

Nested tables are usually considered to be the best way to make sure that any email client or app will display the email well. But they’re terrible to code for and therefore it’s likely that, A, you won’t want to do them yourself or in-house, and B, your email provider won’t want to do them either and won’t offer them.

If you feel there’s an unavoidable reason for using this method, though, it’s based on the align=left attribute, which makes tables align horizontally. Every element – every column -must have a specific width, and these plus spacer columns must add up to the width of the container. When the width of the container decreases, the code tells the columns to drop underneath each other instead, like this:


table[class=”body_table”] {
width: 600px;

table[class=”column_table”] {
width: 180px;

table[class=”spacer_table”] {
width: 30px;

@media only screen and (max-width: 480px) {
table[class=”body_table”] {
width: 420px!important;
table[class=”column_table”] {
width: 100%!important;


It shouldn’t be much of a surprise that they don’t work well on all versions of Outlook — what does? — but otherwise, this is pretty device and client agnostic. But it’s hard and time consuming.

A better method for most purposes is to change the properties of the default tables cells ‘display’ attribute when the device screen measurement changes. This makes the cells stack vertically. So you’d do something like:


table[class=”body_table”] {
width: 600px;
table td[class=”column”] {

@media only screen and (max-width: 480px) {
table[class=”body_table”] {
width: 440px!important;

table td[class=”column”] {
       display: block!important;


Font Size:


On mobile screens, and especially smaller phone screens, font size needs to be larger. People read desktop screens by scanning down a static page with their eyes; they read a mobile screen by scanning down the screen with their thumb. That means you need to address font size, or when the email is resized down it will go from ‘meant to be viewed on a much larger screen’ to ‘are those words?’

When you’re considering font size in responsive emails, the rules of best practice apply: have at least three sizes, for desktop, tablet and phone, and err on the side of larger with phone especially. Then A/B test — and view them yourself on a couple of different phones to ascertain which works best.


Under the Hood:


To build automatic font resizing into your emails, you’d want to make it dependent on screen size directly.

You’d use CSS like:


@media only screen and (max-width: 767px) { h1 { font-size: 3em; } h2 { font-size: 2em; } }


What About Images?


Most emails are nothing without images. True, I got this from Neil Patel the other day:


But for the most part, emails are built from and on images as much as websites are. And obviously, these images seriously need to be resized for smaller screens — or you’re going to be giving your readers a close-up of some pixels. Fortunately, it’s one of the easiest issues to solve.


Under the Hood:


There are several options to solve this one. At the simpler end, you can just tie image size to overall email size, by doing:


(img {max-width: 100%;}


Alternatively, you can use media queries to send two images and let the device size decide which image gets shown:


@media only screen and (max-device-width: 480px) {
   img.original_img {
       display: none;
   .substitute_image {
       background-image: url(background_image.png);
       width: 440px !important;
       height: 240px !important


By assigning a max device width to the original image you let the viewing device screen size choose between original and substitute images. This approach carries risks, though, in that all  images are loaded, not just those that are chosen to show – even images that are hidden by CSS are actually loaded into the email client. In clients that don’t support responsive, that can look bad.


Finally, you can assign a single image to both the img tag and the background-image source, though this makes choosing the image harder. You’d use code like:


@media only screen and (max-device-width: 480px) {
   img.original_img {
       display: none;
   .substitute_image {
       background-image: url(original_image_source.jpg);
       background-position: center center;
       background-repeat: no-repeat;
     width: 440px !important;
     height: 120px !important


This one gets you past a few media queries breakpoints, as well as leaving the client with less to load and less to go wrong.

When an Email Client Doesn’t Support Responsive:


It’s important to note that, although media queries (you’ve been reading the ‘under the hood’ bits, right?) refer to screen size, the thing that decides whether all the code of your responsive email actually gets run or not isn’t the device. It’s the application – or sometimes the operating system. Some email clients attempt responsiveness off their own bat, some just ignore your carefully crafted code, others display it in all its glory. How do you cope with this?


First, these clients will probably display your code fine:

  • Blackberry 0S7
  • Blackberry Z10
  • Windows Phone 7.5
  • Android 4.x email.OEM app
  • iOS Mail app

And these won’t:

  • iPhone Gmail app
  • iPhone Mailbox app
  • iPhone Yahoo Mail app


Yeah,thanks iPhone. Hold on, though –

  • Android Gmail app
  • Android Yahoo Mail app
  • Blackberry OS 5
  • Windows Mobile 6.1
  • Windows Phone 7
  • Windows Phone 8

So if you’re sending an email to a client that doesn’t support responsive, what happens?

Basically, they’ll render the full size email in some way. Sometimes they’ll just show the whole thing, sometimes they’ll zoom in. In Gmail’s case, they’ll automatically display a usually-better-than-nothing,  generically “mobile-friendly” version.

Wrapping Up:

Putting yourself in your recipients’ shoes is the second best way to test if your emails are working or not. So view your emails on as many different devices as possible. Don’t rely on emulators: send the emails and view them across apps, OSS and devices to find out how your campaigns will look.

If that’s the second best, what’s the best? Check with your users by A/B testing, experimenting with responsive implementation as well as other email aspects like copy and images to find the winning combination.

Do you have any other tips for increasing the responsiveness of email? Share your stories in the comments below!


Back to posts
Read previous post:
You Are Probably Getting Stupid Results from A/B Testing. Here’s Why.

You know the drill. Every time you change something on your site or app, you must test – test for...