23 ene, 2026 · 14 min de lectura · Equipo editorial

Compatibilidad con clientes de correo electrónico: Qué funciona dónde

Qué CSS y HTML sobrevive en cada cliente, qué herramientas usar para construirlo y cuánto cuesta enviarlo.

Para la mayoría de equipos que construyen sus propios correos, el punto de partida más sensato es MJML. Es un lenguaje de marcado que se compila a HTML con tablas y estilos en línea, así que no tienes que escribir a mano la estructura que Outlook de escritorio necesita. Se autoaloja, y las condiciones de uso y las opciones de precio se consultan en mjml.io/pricing. Su ventaja principal es que el HTML de salida sigue patrones de compatibilidad conocidos; la responsabilidad de revisar el resultado en cada cliente sigue siendo tuya.

Esta guía explica por qué los clientes de correo se comportan de forma distinta, qué propiedades CSS conviene usar, qué técnicas siguen siendo necesarias para Outlook de escritorio y cómo elegir entre editores visuales, frameworks y plataformas de envío. Si sólo necesitas decidir qué herramienta usar, ve directamente a la tabla comparativa. Si ya tienes una plantilla que se rompe en algún cliente, la lista de migración te servirá más.

Por qué los clientes de correo renderizan de forma distinta

Un navegador web sigue en gran medida una especificación común. Un cliente de correo no. Cada uno tiene su propio motor de renderizado, y eso explica casi todas las diferencias que vas a encontrar. En la práctica conviene agrupar los clientes en tres familias:

Outlook de escritorio para Windows: dibuja el mensaje con el motor de Microsoft Word. Es la familia más restrictiva y la que más código de compatibilidad exige.
Outlook de nueva generación y Outlook en la web: se acercan más a un navegador, pero no se comportan igual que Chrome o Safari. No asumas que una regla que funciona en uno funcionará en el otro.
Motores de navegador y webmails: Apple Mail usa WebKit en macOS e iOS. Gmail, Yahoo y otros servicios reescriben parte del HTML y eliminan propiedades que consideran inseguras. Lo que ves en tu código no siempre es lo que ve el lector.

Este último punto es el que más sorprende a quien llega de la web. Un selector que funciona en una página puede desaparecer en un correo, y una propiedad que el cliente sí soporta puede quedar fuera por una regla de seguridad. Por eso la compatibilidad se verifica con el resultado final, no con la intención del código.

Los clientes principales, uno por uno

Outlook de escritorio (Windows)

Es el cliente más exigente. Al depender del motor de Word, ignora varias técnicas que en la web son estándar:

La flotación con float no es fiable, así que las columnas deben construirse con tablas.
Las imágenes de fondo colocadas en un div no se dibujan. Para fondos de sección necesitas VML.
El margen y el relleno se aplican de forma inconsistente. El espaciado más seguro se hace con celdas de tabla y padding en las celdas.
El posicionamiento CSS no se puede contar con él.
El ancho de contenedor conviene fijarlo con atributos HTML (por ejemplo width="600"), además de estilos.

Nuevo Outlook y Outlook en la web

Son más modernos, pero siguen teniendo peculiaridades propias. La regla práctica es no extrapolar: si una plantilla se ve bien en Outlook de escritorio, eso no garantiza que se vea bien en la versión web, y viceversa. Revisa el mensaje en la versión que usa tu audiencia.

Gmail (web y aplicaciones)

Gmail elimina algunos selectores y propiedades CSS, y puede reescribir partes del documento. Los estilos en línea son la opción más segura para los elementos importantes, como colores de texto, márgenes y botones. Las consultas de medios se comportan de forma diferente según se abra en la web, en la aplicación de iOS o en la de Android, así que confirma cada caso en la documentación de Google antes de depender de ellas.

Apple Mail (macOS e iOS)

Es el cliente más permisivo: soporta consultas de medios, imágenes de fondo y propiedades CSS modernas. Eso invita a diseñar sólo para él, y es un error. Un correo debe leerse bien en Outlook y Gmail aunque tu público sea mayoritariamente de Apple. Usa Apple Mail como cliente en el que el diseño puede lucir mejor, no como referencia única.

Yahoo Mail

