El modo oscuro no es un único modo de renderizado; es una familia de comportamientos por cliente. Algunas apps respetan los colores que enviaste, otras los invierten a la fuerza con algoritmos que no controlas, y unas pocas dejan que tu CSS opte por estilos oscuros explícitos. Probar cada combinación es imposible, e intentarlo es lo que hace perder la cabeza. El enfoque sensato es una matriz de clientes pequeña que puedas mantener, conocimiento de los patrones de fallo concretos, y una separación clara entre lo que verifican las bandejas temporales (qué se envió) y lo que solo los clientes reales pueden mostrar (cómo se renderiza).
Por qué el modo oscuro rompe los correos
En modo claro, el HTML del email se renderiza más o menos como se escribió. En modo oscuro, el comportamiento se divide por cliente:
- Algunos clientes solo oscurecen su propia interfaz y renderizan tu correo exactamente como se envió — un correo de fondo blanco se convierte en una losa brillante dentro de una app oscura.
- Otros aplican oscuro forzado: un algoritmo del cliente remapea tus colores para que los fondos claros se vuelvan oscuros y el texto se invierta por legibilidad. El remapeo es conservador con regiones de color pequeñas y puede convertir los colores de marca en grises medios embarrados.
- Unos pocos respetan los metadatos estándar de modo oscuro y las media queries que te permiten enviar estilos oscuros explícitos, y los ignoran cuando están ausentes.
El mismo correo produce tres resultados distintos, por eso "en mi teléfono se ve bien" no demuestra nada.
Construye una matriz que puedas mantener de verdad
1. Elige clientes de tus propios datos analíticos, no de una lista genérica — típicamente Gmail en web y móvil, Apple Mail en macOS e iOS, y Outlook en Windows y web. 2. Clasifica el comportamiento oscuro de cada celda: respeta los colores originales, fuerza la inversión, o admite estilos oscuros opt-in. 3. Añade el tipo de cuenta donde importe: Gmail en un navegador sanitiza el CSS de forma distinta a Gmail consultado desde un cliente nativo. 4. Prueba cada plantilla en claro y en oscuro. El modo claro se rompe en cuanto alguien empieza a añadir trucos específicos para oscuro. 5. Vuelve a ejecutar tras cada cambio de plantilla y tras las actualizaciones importantes de los clientes, porque su comportamiento cambia sin previo aviso.
Guarda la matriz en el control de versiones junto a las plantillas, con una captura adjunta a cada celda. Eso convierte "el modo oscuro está roto" en un hallazgo reproducible en lugar de un estado de ánimo.
Lo que se rompe de verdad: logos, imágenes, contraste
- Los logos PNG con transparencia desaparecen bajo el oscuro forzado: el algoritmo oscurece el fondo pero deja solos los píxeles transparentes, así que un logo oscuro flota invisible.
- Las imágenes con fondo blanco horneado se renderizan como rectángulos brillantes que agujerean un diseño oscuro.
- Los botones construidos con imagen se invierten de forma impredecible; los botones construidos con HTML y CSS sobreviven mejor porque los clientes los remapean con consistencia.
- Los trazos finos y los bordes de 1px pierden contraste primero; la elegancia sutil se vuelve invisible.
- Los códigos QR deben ir siempre sobre una placa clara fija, o un remapeo de oscuro forzado puede volverlos ilegibles.
Las mitigaciones estándar: acolcha los logos y redondea las esquinas sobre una placa clara fija; envía una variante oscura del recurso para los clientes que admitan opt-in; declara el soporte de color-scheme en el head para que los clientes cooperativos sepan que consideraste ambos modos; y audita cada imagen según cómo se comporta cuando su fondo desaparece.
Qué puede y qué no puede mostrar una bandeja temporal
Una bandeja desechable es un punto de observación agnóstico del renderizado. Recibe el mensaje y te deja inspeccionar exactamente lo que se envió: el HTML fuente completo, el CSS, las URLs de las imágenes y las cabeceras. Eso responde a un conjunto específico de preguntas de alto valor:
- ¿Sobrevivieron los metadatos de modo oscuro y las media queries a tu canalización de envío, o un motor de plantillas o un preprocesador los eliminó en silencio?
- ¿Todas las URLs de imagen son accesibles, están bien dimensionadas, se sirven por HTTPS y pesan algo razonable?
- ¿La alternativa en texto plano está presente y es legible — el fallback que nunca se rompe en ningún modo?
- ¿Existen en el fuente ambas variantes de recursos, clara y oscura?
Lo que no puede hacer es emular el renderizado del cliente. Ninguna bandeja te muestra el comportamiento de Apple Mail o el remapeo de Outlook; para eso hacen falta clientes reales o servicios de capturas con motores auténticos. El reparto eficiente: comprobaciones a nivel de fuente con una bandeja temporal en cada build — el flujo descrito en correo temporal para probar plantillas de email — y la matriz completa de clientes con calendario y antes de cada release.
Un flujo de comprobación antes de pasar la matriz
1. [Crea una bandeja temporal](/) y envíale la plantilla candidata a través de tu canalización real de envío, no de una vista previa local, para que el preprocesamiento quede incluido. 2. Recupera el HTML crudo y verifica que los metadatos de modo oscuro, las media queries y ambas variantes de recursos están presentes. Si falta algo, compara contra el fuente de la plantilla; cuando sospeches que el lado del envío destrozó más que estilos, el analizador de cabeceras de email muestra qué pasó en tránsito. 3. Valida cada URL de imagen: estado, tipo de contenido, dimensiones, peso. Arregla lo roto antes de gastar tiempo de matriz de clientes en ello. 4. Después ejecuta la matriz y captura cada celda en claro y en oscuro.
Provisionar bandejas y recuperar el fuente por API convierte esto en una comprobación por despliegue; consulta automatizar pruebas de email con la API, y prototipa las llamadas primero en el probador de API.
Preguntas frecuentes
¿Puedo automatizar por completo las pruebas de modo oscuro? En parte. Las comprobaciones a nivel de fuente — metadatos presentes, imágenes válidas, texto plano existente — se automatizan bien con una bandeja desechable. El renderizado final necesita motores reales, así que automatízalo con herramientas de captura en dispositivos reales o virtuales, disparadas con calendario en vez de por commit.
¿Los clientes de email respetan prefers-color-scheme? De forma desigual. Algunos clientes soportan la media query en contextos alojados o embebidos, otros eliminan por completo los bloques de estilo, y el webmail difiere de las apps nativas. Trata el soporte como por cliente, verifícalo en tu matriz, y mantén un diseño que se degrade con seguridad cuando la query se ignora.
Mi logo se ve bien en Gmail pero desaparece en el modo oscuro de Outlook. ¿Por qué? Inversión forzada clásica: Outlook oscurece el fondo pero deja intactos los píxeles transparentes, así que un logo oscuro sobre transparencia desaparece. Pon el logo sobre una placa clara acolchada y redondeada, o envía una variante oscura donde el cliente la admita.
¿Existe un diseño que funcione en todas partes? Casi: un diseño claro y de alto contraste con fondo fijo, imágenes sobre placas claras, botones en HTML y CSS en lugar de botones imagen, y metadatos de modo oscuro como mejora progresiva. No será perfectamente oscuro en todas partes, pero se mantiene legible en todas.
Conclusión
Probar el modo oscuro mantiene la cordura cuando divides el problema: verifica qué se envió con bandejas desechables en cada build, y verifica cómo lo renderizan los clientes con una matriz pequeña y versionada con calendario. Cubre primero logos e imágenes — es donde el modo oscuro rompe de verdad — y prueba siempre el modo claro junto al oscuro, porque los trucos para uno son lo que rompe el otro.