Email responsive en HTML: columnas fluidas, método híbrido y media queries

Un correo responsive fiable no depende de una sola técnica. Se construye por capas, de la más segura a la más frágil: primero un contenedor de ancho flexible que cualquier cliente entiende, luego un método híbrido que mantiene columnas lado a lado en escritorio sin necesitar CSS en el <head>, y por último media queries para afinar donde el cliente las respeta. Si una capa falla, la anterior sostiene el diseño.

Por qué el correo no se comporta como una web

En una página web decides con Flexbox y Grid; en un correo, no. La propia tabla de caniemail para display:flex te permite comprobar cliente a cliente cuánto puedes arriesgar, y la regla práctica sigue siendo maquetar con tablas anidadas y estilos en línea. Lo que cambia entre clientes no es solo la estética: es qué parte de tu CSS llega siquiera a ejecutarse.

Qué soporta cada cliente de verdad

Antes de elegir técnica conviene mirar datos, no recuerdos. En la página de caniemail sobre @media aparecen tres hechos que condicionan todo lo demás:

• Apple Mail las admite, tanto en macOS como en iOS.
• Gmail las admite de forma parcial: en sus versiones de escritorio y de aplicación no soporta consultas anidadas ni basadas en la altura, y las aplicaciones de Gmail no las aplican con cuentas que no son de Google.
• Entre soporte completo y parcial, la propia página estima un 80,48 % de cobertura ponderada; el resto de lectores verá tu versión base.

Esa minoría sin cobertura es el argumento de fondo para diseñar la versión sin media queries como si fuera la definitiva, y tratar el resto como adorno.

Capa 1: contenedor fluido con tope de ancho

Un correo de una columna con una tabla al 100 % y un max-width de 600 píxeles se encoge en un móvil y se queda en 600 en un monitor. Es la única técnica que no exige ningún soporte especial. El max-width en sí lo cubre la tabla de caniemail, así que merece la pena revisar los clientes que tu audiencia usa realmente.

<table role="presentation" width="100%" cellpadding="0" cellspacing="0">
  <tr>
    <td align="center">
      <table role="presentation" width="100%" style="max-width: 600px;">
        <tr>
          <td style="padding: 24px; font-family: Arial, sans-serif;">
            Este bloque ocupa el ancho disponible hasta 600 px.
          </td>
        </tr>
      </table>
    </td>
  </tr>
</table>

Dos detalles que se olvidan: el atributo role="presentation" evita que los lectores de pantalla anuncien una tabla de datos, y la tabla exterior centra el contenido en los clientes que ignoran el margen automático.

Capa 2: columnas híbridas con comentarios condicionales

Cuando necesitas dos columnas en escritorio que se apilen en móvil sin depender de una regla CSS, el método híbrido usa dos div en línea con un ancho máximo. Los clientes modernos los colocan lado a lado si caben y los apilan si no. Outlook de escritorio para Windows, que dibuja el correo con el motor de Word, no entiende ese comportamiento, así que se le entrega una tabla real mediante comentarios condicionales que solo él lee.

<!--[if mso]>
<table role="presentation" width="600"><tr><td width="300" valign="top">
<![endif]-->
<div style="display: inline-block; width: 100%; max-width: 300px; vertical-align: top;">
  Columna izquierda
</div>
<!--[if mso]>
</td><td width="300" valign="top">
<![endif]-->
<div style="display: inline-block; width: 100%; max-width: 300px; vertical-align: top;">
  Columna derecha
</div>
<!--[if mso]>
</td></tr></table>
<![endif]-->

Lo difícil de este patrón no es escribirlo, sino mantenerlo: cada columna nueva exige tocar tres sitios. Por eso muchos equipos lo generan con un framework en lugar de a mano.

Capa 3: media queries como mejora

Las media queries siguen siendo útiles para cosas que el método híbrido no puede hacer: reducir el relleno, agrandar el cuerpo del texto o esconder un elemento decorativo en pantallas pequeñas. Se declaran en un bloque <style> y necesitan !important porque deben ganar a los estilos en línea.

<style>
  @media screen and (max-width: 600px) {
    .cuerpo { font-size: 17px !important; line-height: 1.5 !important; }
    .relleno { padding: 12px !important; }
    .solo-escritorio { display: none !important; }
  }
</style>

Dado lo anterior sobre Gmail, nunca pongas aquí algo sin lo que el correo no se pueda leer. Si ocultas con display:none un elemento que contiene el único enlace de acción, quien no reciba la regla lo verá igualmente, y quien sí la reciba se quedará sin él.

Imágenes y botones

Una imagen necesita tres cosas: el atributo width con su tamaño pensado, max-width:100% y height:auto para que escale, y display:block para eliminar el hueco que algunos clientes dejan debajo. Añade siempre un alt descriptivo; si el cliente bloquea las imágenes, será lo único que se lea. Para los botones, el relleno sobre el enlace (no sobre la celda) hace que toda la superficie sea tocable, y las pautas de interfaz de Apple recomiendan un objetivo de al menos 44 × 44 puntos. En Outlook para Windows un botón con fondo y borde redondeado necesita código VML aparte, y esa es una de las razones para no escribirlo a mano.

Dejar que MJML haga la estructura

MJML encapsula las tres capas. Según su documentación de mj-column, las columnas se apilan en móvil y deben estar dentro de un mj-section; si quieres que dos columnas no se apilen, las envuelves en mj-group. El punto de cambio de escritorio a móvil se ajusta con mj-breakpoint.

<mjml>
  <mj-head>
    <mj-breakpoint width="480px" />
  </mj-head>
  <mj-body>
    <mj-section>
      <mj-column>
        <mj-text>Columna izquierda</mj-text>
      </mj-column>
      <mj-column>
        <mj-text>Columna derecha</mj-text>
      </mj-column>
    </mj-section>
  </mj-body>
</mjml>

Fíjate en lo que no aparece: ni comentarios condicionales, ni tablas, ni media queries. La documentación avisa también de límites que conviene conocer: por ejemplo, el menú de hamburguesa de mj-navbar solo funciona en Apple Mail, y el resto de clientes muestra los enlaces en línea. Si quieres comparar este enfoque con otro basado en componentes de React, lee la comparativa MJML frente a React Email.

Cómo probar sin engañarte

1. Desactiva el CSS del <head> a propósito y abre el correo. Es lo que verá quien use Gmail con una cuenta ajena. Si sigue siendo usable, la base es sólida.
2. Reduce el ancho a unos 320 píxeles y comprueba que nada desborda ni que el texto se corta.
3. Revisa Outlook para Windows en un entorno real, o con un servicio de capturas, porque las vistas previas del editor no reproducen el motor de Word.
4. Prueba con las imágenes bloqueadas. Si el mensaje pierde su sentido, tu texto alternativo y tu jerarquía no están haciendo su trabajo.

Para el modo oscuro, que se rompe de forma distinta, tienes la guía de diseño para modo oscuro, y para decidir qué herramienta de maquetación encaja con tu equipo, la comparativa de constructores de HTML.