{"id":1356,"date":"2026-06-12T13:36:38","date_gmt":"2026-06-12T13:36:38","guid":{"rendered":"https:\/\/www.gloobs.com\/blog\/?p=1356"},"modified":"2026-06-12T13:43:11","modified_gmt":"2026-06-12T13:43:11","slug":"guia-completa-de-diseno-responsive-para-email-newsletters","status":"publish","type":"post","link":"https:\/\/www.gloobs.com\/blog\/guia-completa-de-diseno-responsive-para-email-newsletters\/","title":{"rendered":"Gu\u00eda completa de dise\u00f1o responsive para email \/ newsletters"},"content":{"rendered":"
\n

Gu\u00eda completa de dise\u00f1o responsive para email \/ newsletters<\/h1>\n

El dise\u00f1o responsive para email funciona de forma radicalmente distinta al responsive web.<\/strong> No hay flexbox, no hay grid, CSS externo se ignora en la mayor\u00eda de clientes de correo, y Gmail en Android sigue haciendo lo que le da la gana con tu c\u00f3digo. Esta gu\u00eda cubre lo que realmente funciona en 2026, sin rodeos.\u00a0Adem\u00e1s te dejo un HTML ejemplo para que puedas descargarte.<\/p>\n<\/header>\n

\n
\n

Por qu\u00e9 el email HTML es un caso aparte<\/h2>\n

Cuando dise\u00f1as para web, el peor escenario es un navegador con cuatro a\u00f1os de antig\u00fcedad. Cuando dise\u00f1as un email, el peor escenario es Outlook 2016 renderizando con el motor de Word \u2014s\u00ed, Word\u2014, Gmail stripeando tu <style><\/code> si va en el <head><\/code>, y Apple Mail aplicando su propio redimensionado de fuentes sin pedirte permiso.<\/p>\n

La fragmentaci\u00f3n de clientes de correo en 2026 sigue siendo brutal. Seg\u00fan los datos de Litmus, Gmail concentra alrededor del 27% de las aperturas globales, Apple Mail otro 26%, y Outlook (en sus m\u00faltiples 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.<\/p>\n

Todo esto significa que el enfoque correcto no es \u00abdise\u00f1ar como en web y adaptar\u00bb. Es empezar desde la estructura que el email necesita y a\u00f1adir mejoras progresivas encima.<\/p>\n<\/section>\n

\n

La base que no ha cambiado: tablas como estructura<\/h2>\n

S\u00ed, tablas. No es nostalgia, es pragmatismo. Las tablas son el \u00fanico sistema de layout que funciona de forma consistente en todos los clientes de correo relevantes, incluido Outlook. Flexbox y CSS Grid simplemente no est\u00e1n disponibles de forma fiable en el contexto del email.<\/p>\n

La estructura base de cualquier email responsive parte de una tabla contenedora centrada, con un ancho m\u00e1ximo fijo (habitualmente 600px, que es el est\u00e1ndar de la industria para contenido de email) y un ancho del 100% para que se adapte en m\u00f3vil.<\/p>\n

Pero aqu\u00ed est\u00e1 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\u00f3n. Usa un patr\u00f3n llamado hybrid o spongy layout<\/strong>, que permite que las columnas se apilen sin depender de que el cliente de correo soporte media queries.<\/p>\n

El patr\u00f3n hybrid: columnas que se apilan solas<\/h3>\n

La idea es simple pero contraintuitiva. Cada columna tiene un max-width<\/code> fijo (el ancho que quieres en desktop) y un width: 100%<\/code>. Cuando el contenedor es suficientemente ancho, las columnas se colocan en l\u00ednea. Cuando se estrecha, se apilan. Sin media queries.<\/p>\n

\n
\r\n<!-- Contenedor principal del email -->\r\n<table role=\"presentation\" width=\"100%\" cellspacing=\"0\" cellpadding=\"0\" border=\"0\">\r\n  <tr>\r\n    <td align=\"center\" style=\"padding: 0 10px;\">\r\n\r\n      <!-- Tabla de contenido: m\u00e1x 600px, se estrecha en m\u00f3vil -->\r\n      <table role=\"presentation\" width=\"100%\" style=\"max-width: 600px;\" cellspacing=\"0\" cellpadding=\"0\" border=\"0\">\r\n\r\n        <!-- FILA DE DOS COLUMNAS: patr\u00f3n hybrid -->\r\n        <tr>\r\n          <td style=\"padding: 0;\">\r\n\r\n            <!-- Columna izquierda: ocupa la mitad en desktop, 100% en m\u00f3vil -->\r\n            <div style=\"display: inline-block; vertical-align: top; width: 100%; max-width: 280px;\">\r\n              <table role=\"presentation\" width=\"100%\" cellspacing=\"0\" cellpadding=\"0\" border=\"0\">\r\n                <tr>\r\n                  <td style=\"padding: 20px; background-color: #f5f5f5;\">\r\n                    <p style=\"margin: 0; font-family: Arial, sans-serif; font-size: 16px; line-height: 1.5; color: #333333;\">Columna izquierda<\/p>\r\n                  <\/td>\r\n                <\/tr>\r\n              <\/table>\r\n            <\/div><!--\r\n            --><!-- Sin espacio entre divs: los comentarios eliminan el espacio inline-block -->\r\n\r\n            <!-- Columna derecha: mismo patr\u00f3n -->\r\n            <div style=\"display: inline-block; vertical-align: top; width: 100%; max-width: 280px;\">\r\n              <table role=\"presentation\" width=\"100%\" cellspacing=\"0\" cellpadding=\"0\" border=\"0\">\r\n                <tr>\r\n                  <td style=\"padding: 20px; background-color: #ffffff;\">\r\n                    <p style=\"margin: 0; font-family: Arial, sans-serif; font-size: 16px; line-height: 1.5; color: #333333;\">Columna derecha<\/p>\r\n                  <\/td>\r\n                <\/tr>\r\n              <\/table>\r\n            <\/div>\r\n\r\n          <\/td>\r\n        <\/tr>\r\n\r\n      <\/table>\r\n    <\/td>\r\n  <\/tr>\r\n<\/table>\r\n    <\/code><\/pre>\n<\/div>\n
El truco del comentario HTML entre los <div><\/code> (el <!-- --><\/code> al final de cada bloque) elimina el espacio en blanco que los navegadores insertan entre elementos inline-block<\/code> y que desplazar\u00eda las columnas. Es un hack de los de toda la vida, pero funciona en todos los clientes.<\/p>\n<\/section>\n
\n
Media queries en email: d\u00f3nde s\u00ed funcionan y d\u00f3nde no<\/h2>\n
Las media queries funcionan en Apple Mail, iOS Mail, y la mayor\u00eda de clientes basados en WebKit. No funcionan en Gmail (web ni Android), Outlook, ni Yahoo Mail. Por eso el patr\u00f3n hybrid como base: no depende de ellas.<\/p>\n
Pero cuando funcionan, s\u00ed a\u00f1aden mejoras importantes. El lugar correcto para ponerlas en un email es un bloque <style><\/code> dentro del <body><\/code>, no en el <head><\/code>. Gmail elimina el <head><\/code> completo, pero respeta estilos en el <body><\/code> en su versi\u00f3n web (aunque no en Android).<\/p>\n
\n
\r\n\/* Bloque de media queries para clientes que las soportan *\/\r\n\/* Va dentro del <body>, en un <style> justo antes del email --> *\/\r\n\r\n@media screen and (max-width: 600px) {\r\n\r\n  \/* Forzar ancho completo en m\u00f3vil *\/\r\n  .email-container {\r\n    width: 100% !important;\r\n    max-width: 100% !important;\r\n  }\r\n\r\n  \/* Apilar columnas que el hybrid no pudo apilar *\/\r\n  .col-half {\r\n    display: block !important;\r\n    width: 100% !important;\r\n    max-width: 100% !important;\r\n  }\r\n\r\n  \/* Tipograf\u00eda m\u00e1s grande en m\u00f3vil *\/\r\n  .email-body p {\r\n    font-size: 17px !important;\r\n    line-height: 1.6 !important;\r\n  }\r\n\r\n  \/* Bot\u00f3n a ancho completo en m\u00f3vil *\/\r\n  .btn-cta {\r\n    display: block !important;\r\n    width: 100% !important;\r\n    text-align: center !important;\r\n  }\r\n\r\n  \/* Ocultar elementos solo para desktop *\/\r\n  .hide-mobile {\r\n    display: none !important;\r\n    height: 0 !important;\r\n    overflow: hidden !important;\r\n  }\r\n}\r\n    <\/code><\/pre>\n<\/div>\n
El !important<\/code> aqu\u00ed no es mala pr\u00e1ctica: es necesario para sobreescribir los estilos inline que los clientes de correo procesan con mayor prioridad.<\/p>\n<\/section>\n
\n
Tipograf\u00eda en email: lo que puedes y no puedes usar<\/h2>\n
Las web fonts en email son un tema con sus propias reglas. Apple Mail y algunos clientes iOS soportan @font-face<\/code> y Google Fonts via <link><\/code>. Gmail no. Outlook, tampoco.<\/p>\n
La estrategia correcta es declarar la tipograf\u00eda personalizada para quien la soporta y definir un stack de fallback cuidado para quien no. No \u00abArial, sans-serif\u00bb sin m\u00e1s. Un stack pensado:<\/p>\n
\n
\r\n\/* Stack tipogr\u00e1fico para email: de preferida a universalmente disponible *\/\r\nfont-family: 'Inter', 'Helvetica Neue', Helvetica, Arial, sans-serif;\r\n\r\n\/* Para serif si el contexto lo pide *\/\r\nfont-family: 'Georgia', 'Times New Roman', Times, serif;\r\n\r\n\/* Tama\u00f1os m\u00ednimos: nunca bajar de 14px en cuerpo, 22px en H1 *\/\r\n\/* iOS aumenta autom\u00e1ticamente fuentes <13px, lo que rompe layouts *\/\r\nfont-size: 16px; \/* body *\/\r\nfont-size: 24px; \/* h2 *\/\r\nfont-size: 32px; \/* h1 *\/\r\n    <\/code><\/pre>\n<\/div>\n
El m\u00ednimo de 14px en cuerpo no es una preferencia est\u00e9tica: iOS Mail escala autom\u00e1ticamente cualquier fuente menor, lo que puede romper columnas y layouts enteros si no lo anticipas.<\/p>\n<\/section>\n
\n
Botones: el \u00fanico m\u00e9todo que funciona en todos los clientes<\/h2>\n
Los botones en email no son <button><\/code> ni <a><\/code> con estilos aplicados directamente. El m\u00e9todo m\u00e1s robusto \u2014y el que Litmus y Campaign Monitor llevan recomendando a\u00f1os\u2014 es el bot\u00f3n con padding en la celda de una tabla:<\/p>\n
\n
\r\n<!-- Bot\u00f3n responsive que funciona en Outlook y el resto -->\r\n<table role=\"presentation\" cellspacing=\"0\" cellpadding=\"0\" border=\"0\" style=\"margin: 20px auto;\">\r\n  <tr>\r\n    <td align=\"center\" style=\"border-radius: 6px; background-color: #1a1a2e;\">\r\n      <a href=\"https:\/\/tuurl.com\"\r\n         target=\"_blank\"\r\n         style=\"display: inline-block;\r\n                padding: 14px 32px;\r\n                font-family: Arial, sans-serif;\r\n                font-size: 16px;\r\n                font-weight: bold;\r\n                color: #ffffff !important;\r\n                text-decoration: none;\r\n                border-radius: 6px;\r\n                background-color: #1a1a2e;\">\r\n        Ver la gu\u00eda completa\r\n      <\/a>\r\n    <\/td>\r\n  <\/tr>\r\n<\/table>\r\n    <\/code><\/pre>\n<\/div>\n
El color: #ffffff !important<\/code> en el <a><\/code> es necesario porque algunos clientes de correo aplican su propio color a los enlaces y lo sobreescriben si no lo fuerzas. El background-color<\/code> duplicado en la celda y en el <a><\/code> es para que Outlook, que no renderiza el border-radius pero s\u00ed el color, al menos muestre el fondo correcto.<\/p>\n<\/section>\n
\n
Errores que cuestan aperturas y conversiones<\/h2>\n