Tiene un soporte CSS moderado. Elimina algunos estilos, aunque en general de forma menos agresiva que Gmail. El soporte de imágenes de fondo no es uniforme, así que trátalas como una mejora visual, nunca como un requisito para entender el mensaje.

Outlook.com (Hotmail)

Es la versión web de Outlook y se comporta de forma distinta a la de escritorio. Tiene mejor soporte CSS que Outlook de escritorio, pero sigue teniendo casos especiales. Como en el resto de clientes, la revisión debe hacerse contra el cliente concreto.

Propiedades CSS: qué usar, qué probar y qué evitar

La siguiente clasificación es orientativa. Los clientes cambian con cada actualización, así que confirma cualquier propiedad dudosa en la documentación del cliente antes de depender de ella.

Seguras en casi todas partes

/* Propiedades con soporte amplio */
color: #333333;
font-family: Arial, sans-serif;
font-size: 16px;
font-weight: bold;
line-height: 1.5;
text-align: center;
text-decoration: none;
background-color: #ffffff;
border: 1px solid #cccccc;
padding: 10px; /* mejor en celdas de tabla */
width: 100%;
max-width: 600px;

Soporte parcial (requiere revisión)

/* Funcionan en la mayoría, pero con matices en Outlook */
border-radius: 4px; /* sin soporte fiable en Outlook de escritorio */
background-image: url(...); /* en Outlook de escritorio, usa VML */
box-shadow: ...; /* soporte limitado */
margin: 10px; /* inconsistente en Outlook de escritorio */

Evitar o usar con mucha precaución

/* Causan problemas con frecuencia */
display: flex; /* sin soporte fiable en correo */
display: grid; /* sin soporte fiable en correo */
position: absolute/relative; /* muy limitado */
float: left/right; /* problemas en Outlook de escritorio */
transform: ...; /* soporte limitado */
animation: ...; /* soporte solo en algunos clientes de Apple */

Técnicas de estructura que siguen siendo necesarias

Tablas para la maquetación

Las tablas siguen siendo el método fiable para estructurar un correo. La regla es anidar una tabla exterior de ancho completo, otra interior de 600 píxeles centrada, y poner el contenido en celdas:

<table role="presentation" width="100%" cellpadding="0" cellspacing="0">
  <tr>
    <td align="center" style="padding: 20px;">
      <table role="presentation" width="600" cellpadding="0" cellspacing="0">
        <tr>
          <td>Contenido aquí</td>
        </tr>
      </table>
    </td>
  </tr>
</table>

El atributo role="presentation" indica a los lectores de pantalla que la tabla sirve para maquetar y no para datos.

Comentarios condicionales para Outlook

Cuando necesitas que Outlook de escritorio reciba una estructura distinta, usa comentarios condicionales. El resto de clientes los ignora:

<!--[if mso]>
  <table width="600"><tr><td>
<![endif]-->

  <div style="max-width: 600px;">
    Contenido para todos los clientes
  </div>

<!--[if mso]>
  </td></tr></table>
<![endif]-->

VML para fondos de sección en Outlook

Si una sección necesita una imagen de fondo visible en Outlook de escritorio, el div con background-image no basta. Hay que añadir el bloque VML y dejar el HTML normal para el resto:

<!--[if gte mso 9]>
<v:rect xmlns:v="urn:schemas-microsoft-com:vml" fill="true" stroke="false" style="width:600px;height:300px;">
<v:fill type="tile" src="https://example.com/background.jpg" color="#ffffff" />
<v:textbox inset="0,0,0,0">
<![endif]-->

<div style="background-image: url(https://example.com/background.jpg); background-color: #ffffff;">
  Contenido aquí
</div>

<!--[if gte mso 9]>
</v:textbox>
</v:rect>
<![endif]-->

Este patrón es uno de los que más se rompen al copiar y pegar entre plantillas, porque el VML debe llevar la misma ruta de imagen y el mismo tamaño que la sección. Si cambias una cosa, cambia la otra.

Imágenes: lo que más afecta al diseño

Las imágenes son la causa más frecuente de espacios extraños y de maquetas que se descolocan. Este bloque de código cubre los casos habituales:

