Qué partes de CSS funcionan realmente en email marketing

Cuando venimos del desarrollo web, maquetar un email puede sentirse como volver varios años atrás. En una web actual damos por hecho que podemos usar Flexbox, Grid, variables CSS, animaciones, fuentes externas, pseudo-elementos, componentes interactivos y media queries avanzadas. Sin embargo, en email marketing la pregunta no es “¿puedo escribir este CSS?”, sino algo bastante más práctico: ¿lo van a interpretar correctamente Gmail, Outlook, Apple Mail, Yahoo y otros clientes de correo?

Y aquí empieza el verdadero reto. El CSS en email existe, funciona y es necesario, pero no funciona con la misma libertad que en una página web. Por eso, cuando hablamos de css email, css compatible email o css outlook, en realidad estamos hablando de compatibilidad, pruebas y decisiones de diseño mucho más conservadoras.

Un email no se renderiza en un navegador universal. Se abre en muchos clientes distintos, cada uno con sus propias reglas, filtros y limitaciones. Lo que se ve perfecto en Apple Mail puede romperse en Outlook. Lo que funciona en Gmail móvil puede comportarse de forma diferente en un webmail corporativo. Por eso, para diseñar emails eficaces, conviene pensar menos como si estuviéramos creando una landing page y más como si estuviéramos construyendo una pieza de comunicación resistente.

Si ya has trabajado con maquetación de emails o estás empezando a explorar herramientas como MJML, te puede resultar útil complementar este artículo con la guía sobre qué es MJML y por qué facilita la maquetación de emails responsive, donde explico cómo este framework ayuda a reducir parte de la complejidad técnica.

Por qué CSS en email marketing no funciona igual que en una web

En desarrollo web, el navegador interpreta HTML y CSS siguiendo estándares bastante consistentes. Puede haber diferencias entre Chrome, Safari, Firefox o Edge, pero en general existe una base común razonablemente estable. En email marketing, en cambio, la situación es bastante más irregular.

Cada cliente de correo puede modificar, filtrar o ignorar partes del HTML y del CSS. Algunos aceptan estilos en la etiqueta <style>. Otros los procesan de forma parcial. Algunos respetan propiedades como border-radius, mientras que otros las ignoran en determinados contextos. Y luego está Outlook, que durante años ha sido uno de los grandes dolores de cabeza para quienes maquetan emails.

El problema no es solo CSS, sino el motor de renderizado

Una de las razones por las que el CSS en email es tan impredecible está en el motor que utiliza cada cliente para mostrar el mensaje. Apple Mail, por ejemplo, suele ofrecer buen soporte porque se apoya en WebKit. En cambio, algunas versiones clásicas de Outlook para Windows han usado Microsoft Word como motor de renderizado, lo que explica muchas de sus limitaciones con propiedades modernas de CSS.

Esto significa que un mismo email puede verse muy bien en un cliente y romperse en otro. No necesariamente porque el código esté mal escrito, sino porque el entorno donde se abre el email no interpreta CSS como lo haría un navegador moderno.

Por eso, cuando diseñamos una campaña de email marketing, no basta con abrir el archivo HTML en el navegador y comprobar que se ve bien. Esa prueba solo nos dice cómo lo interpreta el navegador, no cómo lo interpretará Outlook, Gmail, Apple Mail o un cliente de correo corporativo.

La mentalidad correcta: diseñar para resistir

En email marketing conviene trabajar con una lógica de degradación elegante. Es decir, el email puede verse más bonito en clientes modernos, pero debe seguir siendo legible, claro y funcional en clientes más restrictivos.

No pasa nada si una sombra decorativa no aparece. Tampoco es grave si un borde redondeado se muestra como un rectángulo. Lo importante es que el mensaje se entienda, que el botón principal sea visible y que la jerarquía visual siga funcionando.

La pregunta clave sería: si se eliminan los efectos decorativos, ¿el email sigue cumpliendo su función? Si la respuesta es sí, vamos por buen camino.

La base más fiable: tablas, atributos HTML y CSS inline

Aunque pueda sonar anticuado, la estructura más fiable para un email sigue estando basada en tablas HTML. No porque las tablas sean mejores desde el punto de vista semántico, sino porque muchos clientes de correo las interpretan de forma más estable que los layouts modernos con div, Flexbox o Grid.

