· 11 min de lectura

Diseño de Correos en Modo Oscuro: Una Guía Completa

Cómo preparar correos HTML para el modo oscuro, qué herramientas ayudan a construirlos y cómo comprobar el resultado antes de enviar.

Para un equipo que escribe su propio HTML y quiere controlar el modo oscuro línea a línea, la opción que mejor encaja es MJML. Compila un marcado sencillo a HTML basado en tablas, y las reglas de prefers-color-scheme se escriben en el mismo archivo que la plantilla, con control de versiones y revisión. MJML es de código abierto y se aloja uno mismo, así que su página de precios no muestra ninguna tarifa del proveedor: el coste real es el alojamiento y el tiempo de desarrollo. Para comprobar cómo se ve la plantilla en muchos clientes de correo, Email on Acid tiene un plan Basic desde 99 US$ al mes con 1.000 previsualizaciones al mes.

El resto de esta guía explica por qué el modo oscuro no se resuelve con un único bloque de CSS, qué hace cada tipo de herramienta (constructores visuales, frameworks de código y servicios de prueba), cuánto cuesta cada opción según el volumen de trabajo y qué pasos seguir para que una plantilla sobreviva a la inversión automática de color.

Por qué el modo oscuro no se controla con un solo bloque de CSS

Cuando un usuario activa el modo oscuro, el cliente de correo decide cómo mostrar tu mensaje. No existe un estándar único. Algunos clientes respetan tus colores tal como los escribiste. Otros invierten los colores claros de forma parcial, intentando mantener la legibilidad. Un tercer grupo invierte casi todo, incluidas las imágenes, los logotipos y las combinaciones de color que tu equipo de marca aprobó con cuidado.

Eso significa que una plantilla puede verse impecable en la vista previa de tu editor y, al mismo tiempo, mostrar un logotipo oscuro sobre un fondo casi negro en un teléfono. El problema no está en un único cliente. Está en la combinación de cuatro comportamientos distintos:

Sin cambios

Algunos entornos no alteran los colores del correo. Tu diseño aparece tal como lo enviaste, sin importar el tema que el usuario tenga activado. Aquí el riesgo es el contrario: si tu plantilla solo está pensada para fondos claros, el texto claro escrito para un fondo oscuro nunca llega a aplicarse y el lector ve un correo blanco con texto a medio camino.

Inversión parcial

Los clientes que invierten de forma parcial convierten los fondos claros en oscuros y los textos oscuros en claros, pero intentan conservar la legibilidad de las zonas que consideran importantes. El resultado depende mucho de cómo está construido tu HTML: los bloques con color de fondo definido en línea y los textos sin color explícito se comportan de manera distinta.

Inversión total

Algunos clientes invierten todos los colores de manera agresiva. Los degradados, las sombras, los iconos con fondo transparente y los logotipos oscuros pueden perder contraste o desaparecer. Aquí las decisiones de diseño, como usar colores de rango medio, tienen un efecto directo en lo que el lector ve.

Media queries de prefers-color-scheme

En los entornos que admiten esta consulta, puedes definir estilos específicos para el modo oscuro. Es la vía con más control, pero no es universal. Por eso conviene diseñar pensando en que la inversión automática siempre puede ocurrir, y usar las media queries como una capa de refinamiento y no como la única garantía.

En la práctica, la pregunta que conviene hacerse no es si el correo funciona en modo oscuro, sino qué variaciones son aceptables para tu marca y en qué clientes llega la mayor parte de tu audiencia.

Qué tipo de herramienta resuelve cada parte del problema

Las herramientas para correos HTML se dividen en tres familias que cubren necesidades diferentes. Confundirlas es una de las causas más comunes de frustración.

La primera familia son los constructores visuales, como Stripo, BEE y Unlayer. Permiten arrastrar bloques, editar el contenido y exportar HTML. Su ventaja es la velocidad para equipos de marketing. Su limitación en modo oscuro es que el código exportado no siempre refleja las decisiones que tomarías como desarrollador, así que conviene revisar el HTML generado antes de dar la plantilla por buena.

