Crear emails responsive puede parecer una especie de castigo técnico si vienes del desarrollo web moderno. Estás acostumbrada a trabajar con flexbox, grid, componentes reutilizables, estilos organizados y layouts que responden con bastante elegancia. Pero, de repente, entras en el mundo del email marketing y todo cambia: aparecen las tablas HTML para email, los estilos inline, las limitaciones de Outlook y ese miedo constante a que algo se vea bien en Gmail pero se rompa en otro cliente de correo.
Y sí, es normal preguntarse: ¿de verdad seguimos usando tablas HTML para maquetar emails en pleno 2026? La respuesta es que sí, aunque con matices. Las tablas no se usan porque sean la opción más moderna ni la más cómoda, sino porque siguen siendo una de las formas más fiables de conseguir compatibilidad entre distintos clientes de correo.
La buena noticia es que no necesitas volverte loca escribiendo veinte niveles de tablas anidadas sin criterio. Hoy puedes crear emails responsive con tablas HTML de forma más ordenada, predecible y mantenible si entiendes qué papel cumple cada capa, qué CSS puedes usar con seguridad y cuándo conviene apoyarte en herramientas como MJML.
Si estás empezando en este tema, puede venirte bien complementar este artículo con la guía sobre qué es MJML y por qué facilita la maquetación de emails responsive, porque te ayudará a entender cómo simplificar parte del trabajo sin perder de vista lo que ocurre por debajo.
Por qué los emails responsive siguen usando tablas HTML
Cuando hablamos de tablas HTML en email, no hablamos de una recomendación estética. Hablamos de una solución práctica ante un entorno bastante irregular. El problema principal es que los clientes de correo no se comportan como los navegadores modernos. Gmail, Outlook, Apple Mail, Yahoo Mail y otros clientes interpretan el HTML y el CSS con diferencias importantes.
En una página web puedes crear un layout responsive con display: grid, display: flex, gap, clamp() o incluso container queries. En email, en cambio, muchas de esas decisiones pueden fallar o no comportarse igual en todos los entornos. Por eso las tablas siguen teniendo tanto peso: permiten crear una estructura base relativamente estable.
No son cómodas, no son bonitas y no son semánticamente ideales para maquetar diseño visual, pero ayudan a que el email mantenga su forma en clientes que todavía no interpretan CSS moderno de manera consistente.
La diferencia entre maquetar una web y maquetar un email
El error más común al empezar con emails responsive es intentar aplicar la misma mentalidad que usarías en una web. Pero un email no es una landing page. No tienes el mismo control sobre el entorno, no puedes asumir que todo el CSS será respetado y tampoco puedes depender de archivos externos como harías en un proyecto frontend tradicional.
En email, la pregunta no es solo: “¿este diseño queda bonito?”. La pregunta real es: “¿este diseño se mantiene suficientemente bien en la mayor cantidad posible de clientes de correo?”
Ese cambio de enfoque modifica por completo la forma de trabajar. En lugar de perseguir una maquetación perfecta al píxel, conviene pensar en sistemas robustos: una estructura sencilla, una anchura máxima razonable, columnas que puedan apilarse, botones legibles y una versión móvil que no obligue al usuario a hacer zoom.
No se trata de amar las tablas, sino de usarlas con estrategia
Las tablas HTML en email son una herramienta. Nada más. No hace falta defenderlas como si fueran modernas ni odiarlas como si fueran el enemigo absoluto. Lo importante es entender cuándo cumplen una función útil.
Una tabla puede servir como contenedor principal del email. Otra puede organizar una sección de dos columnas. Otra puede asegurar que un botón se vea correctamente en distintos clientes. El problema aparece cuando se usan tablas sin estructura, sin nombres de clases claros y sin una lógica de componentes.
Ahí es cuando el email se convierte en una maraña difícil de mantener. Pero si trabajas con una arquitectura clara, incluso una plantilla basada en tablas puede ser relativamente limpia.
La estructura base de un email responsive con tablas HTML
Antes de entrar en trucos responsive, necesitas una base sólida. Un buen email HTML suele tener tres niveles principales: el fondo general, el contenedor central y los bloques de contenido.
La idea más habitual es trabajar con un contenedor de unos 600 px de ancho máximo, porque históricamente ha sido una medida segura para muchas newsletters, campañas comerciales y emails informativos. Aunque hoy se pueden crear diseños más amplios, ese ancho sigue siendo una referencia práctica.
Ejemplo básico de estructura con tablas HTML
<table role="presentation" width="100%" cellspacing="0" cellpadding="0" border="0">
<tr>
<td align="center">
<table role="presentation" width="600" cellspacing="0" cellpadding="0" border="0">
<tr>
<td>
Contenido del email
</td>
</tr>
</table>
</td>
</tr>
</table>Este ejemplo no pretende ser una plantilla final, sino mostrar la idea: una tabla exterior ocupa el ancho completo y centra una tabla interior de anchura controlada.
El contenedor exterior
El contenedor exterior suele ocupar el 100% del ancho. Sirve para definir el fondo general del email y para centrar el contenido. Esta capa es importante porque muchos clientes de correo necesitan estructuras explícitas para respetar alineaciones y fondos.
Aquí puedes aplicar un color de fondo general, por ejemplo un gris claro, y luego colocar dentro el contenido principal sobre fondo blanco. Es una estructura sencilla, pero efectiva.
El contenedor interior
El contenedor interior es el cuerpo real del email. Normalmente se define con un ancho fijo, como 600, y se complementa con estilos que permitan cierta flexibilidad en móvil.
En emails responsive es habitual combinar atributos HTML antiguos, como width="600", con CSS inline y reglas en el bloque <style>. Puede parecer redundante, pero en email la redundancia muchas veces es una forma de defensa.
Las secciones internas
Dentro del contenedor principal puedes crear secciones: cabecera, bloque hero, texto, columnas, llamada a la acción, pie de email, etc.
La clave está en no meter todo en una única tabla gigante sin separación lógica. Aunque el HTML final use tablas, tú puedes pensar en componentes: header, hero, bloque de texto, bloque de dos columnas, botón y footer.
Esa forma de pensar te ayudará a mantener el código más limpio y a reutilizar patrones. Si además estás comparando formas de trabajar, te puede interesar el artículo sobre MJML vs HTML tradicional para emails: ventajas y limitaciones, donde se ve mejor cuándo compensa escribir HTML manual y cuándo conviene automatizar parte del proceso.
Cómo hacer que las tablas HTML funcionen en móvil
El gran reto no es crear un email con tablas. El reto es conseguir que ese email sea responsive. Para eso necesitas combinar varias técnicas: anchuras fluidas, imágenes adaptables, columnas que se apilan y media queries cuando el cliente de correo las soporte.
Lo importante es no depender de una sola técnica. Una buena plantilla de email debe seguir siendo legible incluso aunque una media query no se aplique correctamente.
Usa una estructura fluida siempre que puedas
Una estrategia bastante segura es no depender exclusivamente de una media query. Puedes definir tablas con width="100%" en determinados bloques y limitar el ancho máximo del contenedor principal.
Las imágenes deberían incluir una combinación de atributo HTML y CSS inline similar a esta:
<img src="imagen.jpg" width="600" style="display:block; width:100%; max-width:600px; height:auto;" alt="Descripción de la imagen">Esto permite que la imagen se reduzca en pantallas pequeñas sin deformarse. El atributo width ayuda a algunos clientes de correo, mientras que el CSS aporta flexibilidad.
Apila columnas en pantallas pequeñas
Uno de los patrones más habituales en emails responsive es el bloque de dos columnas. En escritorio puedes mostrar imagen y texto lado a lado. En móvil, lo más cómodo es apilar ambos elementos.
Con tablas HTML, esto suele hacerse creando dos celdas o dos tablas internas que, mediante clases y media queries, pasan a ocupar el 100% del ancho en móvil.
@media only screen and (max-width: 600px) {
.column {
display: block !important;
width: 100% !important;
max-width: 100% !important;
}
}Este tipo de regla permite que una estructura pensada para escritorio se adapte mejor a pantallas pequeñas. Aun así, conviene diseñar siempre con una base sencilla. Si el email solo funciona cuando todo el CSS se aplica perfectamente, probablemente sea demasiado frágil.
No dependas de una única solución responsive
Una buena plantilla de email responsive no debería romperse si una media query falla. Este es uno de los cambios de mentalidad más importantes respecto al desarrollo web tradicional.
En web solemos confiar bastante en CSS. En email, conviene diseñar para la imperfección. Eso significa que el diseño base debe ser legible incluso antes de aplicar mejoras responsive.
Si tu versión sin media queries ya es aceptable, las media queries se convierten en una mejora progresiva, no en una condición de supervivencia.
CSS en emails responsive: lo justo, lo compatible y lo necesario
El CSS en email merece un capítulo aparte. Aquí no se trata de escribir menos CSS porque sí, sino de escribir el CSS que realmente aporta valor y tiene posibilidades razonables de funcionar.
Muchas propiedades modernas pueden ser útiles en determinados clientes, pero no todas son fiables para construir la estructura principal de un email. Por eso conviene trabajar con un criterio muy claro: usar CSS moderno solo cuando haya fallback o cuando el fallo no comprometa la lectura del contenido.
Para profundizar en este punto, puedes leer también qué partes de CSS funcionan realmente en email marketing, donde se explica qué propiedades conviene usar con más prudencia.
Estilos inline: incómodos, pero necesarios
Los estilos inline siguen siendo habituales porque muchos clientes de correo los respetan mejor que los estilos externos. Esto hace que el código sea más verboso, pero también más resistente.
<td style="font-family: Arial, sans-serif; font-size:16px; line-height:24px; color:#222222;">
Texto del email
</td>¿Es elegante? No demasiado. ¿Es práctico? Sí.
Una forma de no volverte loca es no escribir todo a mano en producción. Puedes trabajar con herramientas que automaticen el CSS inline o con frameworks que generen el HTML final.
Media queries: útiles, pero con fallback
Las media queries son muy útiles para ajustar tamaños de fuente, apilar columnas, modificar paddings o centrar elementos en móvil. Pero no conviene usarlas como única garantía.
Un uso razonable sería:
@media only screen and (max-width: 600px) {
.mobile-padding {
padding-left: 20px !important;
padding-right: 20px !important;
}
.mobile-center {
text-align: center !important;
}
.fluid {
width: 100% !important;
max-width: 100% !important;
}
}El uso de !important es bastante común en email porque las reglas inline pueden tener más peso que las reglas declaradas en el bloque <style>. No es una práctica que trasladaríamos alegremente a una web moderna, pero en email responde a una necesidad real.
Evita CSS demasiado moderno si no tienes alternativa
Puedes usar CSS moderno en algunos contextos, pero siempre con cuidado. Flexbox, grid, variables CSS, filtros, posicionamiento complejo o animaciones pueden funcionar en algunos clientes y fallar en otros.
Si decides usarlos, que sea como mejora progresiva, no como base estructural. Para layouts principales, las tablas siguen siendo más fiables. Para detalles visuales secundarios, puedes experimentar un poco más.
Accesibilidad en emails con tablas HTML
Uno de los puntos más importantes, y a veces olvidados, es la accesibilidad. Si usas tablas para maquetar, debes evitar que los lectores de pantalla interpreten esas tablas como datos tabulares.
Para eso se utiliza role="presentation" en las tablas que cumplen una función puramente visual.
Cuándo usar role=»presentation»
Si una tabla solo sirve para colocar una imagen junto a un texto, centrar un botón o estructurar el layout del email, puedes usar:
<table role="presentation" cellspacing="0" cellpadding="0" border="0">Esto ayuda a que la experiencia sea más limpia para personas que usan tecnologías de asistencia.
Cuándo no usarlo
Si la tabla contiene datos reales, como precios, horarios, comparativas o resultados, entonces no deberías usar role="presentation". En ese caso, la tabla sí tiene significado semántico y debe conservarlo.
La diferencia es sencilla: si la tabla organiza diseño, es presentación. Si la tabla organiza datos, es contenido.
No olvides el texto alternativo
Las imágenes en emails suelen tener mucho peso visual, pero no siempre cargan por defecto. Por eso el atributo alt es fundamental.
Un buen texto alternativo debe describir la función de la imagen, no rellenarse con palabras clave sin sentido.
<img src="newsletter-responsive.jpg" alt="Ilustración de una newsletter responsive adaptándose a móvil">El SEO importa, pero la accesibilidad y la claridad también. Una imagen puede reforzar la comprensión del mensaje, pero el contenido esencial debería seguir siendo accesible aunque esa imagen no cargue.
Cómo simplificar el trabajo con MJML
Si tu objetivo es crear emails responsive sin pelearte constantemente con tablas HTML, MJML puede ser una gran ayuda. MJML permite escribir emails con una sintaxis más sencilla y después compilar ese código a HTML compatible con clientes de correo.
La idea es trabajar con etiquetas como <mj-section>, <mj-column>, <mj-text> o <mj-image>, en lugar de escribir manualmente toda la estructura de tablas.
Qué problema resuelve MJML
MJML no elimina las tablas del resultado final. Lo que hace es evitar que tengas que escribirlas tú manualmente en cada plantilla.
Por ejemplo, en lugar de construir una sección de dos columnas con varias tablas anidadas, puedes escribir algo más parecido a esto:
<mj-section>
<mj-column>
<mj-image src="imagen.jpg" alt="Imagen descriptiva" />
</mj-column>
<mj-column>
<mj-text>
Texto del email
</mj-text>
</mj-column>
</mj-section>Después, MJML genera el HTML final con las tablas, estilos y ajustes necesarios.
Si quieres verlo desde un enfoque más práctico, puedes continuar con la guía sobre cómo crear tu primera newsletter responsive con MJML, donde el proceso se entiende mejor paso a paso.
Cuándo te conviene usar MJML
MJML es especialmente útil si vas a crear varias newsletters, plantillas transaccionales o campañas con estructuras repetidas. También es una buena opción si quieres mantener una lógica de componentes y evitar que cada email se convierta en un archivo imposible de leer.
No obstante, sigue siendo importante entender cómo funcionan las tablas HTML en email. Aunque uses MJML, tarde o temprano tendrás que revisar el HTML generado, corregir un comportamiento concreto o adaptar una sección a las limitaciones de un cliente de correo.
Buenas prácticas para no volverte loca con tablas HTML en email
La mejor forma de sobrevivir al desarrollo de emails responsive con tablas HTML es trabajar con método. No improvises cada plantilla desde cero.
Crea una plantilla base reutilizable
Ten una estructura inicial con contenedor exterior, contenedor central, header, bloque de contenido, botón, footer, clases responsive básicas y estilos de texto definidos.
Esto te permitirá empezar cada email desde una base probada, no desde una página en blanco. Además, te ayudará a detectar antes los errores, porque sabrás qué partes de la plantilla ya funcionan correctamente.
Trabaja por bloques, no por pantallas completas
En lugar de pensar “voy a maquetar todo el email”, piensa en bloques independientes: bloque hero, bloque texto más imagen, bloque CTA, bloque testimonios, bloque de producto o bloque footer.
Cada bloque debería poder moverse, duplicarse o eliminarse sin romper toda la plantilla. Esta forma de trabajar se parece más a una lógica de componentes, aunque el resultado final esté construido con tablas.
Prueba antes de enviar
No basta con abrir el HTML en el navegador. Un email puede verse perfecto en Chrome y fallar en Outlook. Siempre que sea posible, prueba en distintos clientes o utiliza herramientas específicas de testing.
Como mínimo, revisa Gmail en escritorio, Gmail en móvil, Apple Mail, Outlook, modo oscuro, imágenes bloqueadas y vista móvil real.
Reduce la ambición visual
Un email no necesita comportarse como una web completa. A veces, cuanto más complejo es el diseño, más posibilidades hay de que algo falle.
En email marketing, la claridad suele ganar a la sofisticación. Un buen email responsive debe ser legible, rápido de escanear, accesible y fácil de accionar. Si además es bonito, mejor. Pero la belleza no debería depender de una estructura frágil.
Errores comunes al crear emails responsive con tablas HTML
Uno de los errores más frecuentes es usar demasiadas columnas. Un diseño de tres o cuatro columnas puede verse bien en escritorio, pero convertirse en un problema en móvil. Si el contenido es importante, asegúrate de que se pueda leer cómodamente en una sola columna.
Otro error habitual es olvidar los paddings móviles. Un email que se ve perfecto en escritorio puede quedar pegado a los bordes en móvil si no defines espaciados adaptados.
También conviene evitar imágenes con texto incrustado. Si el texto importante está dentro de una imagen, puede no ser accesible, no escalar bien o perderse si la imagen no carga.
Y, por último, cuidado con los botones falsos hechos solo con imágenes. Un botón debería ser texto HTML dentro de una estructura clicable, no una imagen que desaparece si el cliente bloquea recursos externos.
Preguntas frecuentes sobre tablas HTML y emails responsive
¿Es obligatorio usar tablas HTML para crear emails responsive?
No es obligatorio en todos los casos, pero sí sigue siendo una de las opciones más compatibles para estructuras principales. Puedes apoyarte en CSS moderno como mejora progresiva, pero para layouts robustos las tablas HTML siguen siendo muy utilizadas en email.
¿Puedo usar flexbox o grid en emails HTML?
Puedes usarlos en algunos contextos, pero no deberías depender de ellos para la estructura principal si necesitas compatibilidad amplia. El soporte de flexbox y grid en clientes de correo no es tan consistente como en navegadores modernos, así que conviene usarlos solo con fallback o en elementos secundarios.
¿MJML evita tener que aprender tablas HTML para email?
MJML reduce muchísimo la necesidad de escribir tablas manualmente, pero no elimina la conveniencia de entenderlas. Es una herramienta muy útil para crear emails responsive de forma más cómoda, aunque el HTML final seguirá usando estructuras compatibles con clientes de correo.
Emails más simples, menos quebraderos de cabeza
Hacer emails responsive con tablas HTML no tiene por qué convertirse en una pesadilla. Es verdad que el desarrollo de emails tiene reglas propias, limitaciones incómodas y decisiones que pueden parecer anticuadas si vienes del desarrollo web moderno. Pero también es cierto que, con una buena estructura base, algunos patrones reutilizables y una mentalidad de compatibilidad, el proceso se vuelve mucho más llevadero.
La clave está en dejar de pelearte con las tablas como si fueran una anomalía y empezar a verlas como una capa de compatibilidad. No necesitas escribir el email más sofisticado del mundo. Necesitas crear una pieza que se lea bien, se adapte al móvil, respete la accesibilidad y funcione en los clientes de correo más importantes.
En email, menos suele ser más. Menos columnas, menos dependencias, menos CSS experimental y menos obsesión por el píxel perfecto. A cambio, más claridad, más consistencia y más tranquilidad.
Porque al final, un buen email responsive no es el que demuestra todo lo que sabes de CSS moderno. Es el que llega, se entiende, se lee cómodamente y consigue que la persona haga lo que tiene que hacer sin obstáculos. Y si para eso hay que usar tablas HTML, que al menos sean tablas bien pensadas.
