Guía completa de diseño responsive para email / newsletters
El diseño responsive para email funciona de forma radicalmente distinta al responsive web. No hay flexbox, no hay grid, CSS externo se ignora en la mayoría de clientes de correo, y Gmail en Android sigue haciendo lo que le da la gana con tu código. Esta guía cubre lo que realmente funciona en 2026, sin rodeos. Además te dejo un HTML ejemplo para que puedas descargarte.
Por qué el email HTML es un caso aparte
Cuando diseñas para web, el peor escenario es un navegador con cuatro años de antigüedad. Cuando diseñas un email, el peor escenario es Outlook 2016 renderizando con el motor de Word —sí, Word—, Gmail stripeando tu <style> si va en el <head>, y Apple Mail aplicando su propio redimensionado de fuentes sin pedirte permiso.
La fragmentación de clientes de correo en 2026 sigue siendo brutal. Según los datos de Litmus, Gmail concentra alrededor del 27% de las aperturas globales, Apple Mail otro 26%, y Outlook (en sus múltiples versiones) ronda el 4-6%. Pero ese 4-6% de Outlook es habitualmente el 100% de los empleados de una empresa corporativa que recibe tu newsletter B2B.
Todo esto significa que el enfoque correcto no es «diseñar como en web y adaptar». Es empezar desde la estructura que el email necesita y añadir mejoras progresivas encima.
La base que no ha cambiado: tablas como estructura
Sí, tablas. No es nostalgia, es pragmatismo. Las tablas son el único sistema de layout que funciona de forma consistente en todos los clientes de correo relevantes, incluido Outlook. Flexbox y CSS Grid simplemente no están disponibles de forma fiable en el contexto del email.
La estructura base de cualquier email responsive parte de una tabla contenedora centrada, con un ancho máximo fijo (habitualmente 600px, que es el estándar de la industria para contenido de email) y un ancho del 100% para que se adapte en móvil.
Pero aquí está el matiz que marca la diferencia entre un email que se ve bien y uno que se rompe: el sistema de columnas responsive en email no usa media queries como primera opción. Usa un patrón llamado hybrid o spongy layout, que permite que las columnas se apilen sin depender de que el cliente de correo soporte media queries.
El patrón hybrid: columnas que se apilan solas
La idea es simple pero contraintuitiva. Cada columna tiene un max-width fijo (el ancho que quieres en desktop) y un width: 100%. Cuando el contenedor es suficientemente ancho, las columnas se colocan en línea. Cuando se estrecha, se apilan. Sin media queries.
<!-- Contenedor principal del email -->
<table role="presentation" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr>
<td align="center" style="padding: 0 10px;">
<!-- Tabla de contenido: máx 600px, se estrecha en móvil -->
<table role="presentation" width="100%" style="max-width: 600px;" cellspacing="0" cellpadding="0" border="0">
<!-- FILA DE DOS COLUMNAS: patrón hybrid -->
<tr>
<td style="padding: 0;">
<!-- Columna izquierda: ocupa la mitad en desktop, 100% en móvil -->
<div style="display: inline-block; vertical-align: top; width: 100%; max-width: 280px;">
<table role="presentation" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr>
<td style="padding: 20px; background-color: #f5f5f5;">
<p style="margin: 0; font-family: Arial, sans-serif; font-size: 16px; line-height: 1.5; color: #333333;">Columna izquierda</p>
</td>
</tr>
</table>
</div><!--
--><!-- Sin espacio entre divs: los comentarios eliminan el espacio inline-block -->
<!-- Columna derecha: mismo patrón -->
<div style="display: inline-block; vertical-align: top; width: 100%; max-width: 280px;">
<table role="presentation" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr>
<td style="padding: 20px; background-color: #ffffff;">
<p style="margin: 0; font-family: Arial, sans-serif; font-size: 16px; line-height: 1.5; color: #333333;">Columna derecha</p>
</td>
</tr>
</table>
</div>
</td>
</tr>
</table>
</td>
</tr>
</table>
El truco del comentario HTML entre los <div> (el <!-- --> al final de cada bloque) elimina el espacio en blanco que los navegadores insertan entre elementos inline-block y que desplazaría las columnas. Es un hack de los de toda la vida, pero funciona en todos los clientes.
Media queries en email: dónde sí funcionan y dónde no
Las media queries funcionan en Apple Mail, iOS Mail, y la mayoría de clientes basados en WebKit. No funcionan en Gmail (web ni Android), Outlook, ni Yahoo Mail. Por eso el patrón hybrid como base: no depende de ellas.
Pero cuando funcionan, sí añaden mejoras importantes. El lugar correcto para ponerlas en un email es un bloque <style> dentro del <body>, no en el <head>. Gmail elimina el <head> completo, pero respeta estilos en el <body> en su versión web (aunque no en Android).
/* Bloque de media queries para clientes que las soportan */
/* Va dentro del <body>, en un <style> justo antes del email --> */
@media screen and (max-width: 600px) {
/* Forzar ancho completo en móvil */
.email-container {
width: 100% !important;
max-width: 100% !important;
}
/* Apilar columnas que el hybrid no pudo apilar */
.col-half {
display: block !important;
width: 100% !important;
max-width: 100% !important;
}
/* Tipografía más grande en móvil */
.email-body p {
font-size: 17px !important;
line-height: 1.6 !important;
}
/* Botón a ancho completo en móvil */
.btn-cta {
display: block !important;
width: 100% !important;
text-align: center !important;
}
/* Ocultar elementos solo para desktop */
.hide-mobile {
display: none !important;
height: 0 !important;
overflow: hidden !important;
}
}
El !important aquí no es mala práctica: es necesario para sobreescribir los estilos inline que los clientes de correo procesan con mayor prioridad.
Tipografía en email: lo que puedes y no puedes usar
Las web fonts en email son un tema con sus propias reglas. Apple Mail y algunos clientes iOS soportan @font-face y Google Fonts via <link>. Gmail no. Outlook, tampoco.
La estrategia correcta es declarar la tipografía personalizada para quien la soporta y definir un stack de fallback cuidado para quien no. No «Arial, sans-serif» sin más. Un stack pensado:
/* Stack tipográfico para email: de preferida a universalmente disponible */
font-family: 'Inter', 'Helvetica Neue', Helvetica, Arial, sans-serif;
/* Para serif si el contexto lo pide */
font-family: 'Georgia', 'Times New Roman', Times, serif;
/* Tamaños mínimos: nunca bajar de 14px en cuerpo, 22px en H1 */
/* iOS aumenta automáticamente fuentes <13px, lo que rompe layouts */
font-size: 16px; /* body */
font-size: 24px; /* h2 */
font-size: 32px; /* h1 */
El mínimo de 14px en cuerpo no es una preferencia estética: iOS Mail escala automáticamente cualquier fuente menor, lo que puede romper columnas y layouts enteros si no lo anticipas.
Botones: el único método que funciona en todos los clientes
Los botones en email no son <button> ni <a> con estilos aplicados directamente. El método más robusto —y el que Litmus y Campaign Monitor llevan recomendando años— es el botón con padding en la celda de una tabla:
<!-- Botón responsive que funciona en Outlook y el resto -->
<table role="presentation" cellspacing="0" cellpadding="0" border="0" style="margin: 20px auto;">
<tr>
<td align="center" style="border-radius: 6px; background-color: #1a1a2e;">
<a href="https://tuurl.com"
target="_blank"
style="display: inline-block;
padding: 14px 32px;
font-family: Arial, sans-serif;
font-size: 16px;
font-weight: bold;
color: #ffffff !important;
text-decoration: none;
border-radius: 6px;
background-color: #1a1a2e;">
Ver la guía completa
</a>
</td>
</tr>
</table>
El color: #ffffff !important en el <a> es necesario porque algunos clientes de correo aplican su propio color a los enlaces y lo sobreescriben si no lo fuerzas. El background-color duplicado en la celda y en el <a> es para que Outlook, que no renderiza el border-radius pero sí el color, al menos muestre el fondo correcto.
Errores que cuestan aperturas y conversiones
- Imágenes sin atributo
alt: muchos clientes bloquean imágenes por defecto. Un email con imágenes sin alt y sin texto alternativo funcional aparece como una caja vacía. El alt no es accesibilidad opcional, es contenido de respaldo obligatorio. - Ancho fijo sin
max-width: ponerwidth="600"en una tabla sinmax-width: 100%en móvil hace que el email aparezca cortado en pantallas estrechas. Siempre los dos:width="600"para Outlook (que no entiendemax-width) ystyle="max-width:600px; width:100%"para el resto. - Padding solo en CSS: Outlook ignora
paddingen muchas celdas. Usacellpaddingen la tabla o combínalo con el atributoalignen la celda. El padding en CSS queda para los clientes modernos como mejora. - Dark mode sin preparación: Apple Mail y varios clientes aplican dark mode automáticamente, invirtiendo o ajustando colores. Si tu email tiene texto oscuro sobre fondo blanco sin declarar colores explícitos en todos los elementos, en dark mode puede quedar ilegible. La solución mínima: declarar
colorybackground-coloren cada celda relevante, nunca dejar herencia implícita. - Fondo de color en body sin respaldo: el
background-coloren el<body>solo funciona en algunos clientes. Para garantizar el color de fondo en Outlook, necesitas una tabla wrapper awidth="100%"con el color declarado en la celda.
Herramientas para no volverse loco testando
Litmus sigue siendo el estándar del sector para previsualizar emails en más de 90 clientes sin necesidad de tener cada cliente instalado. Su plan más básico ya cubre los clientes más críticos. Email on Acid es la alternativa con precio más competitivo.
Para desarrollo, MJML es un framework que genera HTML de email compatible desde una sintaxis mucho más legible. Su compilador maneja los hacks de Outlook, el padding en tablas y el patrón hybrid de forma automática. Si vas a hacer varios emails o un sistema de plantillas, el tiempo de aprendizaje se amortiza rápido.
Y para testear el dark mode sin herramientas externas: en Apple Mail puedes activar el dark mode del sistema y previsualizar directamente. En Gmail web, el modo oscuro se activa en la configuración del sistema operativo (macOS/Windows) y Gmail lo adopta automáticamente desde 2023.