<img
  src="https://example.com/image.jpg"
  alt="Descripción breve de la imagen"
  width="600"
  height="300"
  style="display: block; max-width: 100%; height: auto; border: 0;"
>

Atributos que conviene no omitir:

width y height: Outlook de escritorio los necesita para reservar el espacio.
display: block: elimina el hueco que el navegador deja debajo de una imagen en línea.
max-width: 100%: permite que la imagen se reduzca en pantallas pequeñas.
border: 0: evita el borde que algunos clientes añaden a las imágenes enlazadas.
alt: describe la imagen para quien no la ve, y el texto aparece mientras las imágenes están bloqueadas.

Formatos

JPG: fotografías e imágenes con muchos tonos.
PNG: gráficos sencillos y transparencia.
GIF: animaciones cortas. Usa pocos fotogramas y pesos moderados.
SVG: soporte limitado en correo. Evítalo si el mensaje debe verse bien en todos los clientes.
WebP: no es fiable en Outlook de escritorio. Si lo usas, ofrece un PNG o JPG de respaldo.

Como las imágenes suelen estar bloqueadas por defecto en algunos clientes, el texto que las describe y el diseño sin ellas deben funcionar. Es una comprobación barata y muy útil.

Fuentes

Pila de fuentes seguras

La forma más segura de tipografía es una pila de fuentes que casi cualquier cliente tiene instalada:

font-family: Arial, Helvetica, sans-serif;
font-family: Georgia, Times, serif;
font-family: 'Courier New', Courier, monospace;

Fuentes web

Las fuentes web funcionan en algunos clientes, sobre todo en Apple Mail, iOS y varias aplicaciones de Android. En el resto se usa la fuente de reserva. Si el diseño depende de una tipografía concreta, la reserva debe seguir siendo legible:

<style>
  @import url('https://fonts.googleapis.com/css2?family=Open+Sans&display=swap');
</style>

<p style="font-family: 'Open Sans', Arial, sans-serif;">
  Texto con fuente personalizada
</p>

Outlook de escritorio y varios webmails mostrarán Arial. Apple Mail mostrará Open Sans. Diseña pensando en ambos resultados, no en el mejor de los dos.

Consultas de medios y diseño responsivo

Las consultas de medios permiten apilar columnas en pantallas pequeñas, pero su soporte no es uniforme. Esta es una base habitual:

<style>
  @media screen and (max-width: 600px) {
    .mobile-full-width {
      width: 100% !important;
    }
    .mobile-stack {
      display: block !important;
    }
    .mobile-hide {
      display: none !important;
    }
  }
</style>

En líneas generales, Apple Mail e iOS soportan bien estas reglas, Outlook de escritorio no las aplica, y Gmail depende de la plataforma y de la versión. Por eso el diseño de escritorio debe funcionar sin ellas, y las consultas sólo deben mejorar la lectura en móvil.

Herramientas para construir correos compatibles

No todas las herramientas de esta lista son constructores de HTML. Algunas son frameworks de código, otras son editores visuales y otras son plataformas de envío. Kit y Courier aparecen porque suelen usarse junto a un constructor, no porque generen el HTML del mismo modo.

Herramienta	Mejor para	Precio de entrada	Limitación clave
MJML	Equipos con desarrolladores que quieren código limpio y salida con tablas	Autoalojado. Opciones en mjml.io/pricing	Hay que alojarlo y mantener las plantillas; no es un editor visual
Stripo	Equipos de marketing que diseñan sin código	Precio bajo consulta	El HTML exportado debe revisarse en los clientes de destino
BEE	Diseño visual con bloques reutilizables	Precio bajo consulta	Igual que el resto de editores: revisa el código generado
Unlayer	Integrar un editor de correo dentro de tu propio producto	Precio bajo consulta	Requiere integración en tu aplicación
React Email	Equipos que escriben plantillas con componentes de React	Precio bajo consulta	Hace falta saber React y revisar la salida en cada cliente
Maizzle	Equipos que quieren plantillas con CSS moderno y un paso de compilación	Precio bajo consulta	Requiere un flujo de compilación antes de enviar
Kit	Creadores y newsletters con suscriptores	Gratis hasta 10.000 suscriptores. Creator: 33 US$/mes facturado anualmente	Las automatizaciones visuales y las secuencias están en planes de pago
Courier	Correos transaccionales y notificaciones enviadas por API	Plan Developer gratuito con 10.000 envíos al mes	Pensado para envíos desde código, no como editor de newsletters

