Ya has pasado por todo el proceso de aprobación. El diseñador exporta un magnífico PDF de la campaña de correo electrónico. El departamento de marketing da el visto bueno. El departamento jurídico da su aprobación. El correo electrónico pasa a la fase de creación. Y luego se publica.
Y entonces alguien de tu equipo lo abre en Outlook y no se parece en nada a lo que todos habían aprobado.
Esta situación se repite constantemente en los equipos de marketing, y la causa principal no es el descuido ni un mal diseño. Se trata de una discrepancia fundamental entre lo que se puede verificar en la aprobación del PDF y cómo se muestra realmente el correo electrónico en HTML. Si tu proceso de revisión de campañas sigue basándose en la aprobación del PDF como último filtro, estás aprobando una ficción.
Nuestro artículo explica por qué existe esa brecha, qué coste supone y cómo estructurar un proceso de revisión de correos electrónicos en HTML que realmente detecte los problemas antes de que lleguen a la bandeja de entrada.
Un PDF del diseño de un correo electrónico es una instantánea estática. Te muestra una versión de cómo podría verse el correo electrónico, en un entorno de visualización perfecto, con un ancho de ventana de visualización fijo, con las imágenes cargadas y las fuentes aplicadas exactamente como se pretendía.
Lo que no te dice es cómo se verá el correo electrónico en Gmail en un teléfono Android. Ni en Outlook 2019 en Windows 11. Ni en Apple Mail con el modo oscuro activado. Ni para la parte de tu público que tiene las imágenes bloqueadas por defecto.
La diferencia entre el PDF y el HTML en tiempo real no es meramente estética. Puede significar:
Ninguno de estos fallos es visible en un PDF. Todos ellos son visibles para tus suscriptores.
La estandarización web que se ha producido durante la última década ha pasado en gran medida de largo por el correo electrónico. Navegadores como Chrome, Firefox y Safari convergieron hace años en estándares de visualización comunes. Los clientes de correo electrónico nunca lo hicieron.
Cada cliente utiliza su propio motor de renderización con su propia interpretación de HTML y CSS. Gmail elimina los bloques de estilo incrustados y aplica sus propias reglas CSS. Outlook para Windows utiliza el motor de Word, que ignora características CSS modernas como flexbox y trata ciertos diseños de forma completamente diferente a cualquier navegador. Apple Mail utiliza WebKit y se comporta más como un navegador, pero introduce su propio comportamiento en modo oscuro. Yahoo, Samsung Mail y una docena de otros clientes añaden cada uno su propia capa de variación.
Si multiplicamos eso por el sistema operativo, el tipo de dispositivo, la resolución de pantalla, el navegador (en el caso del correo web) y si el modo oscuro está activo, el número de entornos de visualización distintos para cualquier campaña puede superar los cincuenta.
Un proceso de aprobación en PDF no solo pasa por alto algunos de estos entornos. Los pasa por alto todos.
Las consecuencias de detectar problemas de visualización tras el envío van desde lo molesto hasta lo realmente costoso.
Coherencia de la marca. Un correo electrónico que se visualiza con una fuente incorrecta, imágenes que faltan o un diseño defectuoso da una mala imagen de la marca, independientemente de lo que mostrara el PDF aprobado. Las partes interesadas que dieron el visto bueno a un diseño pulido a menudo no relacionan el correo electrónico defectuoso que se envía con un proceso de revisión defectuoso. Simplemente saben que tiene mal aspecto.
Rendimiento de la campaña. Las llamadas a la acción que no funcionan, los diseños colapsados y los botones invisibles no solo tienen mal aspecto. Reducen directamente las tasas de clics. Si el principal elemento de conversión de una campaña no se muestra correctamente en Outlook, y Outlook representa una parte significativa de las bandejas de entrada de tu público, habrás socavado tu propia campaña.
Riesgos de cumplimiento normativo. En los sectores regulados, los creativos de marketing no solo deben tener un aspecto correcto, sino que también deben contener el contenido adecuado en el orden correcto. Un correo electrónico que se muestra de forma diferente a lo aprobado crea una discrepancia entre lo que se autorizó y lo que se envió. Esa es una posición más difícil de defender en una auditoría. Para obtener más información sobre cómo los fallos en el proceso de aprobación se agravan en entornos regulados, nuestro artículo sobre los costes ocultos de las aprobaciones de creatividades por correo electrónico trata este tema con más detalle.
Ciclos de revisión desperdiciados. Detectar un problema de visualización tras el envío es peor que detectarlo antes del envío, pero detectarlo tras la aprobación y antes del envío sigue siendo ineficaz. La reelaboración tras la producción requiere reabrir el ciclo de aprobación, lo que cuesta tiempo y genera confusión entre versiones.
Sustituir la aprobación en PDF por un proceso más sólido no significa añadir complejidad por el simple hecho de hacerlo. Significa revisar el recurso en el formato y el entorno en el que realmente se va a utilizar.
Así es como se lleva a cabo en la práctica una revisión eficaz de los correos electrónicos en HTML.
1. Revisar el archivo HTML activo, no una exportación estática
Las partes interesadas deben revisar el correo electrónico codificado real en un entorno renderizado por el navegador, no una imagen plana. Esto implica dar a los revisores acceso a la versión HTML para que puedan realizar anotaciones y dar su visto bueno, con el mismo tipo de flujo de trabajo estructurado que los equipos de impresión y embalaje llevan años utilizando en las pruebas en línea. El formato que se revisa debe ser el mismo que se va a enviar.
2. Realiza pruebas en distintos entornos de cliente antes de las fases de aprobación
Las pruebas de visualización en los clientes deben completarse antes, y no después, de la revisión por parte de las partes interesadas. No tiene sentido obtener la aprobación de un contenido que aún no se ha validado para los entornos en los que se leerá. Una vez que se confirma que el HTML renderizado es estable en los clientes prioritarios, esa versión validada entra en el ciclo de aprobación.
3. Define tu matriz de clientes prioritarios basándote en los datos de la audiencia
No todos los clientes de correo electrónico tienen la misma importancia para cada campaña. Recopila datos abiertos por tipo de cliente para el segmento de audiencia relevante y elabora una lista de prioridades de prueba. Una campaña B2B dirigida a cuentas empresariales probablemente deba funcionar a la perfección en Outlook. Una marca DTC que se dirija a un público más joven podría dar mayor importancia a iOS Mail y Gmail. La matriz de pruebas debe reflejar el comportamiento real de la audiencia, no una suposición generalizada.
4. Incluye el modo oscuro en la revisión
La adopción del modo oscuro es significativa y va en aumento. Se estima que entre el 35 % y el 50 % de las aperturas de correo electrónico se producen en modo oscuro en diversas audiencias, con algunos segmentos de usuarios de Apple Mail que registran porcentajes considerablemente más altos. Un correo electrónico en HTML que no se haya revisado en modo oscuro no se ha revisado adecuadamente. La versión aprobada debe validarse tanto en modo claro como en modo oscuro antes de su aprobación definitiva.
5. Revisa en el móvil, no solo en el ordenador
Los PDF casi siempre se revisan a escala de ordenador de sobremesa. Sin embargo, una parte significativa de las aperturas de correos electrónicos se produce en dispositivos móviles. Si tu proceso de aprobación no incluye una comprobación de la visualización en dispositivos móviles, no estás viendo la experiencia que tendrá una gran parte de tus suscriptores.
6. Condiciona la aprobación al código HTML, no a la maqueta de diseño
Este es el cambio fundamental. Los flujos de trabajo de aprobación deben activarse a partir del código HTML, no del archivo de diseño. El PDF o la maqueta de Figma siguen siendo útiles para la orientación del diseño y la coordinación creativa inicial. Pero el paso de aprobación formal, el que autoriza el envío de la campaña, debe basarse en el recurso real en el formato en el que llegará a los suscriptores.
Para los equipos que gestionan grandes volúmenes de campañas de correo electrónico junto con otros tipos de contenido, el problema de la revisión de los correos electrónicos en HTML suele formar parte de un reto de proceso más amplio. Los distintos activos —PDF, imágenes, HTML, vídeo, material de embalaje y creatividades publicitarias digitales— se revisan en herramientas diferentes con registros de aprobación distintos. Los comentarios están dispersos. El control de versiones es manual. No existe una visión única de lo que se ha aprobado y lo que no.
Las plataformas estructuradas de revisión en línea abordan este problema directamente. DALIM FUSION permite la revisión y aprobación de archivos HTML junto con otros tipos de contenido en un entorno unificado. Las partes interesadas pueden añadir anotaciones directamente sobre el recurso renderizado, seguir un flujo de trabajo de aprobación configurable y dejar un registro de auditoría documentado, independientemente del formato que se esté revisando. Para los equipos que gestionan campañas multicanal en las que un correo electrónico, un banner web, un recurso para redes sociales y un encarte impreso deben revisarse y aprobarse antes de la fecha de lanzamiento, disponer de esos ciclos de revisión en un único lugar marca una diferencia sustancial en la eficiencia del proceso.
Si actualmente estás evaluando plataformas y quieres saber qué aspectos debes tener en cuenta, nuestra guía para elegir un software de revisión en línea te indica las preguntas adecuadas que debes plantearte antes de tomar una decisión.
El principio subyacente es el mismo, tanto si utilizas una plataforma especializada como si creas un proceso manualmente: la aprobación debe realizarse sobre el recurso real, en un formato que represente cómo se percibirá realmente. En el caso de los correos electrónicos en HTML, eso significa revisar el código HTML.
Incluso los equipos que dejan de lado la aprobación exclusiva en PDF pueden caer en patrones que socavan la mejora.
Revisar capturas de pantalla en lugar del HTML en vivo. Las capturas de pantalla de la visualización de los correos electrónicos son mejores que los PDF, pero siguen siendo estáticas. No tienen en cuenta los elementos interactivos, el contenido dinámico ni el comportamiento real del recurso en un entorno de bandeja de entrada real.
Realizar pruebas en muy pocos clientes de correo. Los equipos suelen realizar pruebas en Gmail y Outlook y dar el trabajo por terminado. Los clientes prioritarios varían según el público, y una prueba básica en dos clientes puede pasar por alto importantes fallos de visualización para una parte significativa de los destinatarios.
Aprobar el archivo de diseño en lugar de la implementación. La aprobación por parte de las partes interesadas de un diseño en Figma o PSD no autoriza el HTML. El diseño y la implementación son dos cosas diferentes, y se producen cambios en la conversión.
Realizar pruebas de visualización tras la aprobación. El orden es importante. La validación de la visualización debe ser un requisito previo al ciclo de aprobación, no posterior a él.
Descuidar la accesibilidad. El Informe de Accesibilidad 2026 del Email Markup Consortium, que analizó más de 376 000 correos electrónicos en HTML, reveló que la gran mayoría sigue presentando problemas de accesibilidad clasificados como «graves» o «críticos». Los fallos más comunes —atributos de idioma que faltan, contraste de color deficiente, ausencia de texto alternativo y jerarquía de encabezados incorrecta— se han mantenido prácticamente sin cambios año tras año. Un proceso de aprobación que no incluya comprobaciones de accesibilidad pasa por alto un área de riesgo cada vez mayor, especialmente para las marcas que operan en mercados regulados o aquellas sujetas a las Pautas de Accesibilidad al Contenido Web (WCAG 2.2) del W3C, que se convirtieron en norma ISO en 2025 y sirven de base para la Ley de Accesibilidad Europea y los requisitos equivalentes de EE. UU.
¿Por qué los correos electrónicos en HTML se ven diferentes en distintos clientes de correo electrónico?
Los clientes de correo electrónico utilizan sus propios motores de renderizado para interpretar el HTML y el CSS, y dichos motores no siguen un estándar unificado como lo hacen los navegadores web modernos. Outlook para Windows utiliza el motor de Microsoft Word, que tiene una compatibilidad limitada con CSS. Gmail elimina ciertos bloques de estilo. Apple Mail utiliza WebKit. El resultado es que un código HTML idéntico puede producir diseños, fuentes, espaciados y comportamientos significativamente diferentes dependiendo del cliente que lo abra.
¿Se pueden aprobar campañas de correo electrónico en HTML a partir de un PDF?
La aprobación mediante PDF solo es adecuada para verificar la intención del diseño, no para autorizar el envío de una campaña. Un PDF no refleja cómo se mostrará el HTML en los distintos clientes de correo electrónico, dispositivos o modos de visualización. Utilizar la firma del PDF como paso final de aprobación significa que las partes interesadas están aprobando un archivo de diseño estático en lugar del recurso real que recibirán los suscriptores.
¿Qué debe incluirse en un proceso de aprobación de correos electrónicos en HTML?
Un proceso eficaz de aprobación de correos electrónicos en HTML debe incluir pruebas de visualización en los principales entornos antes de que comience la revisión por parte de las partes interesadas; comprobaciones en dispositivos móviles y en modo oscuro; anotaciones y comentarios sobre la versión HTML en funcionamiento, en lugar de una exportación estática; un flujo de trabajo de aprobación estructurado con revisores y fases de aprobación definidas; validación de la accesibilidad según las WCAG 2.2; y un registro con control de versiones de lo que se aprobó y cuándo.
¿Cómo se prueban los correos electrónicos en HTML en diferentes clientes de correo electrónico?
Las herramientas de prueba de correos electrónicos generan vistas previas de cómo se mostrará un correo electrónico en HTML en un gran número de combinaciones de clientes, dispositivos y sistemas operativos. La lista de clientes prioritarios debe ponderarse en función de los datos de la audiencia, en lugar de intentar lograr una visualización perfecta en todas partes. Los clientes principales dentro de la variedad de dispositivos de la audiencia deben validarse antes de que el correo electrónico entre en el ciclo de aprobación.
¿Qué es la visualización de correos electrónicos en modo oscuro y por qué es importante?
El modo oscuro es una configuración del sistema operativo o de la aplicación que cambia la interfaz de usuario a fondos oscuros con texto más claro. Los clientes de correo electrónico implementan el modo oscuro de forma diferente: algunos invierten automáticamente los colores, otros ajustan parcialmente los elementos y otros no modifican los correos electrónicos. Un correo electrónico diseñado para fondos claros puede volverse ilegible en el modo oscuro si no se ha probado específicamente, ya que el texto claro puede resultar invisible sobre un fondo oscuro.
¿Qué revelan los estudios sobre accesibilidad del Email Markup Consortium?
Los informes anuales del Email Markup Consortium constatan sistemáticamente que la gran mayoría de los correos electrónicos en HTML contienen problemas de accesibilidad calificados como «graves» o «críticos». Su informe de 2026, basado en más de 376 000 correos electrónicos, muestra solo una mejora marginal respecto al año anterior. Los fallos más comunes incluyen la falta de atributos de dirección lingüística, contraste de color insuficiente, ausencia de texto alternativo y estructura de encabezados defectuosa: problemas sistémicos arraigados en las plantillas y procesos estándar, no casos aislados.
¿Cómo se aplican las WCAG a las campañas de correo electrónico en HTML?
Las WCAG (Pautas de Accesibilidad al Contenido Web), publicadas por el W3C, son la norma reconocida internacionalmente para la accesibilidad del contenido digital. Las WCAG 2.2 se aprobaron como norma ISO en 2025 y sirven de base para la Ley de Accesibilidad de la Unión Europea, así como para requisitos similares en la legislación estadounidense. Sus principios fundamentales —perceptible, manejable, comprensible y robusto— se aplican directamente al correo electrónico en HTML. Los equipos de sectores regulados o que operan en la UE y EE. UU. deben considerar las WCAG 2.2 Nivel AA como referencia para la revisión de campañas.
¿Cómo encaja la revisión de los correos electrónicos en HTML en el proceso de aprobación de campañas multicanal?
Para los equipos que gestionan campañas a través del correo electrónico, los medios impresos, los canales digitales y las redes sociales, gestionar la revisión de los correos electrónicos en HTML por separado de otros tipos de activos genera confusión entre versiones y registros de auditoría fragmentados. Las plataformas como DALIM FUSION, que permiten la revisión y aprobación de múltiples tipos de archivos dentro de un entorno de flujo de trabajo unificado, proporcionan a los equipos un único registro de lo que se ha aprobado en todos los activos de la campaña y reducen el riesgo de que se publique una versión errónea de cualquier activo.
10 minutos de lectura
Rebecca Freeman : Jul 16, 2026 3:28:48 PM
Todo empieza de forma bastante inocente. Se envía un recurso de la campaña para su revisión. Una de las partes interesadas pide un pequeño ajuste....
1 minutos de lectura
Rebecca Freeman : Jul 16, 2026 3:09:35 PM
Puntos clave Los trabajos de impresión de datos variables (VDP) no superan la fase de aprobación porque el proceso de revisión está diseñado para...
1 minutos de lectura
Rebecca Freeman : Jul 16, 2026 1:51:41 PM
Seguro que te ha pasado. Se lanza un producto. Alguien detecta un error en la declaración de alérgenos de la etiqueta. O el código de barras no se...
Rebecca Freeman