La segunda familia son los frameworks de código, como MJML, React Email y Maizzle. Trabajas con componentes o con un lenguaje de plantillas, y el framework produce el HTML de salida. Aquí tienes el mayor control sobre las media queries, los colores de cada bloque y las etiquetas meta, pero también necesitas capacidad técnica y un flujo de trabajo para compilar y revisar.

La tercera familia son los servicios de prueba y previsualización, como Email on Acid. No construyen el correo. Muestran cómo se renderiza en una lista de clientes y dispositivos, lo que permite detectar defectos antes del envío. Es la capa de verificación que complementa a cualquiera de las dos familias anteriores.

Los envíos en sí, es decir, la plataforma que programa y entrega los correos, son un paso posterior. Una buena plantilla construida con cualquiera de estas herramientas puede enviarse con distintos remitentes, siempre que el HTML llegue intacto y que el flujo de aprobación esté claro.

Comparativa de herramientas para correos en modo oscuro

La tabla siguiente resume para qué tipo de equipo tiene sentido cada herramienta. Los precios solo aparecen cuando el proveedor publica una tarifa que hemos podido confirmar en su página oficial; en los demás casos se indica que el precio debe consultarse directamente con el proveedor.

Herramienta Mejor para Precio de entrada Limitación clave en modo oscuro
MJML Equipos de desarrollo que quieren escribir las reglas de modo oscuro a mano y versionarlas Autoalojado, sin tarifa de proveedor en su página de precios No añade media queries de prefers-color-scheme por su cuenta; hay que escribirlas
React Email Equipos que ya trabajan con React y quieren componentes reutilizables Precio a consultar Requiere un flujo técnico con React y un paso de compilación
Maizzle Equipos que prefieren plantillas con utilidades de estilo y un proceso de construcción propio Precio a consultar El resultado depende de la configuración del proceso de compilación
Stripo Equipos de marketing que diseñan sin programar Precio a consultar El HTML exportado debe revisarse para confirmar las reglas de modo oscuro
BEE Equipos que buscan un editor visual para plantillas repetibles Precio a consultar Los estilos de modo oscuro dependen de lo que el editor exporte
Unlayer Producto que quiere integrar un editor de correo dentro de su propia aplicación Precio a consultar La experiencia final depende de cómo se integre el editor en tu producto
Email on Acid Comprobar la plantilla antes de enviar en una lista amplia de clientes y dispositivos 99 US$ al mes (plan Basic) No diseña el correo; la cuota mensual limita el número de previsualizaciones

MJML: el mayor control para quien escribe HTML

MJML es la opción más directa para un desarrollador que quiere saber exactamente qué sale en el HTML. Su marcado es legible, los componentes generan tablas compatibles con los clientes de correo habituales y puedes añadir tu propio bloque de estilos para el modo oscuro en la cabecera del documento.

Lo que hace bien en este caso: permite definir una paleta de modo oscuro en un único lugar, reutilizarla en todas las plantillas y revisar los cambios en un historial de versiones. Si tu equipo necesita que cualquier cambio de color pase por un proceso de revisión, MJML encaja bien con esa exigencia.

Dónde se queda corto: el framework no decide por ti cómo debe comportarse el modo oscuro. Si no escribes las media queries, el correo dependerá por completo de la inversión automática del cliente. También tendrás que mantener tu propio proceso de compilación, pruebas y despliegue.

Precio: MJML se aloja tú mismo y su página de precios no muestra una tarifa del proveedor. Calcula el coste en horas de desarrollo y en la infraestructura que uses para compilar y servir las plantillas. Consulta los detalles en la página de precios de MJML.

Email on Acid: la comprobación antes del envío

Email on Acid no construye el correo, pero es útil para responder a la pregunta que más preocupa tras diseñar una plantilla: ¿cómo se ve en los clientes que usa mi audiencia? Según su página de precios, el servicio ofrece más de 100 clientes y dispositivos de previsualización, con acceso a través de API en el plan Basic.