Análisis por herramienta

MJML

Qué hace bien: para un equipo técnico, MJML reduce el trabajo de escribir tablas anidadas y estilos en línea. El código fuente es legible y se versiona como cualquier otro proyecto, lo que facilita revisar cambios. Para un público que usa Outlook de escritorio, esa estructura predecible es su gran ventaja.

Dónde se queda corta: no es un editor para marketers. Quien no escriba código tendrá que apoyarse en alguien que sí lo haga, y cada cambio de diseño pasa por el ciclo de edición, compilación y revisión.

Precio: se autoaloja. Las opciones y condiciones se consultan en mjml.io/pricing.

Stripo

Qué hace bien: es un editor visual pensado para que personas de marketing construyan plantillas sin tocar código. Para equipos que necesitan producir muchos correos con un estilo de marca coherente, esa velocidad es el argumento principal.

Dónde se queda corta: el HTML exportado debe revisarse como cualquier otro. Un editor visual no te exime de comprobar Outlook de escritorio, sobre todo si usas fondos, columnas o botones con formas complejas.

Precio: bajo consulta. Antes de elegir, pide la tarifa vigente al proveedor para tu volumen.

BEE

Qué hace bien: trabaja con bloques reutilizables y una interfaz de arrastrar y soltar. Es útil para equipos pequeños que quieren una biblioteca de módulos y no quieren mantener HTML propio.

Dónde se queda corta: como con todos los editores, la compatibilidad depende de la calidad del HTML generado. Si tu plantilla tiene requisitos especiales, conviene probar primero un bloque de cada tipo antes de montar el mensaje completo.

Precio: bajo consulta.

Unlayer

Qué hace bien: está pensado para incrustarse dentro de un producto. Si estás construyendo una aplicación en la que tus clientes diseñan sus propios correos, un editor integrable evita tener que desarrollar uno desde cero.

Dónde se queda corta: requiere trabajo de integración, y la responsabilidad de que el resultado funcione en los clientes de correo sigue siendo tuya como proveedor de la plataforma.

Precio: bajo consulta.

React Email

Qué hace bien: para equipos que ya trabajan con React, permite escribir plantillas con componentes en el mismo lenguaje que la aplicación. Esto facilita reutilizar lógica, tipar los datos y mantener las plantillas junto al código que las alimenta.

Dónde se queda corta: si el equipo no sabe React, la curva de aprendizaje es real. Además, el código bonito no garantiza un correo compatible: hay que revisar la salida renderizada en Outlook de escritorio y en Gmail.

Precio: bajo consulta.

Maizzle

Qué hace bien: ofrece un flujo basado en CSS moderno y una etapa de compilación que produce HTML para correo. Es una buena opción para quien ya conoce las utilidades de CSS y quiere aplicar esos hábitos al correo.

Dónde se queda corta: el paso de compilación añade una herramienta más al flujo, y las clases utilitarias deben traducirse de forma que Outlook de escritorio las entienda. Revisa siempre el resultado compilado.

Precio: bajo consulta.

Kit

Qué hace bien: es una plataforma de envío para newsletters y audiencias. Para un creador o un equipo pequeño que quiere enviar boletines, el plan gratuito cubre hasta 10.000 suscriptores con difusiones de correo ilimitadas, formularios, páginas de captación y segmentación por etiquetas.

Dónde se queda corta: las automatizaciones visuales y las secuencias de correo no están en el plan gratuito. Si tu plantilla necesita HTML muy personalizado, comprueba antes si el editor de Kit permite lo que necesitas.

Precio: plan gratuito hasta 10.000 suscriptores. El plan Creator se factura a 33 US$ al mes con facturación anual, e incluye automatizaciones visuales, secuencias ilimitadas y pruebas A/B de asunto. Hay prueba gratuita de 14 días en los planes de pago, sin tarjeta. Consulta las condiciones en kit.com/pricing.