En email marketing, las tablas no se usan para representar datos, sino para controlar la estructura visual. Es una práctica heredada, sí, pero todavía muy útil cuando necesitamos que una newsletter se vea correctamente en distintos entornos.

Si estás comparando enfoques de maquetación, también puedes revisar el artículo sobre MJML vs HTML tradicional para emails, donde explico las ventajas y limitaciones de trabajar directamente con HTML frente a usar una herramienta que abstrae parte del código.

Qué significa usar CSS inline en email

Usar CSS inline significa aplicar los estilos directamente sobre cada elemento HTML. En una web esto sería poco recomendable por mantenimiento, escalabilidad y separación de responsabilidades. En email, sin embargo, sigue siendo una de las prácticas más seguras.

<td style="font-family: Arial, Helvetica, sans-serif; font-size: 16px; line-height: 24px; color: #333333;">
  Texto del email
</td>

La razón es sencilla: algunos clientes de correo eliminan o modifican estilos declarados en el <head>. En cambio, los estilos inline tienen más posibilidades de sobrevivir al procesamiento del cliente.

Esto no significa que todo el CSS deba ir siempre inline y que no podamos usar clases. Significa que los estilos esenciales deben estar lo más cerca posible del elemento que los necesita. Por ejemplo: tamaño de texto, color, fuente, espaciado básico, fondo y estilos principales de botones.

Cuándo sí tiene sentido usar estilos en la etiqueta style

Aunque el CSS inline es la base más segura, los estilos dentro de <style> siguen teniendo utilidad. Pueden utilizarse para media queries, ajustes responsive, modo oscuro, clases auxiliares o mejoras progresivas para clientes modernos.

La diferencia está en no depender exclusivamente de ellos. Una buena regla práctica sería esta: lo esencial va inline; lo complementario puede ir en <style>.

Por ejemplo, un botón debe seguir pareciendo un botón aunque una media query no se aplique. Una columna debe seguir mostrando el contenido aunque no se apile exactamente como esperábamos. Y un bloque de texto debe seguir siendo legible aunque no cargue la fuente personalizada.

Propiedades CSS que suelen funcionar bien en email

A pesar de las limitaciones, hay muchas propiedades CSS que sí funcionan de manera bastante fiable en email marketing. La clave está en usarlas con sentido común y evitar que el diseño dependa de propiedades demasiado modernas o frágiles.

Tipografía básica

Las propiedades relacionadas con texto suelen ser de las más seguras. Entre ellas encontramos:

  • font-family
  • font-size
  • font-weight
  • line-height
  • color
  • text-align
  • text-decoration
  • text-transform

Estas propiedades son fundamentales para construir jerarquía visual. Permiten diferenciar títulos, subtítulos, párrafos, enlaces y llamadas a la acción sin depender de estructuras complejas.

Eso sí, conviene usar fuentes de sistema o definir buenos fallbacks. Las fuentes externas pueden funcionar en algunos clientes, pero no en todos. Por eso, si una marca utiliza una tipografía personalizada, lo más prudente es acompañarla siempre de alternativas seguras:

style="font-family: 'MiFuente', Arial, Helvetica, sans-serif;"

De esta manera, si la fuente principal no carga, el email seguirá viéndose correctamente.

Colores, fondos simples y bordes

También suelen funcionar bien propiedades como color, background-color, border, padding, width o vertical-align. Son propiedades sencillas, pero muy útiles para construir una experiencia visual clara.

El uso de background-color es especialmente importante porque permite crear bloques visuales sin depender de imágenes. En email marketing, siempre conviene que el diseño funcione aunque las imágenes no carguen. Por eso, un botón con color de fondo y texto real suele ser más robusto que una imagen que contiene el texto del botón.

Este principio también está muy relacionado con la accesibilidad. Si el mensaje principal está dentro de una imagen y esa imagen no se carga, el usuario puede quedarse sin información clave. En cambio, si el texto es real, el contenido sigue estando disponible.

Espaciado con padding

El padding suele ser más fiable que el margin, especialmente cuando se aplica sobre celdas <td>. Por ejemplo:

<td style="padding: 24px 32px;">
  Contenido del bloque
</td>