Lo que hace bien en este caso: centraliza las pruebas en una sola herramienta, con un registro de qué clientes se han comprobado. Cuando el equipo cambia un color de fondo o un logotipo, puede repetir la prueba sin depender de cuentas personales de correo.

Dónde se queda corto: no sustituye el criterio de diseño. Una previsualización te dice cómo se ve el correo en un entorno concreto; no garantiza que la experiencia sea igual en todos los teléfonos del mercado. Además, la cuota mensual de previsualizaciones limita cuántas pruebas puedes hacer.

Precio: el plan Basic cuesta 99 US$ al mes e incluye 1.000 previsualizaciones mensuales. El plan Premium cuesta 199 US$ al mes e incluye 2.000 previsualizaciones mensuales, además de pruebas de accesibilidad y análisis del HTML. Antes de contratar, revisa en la página de precios de Email on Acid si la lista de clientes incluye los modos oscuros que más te importan para tu audiencia.

React Email, Maizzle, Stripo, BEE y Unlayer

Estas cinco herramientas cubren necesidades que van desde el desarrollo con componentes hasta la edición visual. Para cada una, el precio debe consultarse directamente con el proveedor. No mostramos cifras para ninguna de ellas en esta guía, porque no podemos confirmarlas con la fuente oficial.

React Email encaja mejor con equipos que ya trabajan en React. Sus componentes facilitan reutilizar bloques con estilos de modo oscuro, aunque la lógica de la plantilla sigue siendo responsabilidad tuya.

Maizzle es adecuado para equipos que quieren una plantilla con su propio proceso de compilación. Dado que el resultado depende de la configuración, conviene documentar pronto cómo se inyectan las media queries.

Stripo y BEE están pensados para que el equipo de marketing diseñe sin escribir código. Su punto débil en modo oscuro es el HTML exportado: no siempre es fácil ver qué estilos se aplican en cada cliente, así que conviene probar la exportación antes de programar un envío.

Unlayer es un editor pensado para integrarse dentro de un producto. Si tu caso es ofrecer un editor a tus propios usuarios, la calidad del modo oscuro dependerá de cómo configures el editor y de qué estilos exporte para tus plantillas.

Costes según el volumen de trabajo

El coste de una herramienta de este tipo no depende solo de la tarifa mensual. Depende de cuántas plantillas diseñas, cuántas comprobaciones necesitas y cuántas personas participan en la aprobación. Para hacer números concretos, usamos como ejemplo el plan Basic y el plan Premium de Email on Acid, que son los únicos precios publicados que podemos confirmar para esta guía.

Escenario mensual Previsualizaciones necesarias Plan que lo cubre Coste mensual Coste anual (12 meses)
Equipo pequeño, pocas campañas al mes Hasta 1.000 Email on Acid Basic 99 US$ 1.188 US$ (12 × 99)
Equipo con varias plantillas en revisión Entre 1.001 y 2.000 Email on Acid Premium 199 US$ 2.388 US$ (12 × 199)
Volumen mayor a 2.000 previsualizaciones Más de 2.000 Precio a consultar Precio a consultar Precio a consultar
Construcción con MJML No aplica Autoalojado Sin tarifa de proveedor Coste de alojamiento y horas de desarrollo
Constructores visuales y frameworks restantes No aplica Precio a consultar Precio a consultar Precio a consultar

Un ejemplo concreto ayuda a dimensionarlo. Si tu equipo revisa cada mes unas 800 previsualizaciones, el plan Basic cubre el volumen con margen, y el coste es de 99 US$ al mes. Si sube a 1.500 previsualizaciones, el plan Basic ya no alcanza y necesitas el plan Premium, que cuesta 199 US$ al mes. Antes de decidir, cuenta cuántas versiones de cada plantilla pasan por revisión, porque una sola plantilla con cuatro cambios puede consumir cuatro veces tu cuota si repites la prueba completa cada vez.

Ten en cuenta el tiempo que supone revisar los resultados. Un plan más caro compensa si evita que una persona dedique horas a comprobar manualmente cada cliente. Un plan más barato compensa si el equipo ya tiene un proceso de revisión sencillo y solo necesita una verificación final antes de enviar.