Courier

Qué hace bien: es una plataforma para enviar notificaciones y correos desde tu propio código mediante API. Si tu correo es transaccional, como confirmaciones de pedido o avisos de cuenta, su modelo por envío encaja bien.

Dónde se queda corta: no está pensado como editor de newsletters para marketing. Si tu caso es un boletín para miles de suscriptores, Kit o un editor de campañas será más cómodo.

Precio: el plan Developer es gratuito con 10.000 envíos al mes. El plan Business se factura por envío, a 0,005 US$ por envío. El plan Enterprise es personalizado. Detalles en courier.com/pricing.

Cuánto cuesta enviar a distintos tamaños de lista

La tabla siguiente compara Kit y Courier en tres escenarios. Los importes de Courier son aritmética sobre la tarifa por envío publicada, sin contar otros cargos. Confirma en el proveedor cómo se factura tu caso concreto antes de decidir.

Escenario	Kit	Courier
2.000 suscriptores, 2.000 correos al mes	0 US$ en el plan gratuito (hasta 10.000 suscriptores)	0 US$ en el plan Developer (2.000 envíos dentro de 10.000)
10.000 suscriptores, 10.000 correos al mes	0 US$ en el plan gratuito, en el límite de 10.000	0 US$ en el plan Developer, en el límite de 10.000 envíos
25.000 suscriptores, 25.000 correos al mes	Plan Creator: 33 US$/mes facturado anualmente. Confirma el precio para ese tamaño en kit.com/pricing	15.000 envíos por encima del límite gratuito: 15.000 × 0,005 = 75 US$ al mes en tarifa Business
50.000 suscriptores, 50.000 correos al mes	Precio bajo consulta según el plan y el tamaño de la lista	40.000 envíos por encima del límite gratuito: 40.000 × 0,005 = 200 US$ al mes en tarifa Business

La conclusión práctica es que, para newsletters con muchos suscriptores, la comparación debe hacerse sobre el número de suscriptores; para correos transaccionales, sobre el número de envíos. Si envías un boletín semanal a 25.000 personas, eso son 25.000 envíos por edición, no un único envío mensual. Haz la cuenta con tu frecuencia real.

Cómo elegir

Antes de decidir, responde a estas tres preguntas: quién va a editar las plantillas, cuánto volumen tendrás y si el correo es de marketing o transaccional. Con esas respuestas, la tabla siguiente sirve como punto de partida:

Si necesitas...	Elige...	Porque...
Control total del HTML y cambios versionados	MJML o Maizzle	La salida es predecible y el código se revisa como cualquier otro proyecto
Diseño sin código por parte de marketing	Stripo o BEE	Editor visual con bloques, aunque debes revisar el HTML exportado
Un editor de correo dentro de tu propia aplicación	Unlayer	Está pensado para integrarse en productos
Plantillas escritas con componentes de React	React Email	Comparte lenguaje y datos con la aplicación
Boletines a suscriptores con automatizaciones	Kit	Plan gratuito hasta 10.000 suscriptores, con difusiones ilimitadas
Correos transaccionales enviados desde código	Courier	Plan Developer gratuito hasta 10.000 envíos al mes, con SDKs y API

Una combinación habitual es un framework para la plantilla y una plataforma de envío para entregar. El framework controla la compatibilidad; la plataforma controla la lista, la segmentación y la entrega. Mezclar ambos no es un error, siempre que cada herramienta haga lo que mejor sabe.

Migración de una plantilla existente

Si ya tienes una plantilla que funciona en parte, no la reescribas de cero. Sigue estos pasos en orden y revisa el resultado después de cada uno:

Paso	Qué revisar	Señal de alerta
1. Guarda la versión actual	Copia el HTML en control de versiones antes de cambiar nada	No puedes volver a la versión que sí funcionaba
2. Pasa los estilos a línea	Cada elemento importante debe llevar sus propios estilos	Gmail pierde colores, márgenes o tamaños de texto
3. Sustituye divs de estructura por tablas	Tabla exterior de ancho completo y tabla interior de 600 píxeles	Columnas desalineadas en Outlook de escritorio
4. Añade comentarios condicionales y VML	Sólo para los fondos y estructuras que lo necesiten	Fondos que no aparecen en Outlook de escritorio
5. Ajusta las imágenes	width, height, alt, display block y max-width	Huecos bajo las imágenes o imágenes que se desbordan
6. Revisa las consultas de medios	El diseño de escritorio debe funcionar sin ellas	Columnas que no se apilan en el móvil
7. Verifica enlaces e imágenes	URL absolutas con HTTPS y rutas que existen	Imágenes rotas al abrir el mensaje