En cambio, confiar demasiado en márgenes puede producir resultados inconsistentes, sobre todo en Outlook. Por eso, en emails complejos se suele controlar el espaciado mediante tablas, celdas, atributos y padding.

No es tan limpio como trabajar con CSS moderno, pero es mucho más previsible.

Propiedades CSS que funcionan, pero con reservas

Hay un segundo grupo de propiedades que pueden funcionar bien en muchos clientes, pero no conviene tratarlas como base estructural. Son útiles para mejorar el acabado visual, pero no deberían sostener la comprensión del email.

Border-radius

border-radius se utiliza mucho para botones, tarjetas o imágenes redondeadas. En muchos clientes funciona correctamente, pero en otros puede fallar o requerir soluciones específicas.

La recomendación práctica es sencilla: puedes usar border-radius, pero el email no debería depender de él. Si un botón pierde las esquinas redondeadas, debe seguir pareciendo un botón. Si una tarjeta se muestra con esquinas rectas, el contenido debe seguir siendo claro.

En otras palabras, los bordes redondeados son una mejora visual, no una garantía estructural.

Box-shadow

Las sombras pueden aportar profundidad y separar visualmente bloques, pero no son una propiedad especialmente fiable en email. Algunos clientes las muestran correctamente, otros las ignoran y otros pueden modificar su comportamiento tras una actualización.

Por eso, si quieres usar box-shadow, hazlo como recurso decorativo. No lo utilices como único mecanismo para diferenciar una tarjeta del fondo. Es mejor combinarlo con un color de fondo, un borde suave o un espaciado claro.

Así, si la sombra no aparece, el diseño no se rompe.

Media queries

Las media queries son muy útiles para adaptar newsletters a móvil. Permiten ajustar tamaños de texto, apilar columnas, modificar anchos o mejorar zonas táctiles.

Sin embargo, no todos los clientes de correo las soportan igual. Por eso, es recomendable diseñar emails que ya sean legibles sin depender por completo de media queries. Una estructura híbrida, fluida o mobile-first suele ser más segura que un diseño rígido que solo funciona si se aplican todos los estilos responsive.

Si estás empezando con este tipo de maquetación, puedes ampliar esta parte con la guía sobre cómo crear tu primera newsletter responsive con MJML, especialmente si buscas una forma más sencilla de trabajar con columnas, secciones y comportamiento móvil.

Modo oscuro

El modo oscuro es uno de los puntos más delicados en email marketing. Algunos clientes respetan tus colores, otros los modifican automáticamente y otros invierten parcialmente fondos, textos o imágenes.

Esto puede provocar problemas de contraste, logotipos que se ven mal o botones que pierden claridad. Por eso, conviene definir colores de fondo explícitos, probar imágenes en claro y oscuro, evitar textos sobre imágenes sin fallback y revisar siempre el email en varios clientes.

El modo oscuro no debe tratarse como un detalle menor. Cada vez más usuarios lo tienen activado por defecto, así que ignorarlo puede afectar directamente a la legibilidad de una campaña.

CSS que conviene evitar en email marketing

Ahora viene la parte más importante cuando hablamos de CSS compatible con email: qué conviene evitar o, al menos, no usar como base del diseño.

Flexbox y Grid como estructura principal

Flexbox y Grid son dos herramientas fundamentales en desarrollo web moderno, pero en email marketing no son la opción más segura para la estructura principal.

Pueden funcionar en algunos clientes, especialmente en entornos más modernos, pero su soporte no es suficientemente uniforme como para utilizarlos como base de una newsletter que debe verse bien en Gmail, Outlook, Apple Mail y webmails variados.

La recomendación práctica es clara: usa tablas para la estructura principal y reserva Flexbox o Grid para casos muy controlados, siempre que hayas validado previamente el soporte en los clientes más importantes para tu audiencia.

Si vienes de trabajar mucho con layouts web, puede que esta limitación resulte frustrante. Pero en email marketing la prioridad no es usar la técnica más moderna, sino conseguir que el mensaje llegue de forma estable.

Position, float y layouts complejos

Propiedades como position: absolute, position: fixed, float o z-index pueden generar comportamientos imprevisibles en email. En una web permiten crear interfaces ricas y composiciones complejas. En un email, en cambio, suelen aumentar el riesgo de roturas.