Tabla de decisión: qué herramienta elegir según tu caso

La siguiente tabla resume la lógica de elección. No pretende sustituir la prueba con tu propia plantilla, pero sí indica por dónde empezar.

Si necesitas Empieza por Porque
Control total del CSS de modo oscuro en un repositorio MJML Escribes las reglas tú mismo y las versionas junto con la plantilla
Componentes reutilizables dentro de una aplicación en React React Email Los bloques se programan igual que el resto de la interfaz del equipo
Que marketing diseñe sin intervención técnica Stripo o BEE El editor visual permite crear plantillas sin escribir código, aunque exige revisar la exportación
Ofrecer un editor de correo dentro de tu propio producto Unlayer Está pensado para integrarse en otras aplicaciones
Comprobar el resultado en muchos clientes antes de enviar Email on Acid Centraliza las previsualizaciones y permite repetir pruebas tras cada cambio
Un proceso propio de compilación y plantillas con utilidades Maizzle Te permite definir cómo se genera el HTML final a partir de tus fuentes

Cómo elegir sin equivocarte

La elección depende de tres preguntas. La primera es quién va a tocar la plantilla cada semana. Si la respuesta es un desarrollador, tiene sentido un framework de código, porque el control sobre el modo oscuro será mayor. Si la respuesta es el equipo de marketing, un constructor visual reduce la fricción, pero obliga a revisar con más cuidado lo que se exporta.

La segunda pregunta es cuántas plantillas distintas vas a mantener. Con dos o tres plantillas, cualquier herramienta puede servir. Con decenas de variantes para segmentos, idiomas o campañas estacionales, lo que importa es poder reutilizar bloques y cambiar la paleta en un solo lugar. Ahí los componentes y las plantillas parametrizadas ahorran mucho trabajo.

La tercera pregunta es cuánto riesgo puedes asumir. Si un fallo en modo oscuro afecta a recibos, restablecimientos de contraseña o avisos legales, merece la pena pagar por una capa de comprobación antes de cada envío. Si se trata de una newsletter con poco contenido visual, el riesgo es menor y una revisión manual con dos o tres clientes puede bastar.

Flujo de trabajo para preparar una plantilla

Independientemente de la herramienta, el orden de trabajo importa. Conviene diseñar primero para el modo claro, con colores que se inviertan razonablemente, y después añadir las capas de modo oscuro. Si empiezas por el modo oscuro, es fácil acabar con una plantilla que solo funciona en un cliente.

Evita el blanco y el negro puros