Un flujo de trabajo que evita sorpresas

La forma más eficaz de controlar la compatibilidad no es una revisión final, sino un flujo que la integre desde el principio:

Empieza con una plantilla base mínima. Una tabla de 600 píxeles, un encabezado, un bloque de texto y un botón. Asegúrate de que esa base llega bien a los clientes principales antes de añadir secciones.
Revisa el código de salida, no sólo la vista previa. La vista previa del editor no muestra los errores de estructura que aparecerán en el cliente real.
Añade un bloque cada vez. Cuando un bloque falla, sabes cuál es el causante. Si añades diez bloques de golpe, el problema se vuelve difícil de localizar.
Mira tu propia audiencia. Tu herramienta de envío suele mostrar qué clientes usan tus suscriptores. Prioriza esos clientes en la revisión, aunque la guía general cubra más casos.
Mantén un texto alternativo y una versión sin imágenes. Un mensaje que se entiende sin imágenes se lee bien en todos los clientes, incluidos los que las bloquean.

Conclusión

La compatibilidad con clientes de correo es compleja, pero manejable si trabajas con técnicas conocidas: tablas para la maquetación, estilos en línea, fuentes seguras con reserva y VML donde Outlook de escritorio lo necesite. Elige la herramienta según quién edita, cuánto volumen tienes y si el correo es de marketing o transaccional. Y revisa el resultado en los clientes que usa tu audiencia antes de cada envío importante.

Preguntas frecuentes

¿Puedo ignorar Outlook de escritorio?

No si tu audiencia lo usa. Es el cliente más restrictivo, y muchas de las técnicas de esta guía existen precisamente por él. Si tu público es mayoritariamente de Apple, puedes priorizar el diseño, pero conviene que el mensaje siga leyéndose bien en Outlook.

¿Necesito MJML si uso un editor visual?

No es necesario. Un editor visual como Stripo o BEE genera el HTML por ti. MJML tiene sentido si quieres controlar el código fuente, versionarlo y compilarlo como parte de tu proyecto. En cualquier caso, la revisión en clientes de correo sigue siendo necesaria.

¿Las consultas de medios funcionan en Gmail?

Depende de la plataforma. Las aplicaciones de Gmail en iOS y Android tienen un comportamiento distinto al de la versión web, y ese comportamiento puede cambiar. Diseña el correo para que sea legible sin consultas de medios y usa las consultas sólo para mejorar la lectura en móvil.

¿Qué formato de imagen debo usar?

JPG para fotografías, PNG para gráficos con transparencia y GIF para animaciones cortas. Evita SVG y WebP en correo, o usa un respaldo en PNG o JPG si necesitas WebP.

¿Kit sirve para correos transaccionales?

Kit está pensado para boletines y audiencias. Para confirmaciones de pedido, avisos de cuenta o notificaciones enviadas desde tu aplicación, Courier tiene un modelo más adecuado, con un plan Developer gratuito de hasta 10.000 envíos al mes.

¿Cuánto cuesta Courier si supero los 10.000 envíos?

Sobre la tarifa por envío publicada de 0,005 US$, cada envío por encima del límite gratuito cuesta esa cantidad en el plan Business. Por ejemplo, 40.000 envíos extra suman 200 US$ al mes en esa tarifa, sin contar otros cargos. Confirma el detalle en courier.com/pricing.

¿Es suficiente con revisar en un solo cliente?

No. Un cliente puede mostrar bien un correo que otro rompe por completo. Revisa al menos Outlook de escritorio, Gmail y Apple Mail, y añade los clientes que usa tu audiencia. La inversión en revisión es pequeña comparada con el coste de un mensaje roto enviado a toda la lista.