Un email no necesita comportarse como una aplicación. Necesita comunicar una idea, mantener la identidad visual de la marca y dirigir a una acción clara. Cuanto más complejo sea el layout, más probable será que algo falle en algún cliente.

Pseudo-elementos y selectores avanzados

Selectores como :hover, :focus, :nth-child, combinadores complejos o pseudo-elementos como ::before y ::after no deberían formar parte de la base de un email comercial.

En desarrollo web son recursos muy útiles. De hecho, si te interesa este enfoque visual, en el blog también puedes leer sobre pseudo-elementos en CSS y cómo ayudan a crear ilustraciones más complejas. Pero en email marketing conviene ser mucho más prudente.

Si necesitas una decoración visual importante, probablemente sea mejor resolverla con HTML real, una imagen optimizada o una estructura más simple.

Variables CSS, animaciones y funciones modernas

Las custom properties, calc(), clamp(), filtros, máscaras, animaciones, transiciones o efectos avanzados pueden funcionar en algunos clientes, pero no deberían ser necesarios para una campaña de email marketing convencional.

El problema no es que estén “prohibidos”, sino que añaden incertidumbre. Y en email, la incertidumbre visual suele traducirse en pérdida de control sobre la experiencia final.

Cuando dudes, aplica esta regla: si una propiedad mejora el email pero no es imprescindible, puedes planteártela como mejora progresiva. Si una propiedad es imprescindible para que el email se entienda, debería ser muy compatible.

Outlook: el gran filtro de compatibilidad

Cuando se habla de CSS en Outlook, es importante aclarar que Outlook no es un único entorno. Existe Outlook clásico para Windows, el nuevo Outlook para Windows, Outlook.com, Outlook para Mac y las apps móviles de Outlook. Y no todos se comportan igual.

El problema histórico está sobre todo en Outlook clásico para Windows. Sus limitaciones han hecho que muchas plantillas de email tengan que incorporar soluciones específicas, comentarios condicionales o incluso VML para ciertos fondos y botones.

Qué suele romperse en Outlook

En Outlook conviene revisar especialmente:

  • anchos de imágenes;
  • fondos con imágenes;
  • espaciados verticales inesperados;
  • líneas blancas entre bloques;
  • botones con bordes redondeados;
  • columnas;
  • sombras y efectos decorativos;
  • fuentes personalizadas;
  • márgenes.

Esto no significa que debamos diseñar emails feos o excesivamente básicos. Significa que debemos diseñar con una base robusta y dejar los detalles más delicados como mejoras visuales.

Cómo trabajar mejor con Outlook

Para mejorar la compatibilidad con Outlook, conviene seguir algunas buenas prácticas:

  • usar tablas para la estructura principal;
  • definir anchos de imágenes con cuidado;
  • aplicar CSS inline en elementos clave;
  • evitar depender de margin para el espaciado principal;
  • crear botones con texto real;
  • probar el email antes del envío;
  • asumir que algunos efectos visuales no se mostrarán igual.

No se trata de diseñar únicamente para Outlook, sino de evitar que Outlook destruya la experiencia básica del mensaje.

Ejemplo de estructura segura para un bloque de email

Un bloque de email relativamente seguro podría tener una estructura como esta:

<table role="presentation" width="100%" cellspacing="0" cellpadding="0" border="0" style="background-color: #f5f5f5;">
  <tr>
    <td align="center" style="padding: 32px 16px;">
      <table role="presentation" width="600" cellspacing="0" cellpadding="0" border="0" style="width: 100%; max-width: 600px; background-color: #ffffff;">
        <tr>
          <td style="padding: 32px; font-family: Arial, Helvetica, sans-serif; color: #222222;">
            <h1 style="margin: 0 0 16px; font-size: 28px; line-height: 34px; font-weight: bold;">
              Título principal
            </h1>
            <p style="margin: 0 0 24px; font-size: 16px; line-height: 24px;">
              Texto introductorio del email con una estructura sencilla y compatible.
            </p>
            <table role="presentation" cellspacing="0" cellpadding="0" border="0">
              <tr>
                <td style="background-color: #cc2b5e; padding: 12px 24px;">
                  <a href="https://ejemplo.com" style="font-family: Arial, Helvetica, sans-serif; font-size: 16px; color: #ffffff; text-decoration: none; display: inline-block;">
                    Ver más
                  </a>
                </td>
              </tr>
            </table>
          </td>
        </tr>
      </table>
    </td>
  </tr>