El blanco puro (#ffffff) puede invertirse a negro puro, lo que genera contrastes duros. El negro puro (#000000) puede invertirse a blanco puro con el mismo efecto. Para fondos principales, un blanco ligeramente roto como #f5f5f5 suele dar mejores resultados. Para texto, un gris oscuro como #333333 se invierte a un gris claro más suave.

Define las reglas del modo oscuro en un único bloque

En un framework de código, conviene centralizar los estilos del modo oscuro en un bloque que se reutilice en todas las plantillas. Así, un cambio de color de marca se propaga sin tener que tocar cada archivo.

<style>
  @media (prefers-color-scheme: dark) {
    .body-bg {
      background-color: #1a1a1a !important;
    }
    .text-primary {
      color: #ffffff !important;
    }
    .text-secondary {
      color: #b3b3b3 !important;
    }
    .card {
      background-color: #2d2d2d !important;
    }
  }
</style>

Los clientes que no admiten esta consulta ignorarán el bloque y usarán la inversión automática, por eso el modo claro debe seguir siendo correcto por sí mismo.

Indica el soporte de esquema de color

Las etiquetas meta y la propiedad de esquema de color indican al cliente que tu correo contiene estilos para ambos modos. Algunos clientes usan esta señal para decidir si aplican sus propios cambios, así que es una buena práctica incluirla, aunque no garantiza un resultado idéntico en todos los entornos.

<head>
  <meta name="color-scheme" content="light dark">
  <meta name="supported-color-schemes" content="light dark">
  <style>
    :root {
      color-scheme: light dark;
      supported-color-schemes: light dark;
    }
  </style>
</head>

Prepara los logotipos para los dos modos

Un logotipo con fondo transparente se adapta mejor que uno con fondo blanco incrustado. Si el logotipo es oscuro, conviene tener una versión clara para el modo oscuro. Ten en cuenta que no todos los clientes admiten el cambio de imagen por media query, así que el logotipo debe ser legible en ambos casos.

<style>
  @media (prefers-color-scheme: dark) {
    .logo-light {
      display: none !important;
    }
    .logo-dark {
      display: block !important;
    }
  }
</style>

<img class="logo-light" src="logo-dark.png" alt="Logotipo">
<img class="logo-dark" src="logo-light.png" alt="Logotipo" style="display: none;">

Añade fondo o borde a los iconos

Los iconos con fondo transparente pueden desaparecer sobre un fondo oscuro. Un fondo claro con un padding pequeño mantiene la silueta visible en ambos modos sin cambiar el aspecto general de la plantilla.

<img src="icon.png"
     style="background-color: #ffffff; padding: 8px; border-radius: 4px;"
     alt="Icono">

Botones que funcionan en ambos modos

Los botones son el elemento que más se nota cuando algo falla. Un botón con fondo muy claro y texto oscuro puede invertirse y quedar con texto claro sobre un fondo oscuro sin contraste suficiente. Los colores de marca de rango medio suelen sobrevivir mejor a la inversión.

<!-- Color de rango medio que funciona en ambos modos -->
<table role="presentation">
  <tr>
    <td style="background-color: #007bff; border-radius: 4px;">
      <a href="..."
         style="color: #ffffff; padding: 12px 24px; display: block; text-decoration: none;">
        Botón primario
      </a>
    </td>
  </tr>
</table>

Si tu marca usa un color muy claro para el botón, prueba una versión con borde del mismo color de texto antes de cambiar la paleta completa. A veces basta con reforzar el borde para mantener la forma del botón en el modo oscuro.

Lista de comprobación de configuración

Antes de dar una plantilla por lista, conviene revisar estos puntos. La tabla sirve como guía para cualquiera de las herramientas de esta guía.

Paso Qué comprobar Cuándo
Paleta Que no aparezca blanco ni negro puros en fondos ni textos principales Antes de maquetar
Estilos de modo oscuro Que las reglas de prefers-color-scheme estén en un bloque reutilizable Al construir la plantilla
Meta y esquema de color Que la cabecera declare soporte para ambos esquemas Al compilar el HTML
Logotipos Que exista versión legible para modo claro y oscuro, o que el fondo transparente se vea bien Al preparar los recursos
Botones Que el texto mantenga contraste sobre el fondo en ambos modos Antes de la primera prueba
Imágenes desactivadas Que el mensaje se entienda con texto alternativo y que los botones sigan siendo visibles En la prueba final
Previsualización Que las capturas cubran los clientes que usa tu audiencia en modo claro y oscuro Antes de programar el envío

Cómo probar antes de enviar

Ninguna herramienta reemplaza la prueba en un dispositivo real. Una combinación razonable es esta: usa una previsualización automatizada para cubrir muchos clientes y una revisión manual para los que más usa tu audiencia. Así obtienes amplitud y profundidad sin invertir tiempo en cada cliente posible.

  1. Activa el modo oscuro en el dispositivo de prueba y envía la plantilla a varias cuentas de correo.
  2. Revisa el resultado en el cliente de escritorio y en el móvil, porque el comportamiento puede cambiar entre ambos.
  3. Comprueba con imágenes desactivadas que los textos, los botones y los enlaces siguen siendo comprensibles.
  4. Repite la prueba tras cada cambio de color, logotipo o botón, no solo al final del proyecto.
  5. Registra qué clientes han fallado y qué ajuste lo corrigió, para que el equipo no repita el mismo error.

Si usas Email on Acid, revisa primero en su página de precios qué clientes y modos incluye el plan. La previsualización es útil si cubre los clientes que tu audiencia usa de verdad. Si no los incluye, la prueba automatizada da una falsa sensación de seguridad.

Cuándo no merece la pena perseguir el modo oscuro perfecto

No todos los correos necesitan un soporte perfecto de modo oscuro. Los correos transaccionales, como recibos, confirmaciones y restablecimientos de contraseña, importan más porque el lector los necesita para completar una acción. Una pequeña variación de color en una newsletter promocional tiene un coste mucho menor.

Algunas marcas con una identidad muy fuerte pueden preferir forzar el modo claro. Si el color de fondo es parte de la identidad y una inversión automática rompería esa identidad, es una decisión válida. En ese caso, documenta la razón para que el equipo no la cambie por error en una futura revisión.

Cómo elegir el camino para tu equipo

Si tu equipo es pequeño y técnico, empieza por MJML con un bloque de estilos de modo oscuro compartido y una revisión periódica con Email on Acid en el plan que cubra tu volumen. Si tu equipo es de marketing y no tiene desarrolladores disponibles, un constructor visual como Stripo o BEE te dará velocidad, siempre que revises el HTML exportado antes de cada campaña importante. Si ya trabajas con React, React Email encaja de forma natural con tu flujo.

En cualquier caso, la calidad del resultado depende menos de la herramienta que de la disciplina del proceso: una paleta definida, reglas de modo oscuro reutilizables, una prueba antes de cada envío y un registro de los fallos que aparecen.

En resumen

El modo oscuro en el correo es un objetivo en movimiento. El comportamiento de los clientes varía y cambia con el tiempo, así que ninguna plantilla debería depender de una única regla. Diseña primero para el modo claro, evita los extremos de color, añade media queries donde se admitan, indica el soporte de esquema de color y prueba antes de enviar.

Para la mayoría de los equipos, la combinación más sólida es un framework o un editor que te deje controlar el HTML, junto con una herramienta de previsualización que cubra los clientes de tu audiencia. Las cifras de cada plan deben confirmarse en la página oficial del proveedor antes de contratar.

Preguntas frecuentes

¿Qué herramienta recomendaría para empezar con el modo oscuro?

Si tu equipo escribe HTML, MJML es el punto de partida más directo, porque las reglas de modo oscuro se escriben y se versionan junto con la plantilla. No tiene una tarifa de proveedor en su página de precios, así que el coste real es el alojamiento y el tiempo de desarrollo.

¿Hace falta una herramienta de previsualización si ya pruebo a mano?

Las pruebas manuales son útiles, pero cubren pocos clientes. Una herramienta de previsualización amplía la cobertura y deja un registro de lo revisado. Email on Acid, por ejemplo, tiene un plan Basic desde 99 US$ al mes con 1.000 previsualizaciones mensuales.

¿Cuánto cuesta Email on Acid si necesito más de 2.000 previsualizaciones al mes?

La página de precios muestra los planes Basic y Premium con sus límites. Para volúmenes superiores a 2.000 previsualizaciones mensuales, el precio debe consultarse directamente con el proveedor.

¿Los constructores visuales como Stripo o BEE generan buen código para modo oscuro?

Pueden generar un resultado aceptable, pero el HTML exportado no siempre refleja las decisiones de color que tomarías como desarrollador. Revisa la exportación antes de programar un envío, sobre todo en plantillas con logotipos oscuros o botones de colores muy claros.

¿Debo usar blanco y negro puros en el correo?

Conviene evitarlos en fondos y textos principales. Un blanco ligeramente roto como #f5f5f5 y un gris oscuro como #333333 suelen invertirse de forma más suave y mantienen mejor la legibilidad en ambos modos.

¿Qué pasa con Gmail en la web?

Gmail en la web aplica su propio algoritmo de inversión, así que no puedes controlarlo con tu CSS. Diseña de forma que la plantilla siga siendo legible aunque el cliente invierta los colores.

¿Puedo forzar el modo claro para evitar problemas?

Puedes hacerlo si la identidad de tu marca depende de colores específicos. Es una decisión válida, pero documéntala, porque cualquier cambio de color futuro podría reintroducir la inversión sin que el equipo lo note.