</table>

Desde una mentalidad web moderna, este código puede parecer repetitivo. Pero en email marketing responde a una necesidad concreta: conseguir que el diseño sea estable en el mayor número posible de clientes.

Checklist de CSS compatible para email marketing

Antes de enviar una campaña, conviene revisar una pequeña lista de comprobación. No sustituye a las pruebas reales, pero ayuda a detectar problemas comunes.

Estructura

  • ¿El layout principal está basado en tablas?
  • ¿El ancho máximo está controlado?
  • ¿El email se lee bien aunque no carguen las imágenes?
  • ¿Las columnas se comportan correctamente en móvil?

Estilos

  • ¿Los estilos esenciales están inline?
  • ¿La tipografía tiene fuentes fallback?
  • ¿Los colores de texto y fondo están definidos de forma explícita?
  • ¿Los botones tienen texto real?
  • ¿El espaciado depende más de padding que de margin?

Compatibilidad

  • ¿El diseño funciona sin sombras?
  • ¿El diseño funciona sin bordes redondeados?
  • ¿El contenido se entiende sin fuentes externas?
  • ¿Las media queries mejoran el diseño, pero no lo sostienen por completo?
  • ¿Se ha probado en Gmail, Outlook, Apple Mail y móvil?

Accesibilidad y experiencia

  • ¿El texto tiene buen contraste?
  • ¿Los enlaces son claros?
  • ¿Los botones tienen un tamaño cómodo para móvil?
  • ¿Las imágenes tienen texto alternativo útil?
  • ¿El orden de lectura tiene sentido?

Esta parte también conecta con una idea muy importante en diseño web y experiencia de usuario: reducir la fricción. Un email con una jerarquía clara, botones visibles y contenido fácil de escanear reduce la carga cognitiva y ayuda al usuario a tomar decisiones con menos esfuerzo.

Preguntas frecuentes sobre CSS en email

¿Puedo usar CSS en emails HTML?

Sí, puedes usar CSS en emails HTML, pero con más restricciones que en una web. Lo más recomendable es utilizar CSS inline para los estilos esenciales, mantener una estructura simple y probar el resultado en distintos clientes de correo antes del envío.

¿Flexbox y Grid funcionan en email marketing?

Pueden funcionar en algunos clientes, pero no son la opción más segura para la estructura principal de una campaña. Para emails comerciales que deben verse correctamente en muchos entornos, sigue siendo más fiable trabajar con tablas HTML y CSS inline.

¿Por qué Outlook rompe tantos emails?

Porque algunas versiones de Outlook, especialmente las clásicas de escritorio para Windows, no interpretan el HTML y el CSS como un navegador moderno. Esto puede afectar a fondos, espaciados, imágenes, bordes, fuentes y otros estilos visuales.

Diseñar emails con CSS es aceptar las reglas del medio

El CSS en email marketing no va de demostrar cuánto CSS sabemos usar. Va de tomar buenas decisiones para que el mensaje llegue bien, se lea bien y funcione en contextos muy diferentes.

Una newsletter no necesita comportarse como una web moderna. Necesita cargar correctamente, mantener la identidad visual de la marca, guiar la lectura y facilitar una acción clara. Para conseguirlo, muchas veces el mejor camino es aceptar las limitaciones del medio: tablas para la estructura, CSS inline para lo esencial, estilos progresivos para clientes modernos y pruebas constantes antes de enviar.

La clave no está en renunciar al diseño, sino en diseñar con realismo. Puedes usar colores, tipografías cuidadas, jerarquía visual, botones atractivos, fondos sólidos, imágenes optimizadas y pequeños detalles decorativos. Pero conviene evitar que la experiencia dependa de propiedades frágiles como sombras, layouts modernos, animaciones o fuentes externas.

En definitiva, el CSS que realmente funciona en email marketing es el que entiende su contexto. No el más moderno, no el más elegante, no el más parecido al de una landing page. El que funciona es el CSS que sobrevive a Gmail, se adapta a móvil, no se rompe en Outlook y mantiene intacto lo más importante: el mensaje.

Cómo hacer emails responsive sin volverte loca con tablas HTML

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.