IA para crear emails en HTML: qué producen realmente ChatGPT, Claude y Gemini

Hay una pregunta que circula ahora mismo por los círculos del email marketing, y suele sonar así: ahora que puedo pedirle a una IA que me cree un email en HTML en diez segundos, ¿sigo necesitando un editor de emails?

Es una pregunta justa. El correo no es un canal pequeño. En todo el mundo se envían unos 376 mil millones de emails cada día a fecha de 2025 (Radicati), el canal sigue devolviendo alrededor de $36 por cada $1 invertido según Litmus, y la mayoría de los profesionales del marketing ya usa IA en algún punto de su flujo de trabajo según la investigación de HubSpot sobre tendencias de IA en 2025. Si una herramienta puede generar una plantilla terminada a partir de un prompt de una línea, saltarse el editor parece una victoria obvia.

Luego envías la cosa de verdad y el panorama cambia rápido. Entre los emails que comprobamos en Unspam, solo el 30% supera nuestras comprobaciones de buenas prácticas de HTML (las cifras de benchmark de este artículo salen de nuestro benchmark de entregabilidad, los doce meses hasta junio de 2026). El cuerpo HTML es la parte más débil de la campaña media que medimos, por detrás de los asuntos, por detrás de los enlaces, por detrás incluso del lenguaje que activa los filtros de spam. Y es exactamente la parte que la gente está empezando a delegar en una herramienta que nunca se construyó para eso.

Esa brecha es toda la historia. Estas herramientas son buenas escribiendo un email. Todavía no son buenas escribiendo el HTML de un email, y son dos cosas muy distintas. Este artículo repasa qué producen en realidad las principales herramientas de IA, por qué el HTML del correo es un lenguaje propio, dónde aparece la diferencia en la bandeja de entrada y cómo un editor específico como Postcards cierra esa brecha. Termina con una lista de comprobación previa al envío que puedes aplicar a cualquier email, lo haya escrito un modelo o lo hayas escrito tú.

Hay una idea que recorre todo esto, así que conviene decirla claramente ya: parecer terminado en un navegador y renderizarse correctamente en una bandeja de entrada son dos cosas distintas, y la única prueba que decide cuál de las dos tienes es abrir el archivo en una comprobación real de bandeja de entrada.

Esto es lo que cubre el artículo:

• Por qué el HTML web y el HTML del correo son dos lenguajes completamente distintos, y sobre qué reglas concretas cae la brecha
• Qué producen por defecto v0, Bolt, Cursor, Replit, ChatGPT, Claude, Gemini y Lovable, y dónde falla cada uno
• Cómo se comparan la IA integrada en los ESP y los editores de email dedicados en portabilidad y renderizado
• Dónde te cuesta la llegada a la bandeja de entrada un HTML roto, con datos del propio benchmark de Unspam
• Una lista de comprobación previa al envío con doce puntos que todo email debería superar antes de salir
• El flujo de trabajo que usa la IA donde ayuda y un editor probado donde importa

El HTML web y el HTML del correo no son el mismo lenguaje

La razón por la que las herramientas de IA se atascan con el correo no tiene nada que ver con lo listo que sea el modelo. Es que casi todos los generadores con IA se entrenaron para producir páginas web modernas, y el correo se construye sobre un conjunto de reglas completamente diferente y mucho más antiguo.

Un navegador es un motor, una bandeja de entrada son decenas

Un navegador web es un único motor de renderizado moderno y conforme a los estándares. Una bandeja de entrada son decenas de motores inconsistentes. Uno de los clientes de correo corporativos más extendidos, Outlook para Windows, renderiza tu HTML con el motor de Microsoft Word, no con un navegador. Gmail reescribe y elimina partes de tu código antes de mostrarlo. El sitio de referencia Can I Email hace seguimiento de más de 300 características de HTML y CSS en unos 20 clientes de correo, un gran salto frente a las 50 características que cubría cuando se lanzó en 2019. Muchas de sus entradas se probaron por última vez hace años, así que las cifras de compatibilidad son estimaciones más que una foto en vivo, y la distancia entre los mejores y los peores clientes de correo es enorme.

Dónde abren el correo tus lectores de verdad

Aquí está dónde lee la mayoría de la gente, que es la parte que hace que todo esto importe:

Apple Mail y Gmail juntos suman cerca del 89% de las aperturas. (La cifra de Apple está inflada porque su Mail Privacy Protection cuenta muchas aperturas que puede que no sean humanas, así que trátala como un techo, pero la concentración es real). El problema es que Gmail, el segundo cliente de correo más habitual, es también uno de los más agresivos reescribiendo tu CSS, y el Outlook clásico, aunque tenga poca cuota, sigue muy desplegado en las oficinas y es donde peor se rompen los diseños. Así que los clientes de correo que castigan el HTML de estilo web son justo los que no puedes ignorar.

Las diferencias concretas que la IA hace mal

Estas son las diferencias concretas que una herramienta de IA tiene que acertar, y normalmente no acierta:

Nada de esto es exótico para quien desarrolla correo. Simplemente es invisible para una herramienta pensada para páginas web, y para la persona que la usa. Para un recorrido más profundo por las reglas en sí, nuestra guía de buenas prácticas de HTML para email cubre en detalle la parte de escribir el código a mano.

Por qué los porcentajes de compatibilidad mienten

Es fácil buscar una característica, ver un número de compatibilidad alto y suponer que estás a salvo. Normalmente no lo estás, porque los números esconden dónde caen los huecos. Según Can I Email, display: flex y display: grid muestran alrededor de un 83% de compatibilidad cada uno, lo que suena bien hasta que recuerdas que el motor de Word en Outlook ignora ambos, así que una maquetación construida sobre flex o grid se derrumba ahí en silencio. La propiedad CSS position muestra cerca del 80%, pero solo un tercio de eso es compatibilidad total y el resto es parcial: la mayoría de clientes de correo respeta solo algunos valores, y Outlook de escritorio no respeta ninguno. Las fuentes web con @font-face se quedan cerca del 24%, y las propiedades personalizadas de CSS (variables) cerca del 45%, con el Outlook clásico sin admitir ninguna variable y con Gmail permitiendo el uso de var() pero no las declaraciones que las definen. Ese último par es la razón de que un resultado de IA que se apoya en una fuente web y en un sistema de color basado en variables, exactamente como un modelo estiliza una página web moderna, pierda su tipografía y sus colores de marca en cuanto aterriza en una bandeja de entrada real. Un porcentaje de titular es una media entre clientes de correo que pondera a todos por igual. El correo no.

Qué producen en realidad las herramientas de IA de propósito general

Empecemos por las herramientas a las que la gente recurre primero: los generadores de sitios y de aplicaciones, y los chatbots. Lo importante que hay que entender es que ninguno de ellos es un producto de correo. Son generadores web que además emiten HTML, así que la gente los reutiliza.

Los generadores de aplicaciones: herramienta correcta, trabajo equivocado

v0, Bolt, Cursor y Replit son generadores de aplicaciones. Pedirles un email es como pedirle una hoja de cálculo a un procesador de textos: puedes forzarlo, pero peleas con la herramienta todo el camino, y el resultado es HTML web moderno que una bandeja de entrada nunca iba a renderizar como prometía la vista previa.

Los chatbots y la trampa de la vista previa

Los chatbots merecen un aviso específico, porque crean una trampa. El Canvas de ChatGPT y los Artifacts de Claude renderizan una vista previa en vivo del HTML que generan. Esa vista previa usa un motor de navegador. Así que tu email con IA parece terminado y pulido en pantalla, que es precisamente la razón de que la rotura sea invisible hasta que lo envías a una bandeja de entrada real. Este es el mayor motivo por el que la gente se lleva un chasco: la vista previa miente, no a propósito, sino porque un navegador no es Outlook.

Los modos de fallo son consistentes. Una maquetación que se ve limpia en la vista previa se apoya en propiedades que Outlook ignora, como max-width en una tabla o flexbox, así que las columnas se derrumban o se salen del borde. Las fuentes web caen a una por defecto como Times New Roman. Los botones redondeados se cuadran. Y cualquier estilo que no se pusiera en línea simplemente desaparece en partes de Gmail.

Ese último punto merece concretarse, porque es más grande de lo que suena. Cuando la app de Gmail renderiza correo de una cuenta que no es de Google, una configuración lo bastante común como para tener su propio apodo (GANGA, Gmail App with Non-Google Accounts), no admite en absoluto la etiqueta <style>, así que cada regla que un modelo dejó en un bloque de estilos de la cabecera se descarta para todo ese segmento de lectores. Gmail además es de todo o nada con los estilos incrustados: un solo error que no le guste, como una regla @font-face o @media anidada dentro de otra regla-at, hace que elimine el bloque de estilos entero, y aplica un límite duro de tamaño por bloque (históricamente en torno a los 8KB). Un chatbot que amontona con total confianza todo tu CSS en una gran etiqueta <style> está escribiendo exactamente lo que Gmail tiene más papeletas de tirar a la basura.

La única excepción parcial

Lovable es la única excepción parcial que merece nombrarse. Como enruta la generación de emails a través de la librería React Email, produce por defecto marcado basado en tablas y con estilos en línea, y su documentación incluso menciona el límite de recorte de Gmail de unos 102KB. Eso sí está genuinamente más cerca de lo correcto. Sigue sin gestionar por su cuenta los comentarios condicionales de Outlook, el modo oscuro o las particularidades de Apple Mail, y sigue siendo en el fondo un generador de aplicaciones web, pero enseña qué aspecto tiene lo "consciente del correo" cuando una herramienta lo intenta de verdad.

Cómo guiar a un chatbot hacia un HTML seguro para el correo

Puedes obtener un resultado utilizable de un chatbot general, pero solo si le entregas el conocimiento sobre correo que no aplica por su cuenta. En la práctica eso significa detallar cada requisito en el prompt. El mínimo para conseguir un resultado utilizable:

• Construir la maquetación sobre tablas anidadas, no sobre divs ni flexbox
• Poner cada estilo en línea en el elemento, no en un bloque <style>
• Envolver los arreglos específicos de Outlook en comentarios condicionales MSO (<!--[if mso]>...<![endif]-->)
• Dar a cada fuente web una pila real de alternativas con nombre (Arial, Georgia, una fuente del sistema)
• Mantener el archivo entero por debajo del límite de recorte de Gmail de unos 102KB
• Incluir una versión en HTML y otra en texto plano

Aun así, dos cosas siguen siendo ciertas. El modelo no mantiene de forma fiable ese modo a lo largo de las ediciones, así que la tercera revisión vuelve calladamente a los hábitos web. Y la única manera de saber si cumplió es probar el resultado en clientes de correo reales, no confiar en que siguió las instrucciones. Si ya estás usando IA para los textos, nuestra recopilación de prompts de ChatGPT para email marketing es un uso mejor de las mismas herramientas.

"Pero mi plataforma de correo ya lleva IA integrada"

Lo siguiente que dice la gente es que su ESP o su editor ya tiene IA, así que esto está resuelto. A veces. El problema es que "IA para el correo" significa tres cosas muy distintas, y el marketing las difumina a propósito.

Tres cosas que puede significar "IA para el correo"

• IA que escribe textos. Asuntos, cuerpo del mensaje, una llamada a la acción. Es el tipo más común y el menos arriesgado, porque una persona sigue colocando las palabras dentro de una maquetación probada.
• IA que ensambla secciones editables. Te da una estructura aproximada con bloques de marcador de posición que terminas a mano. La IA de email de Klaviyo funciona así, y su propia documentación señala que todavía tienes que añadir botones, enlaces e imágenes a mano antes de que esté lista para enviarse.
• IA que genera una plantilla completa. Maquetación, textos, a veces imágenes, desde un solo prompt. Esta es la demo impresionante, y también donde el marcado en sí se convierte en el resultado sin verificar.

El eje que importa para la entregabilidad: portabilidad y pruebas

Luego hay un segundo eje que importa aún más para la entregabilidad: ¿puedes llevarte el HTML a cualquier parte y hay algo que pruebe cómo se renderiza? Así se comparan los editores de email dedicados, las herramientas cuyo trabajo entero es entregarte HTML portable.

Los cuatro exportan HTML portable que puedes llevarte a cualquier ESP, que es justo el sentido de un editor. Donde más se diferencian es en cuánto trabajo hace la IA. Postcards, Unlayer y Stripo ofrecen un flujo completo guiado por prompts, mientras que la IA de Beefree escribe textos e imágenes y te deja a ti la maquetación. Los cuatro muestran también una previsualización del renderizado, pero una previsualización rápida no es lo mismo que una prueba profunda en distintos clientes de correo, así que los equipos cuidadosos siguen validando el HTML final en una comprobación dedicada antes de enviar. El contraste con un ESP de plantilla completa como Mailchimp o HubSpot es todavía más marcado, porque esos tienden a encerrar el resultado dentro de su propio envío en lugar de entregarte código portable. Para una comparativa completa y ordenada de estos editores dedicados en plantillas, IA, colaboración y entregabilidad, consulta nuestra guía de los mejores editores de plantillas de email de 2026.

Dónde te cuesta esto de verdad: la bandeja de entrada

Es tentador afirmar que un HTML malo te manda directo a spam. Es más honesto, y más útil, ser preciso sobre cómo ocurre realmente el daño, porque exagerarlo es la forma de perder credibilidad.

Un HTML malo no va directo a spam, llega ahí de forma indirecta

Los filtros modernos de Gmail, Outlook y Yahoo se guían sobre todo por la reputación del remitente y la interacción de quien recibe, no por una pulcra puntuación de calidad del HTML. Así que un marcado desordenado generado con IA rara vez activa una penalización directa. El camino real es indirecto, y es el que describe Litmus en sus propias recomendaciones de entregabilidad de febrero de 2026: un email que se renderiza roto hace que la gente dude de él, la duda baja la interacción y sube las quejas, y una interacción débil junto con las quejas es exactamente lo que daña tu reputación como remitente y empuja los envíos futuros hacia spam. Las reglas de Google para remitentes masivos ponen una cifra dura a la señal más dañina: mantén las quejas de spam por debajo del 0,1%, que es una de cada mil. Una plantilla que se ve rota en una cuarta parte de las bandejas de entrada es una forma rápida de cruzar esa línea.

El cuerpo HTML es la parte más débil de la campaña media

Vemos este patrón en nuestros propios datos. Entre los emails pasados por Unspam durante los doce meses hasta junio de 2026, el cuerpo HTML es de forma consistente el área más débil de todo el mensaje:

Vuelve a leer la primera fila. El HTML es la comprobación que más emails suspenden, por un margen amplio, y muchos más que los que suspenden en asuntos o en palabras spam. Es además la comprobación que tienes más papeletas de delegar en un chatbot.

Recorte, filtros heurísticos y otros enganches concretos

Hay unos cuantos enganches concretos más que conviene conocer sobre el HTML roto en particular:

• Los filtros heurísticos antiguos siguen existiendo aguas abajo. Filtros de código abierto como SpamAssassin todavía puntúan el correo solo en HTML sin parte de texto plano (vale un par de puntos) y el correo cargado de imágenes con poco texto. No son lo que ejecuta Gmail, pero describen los patrones en los que suele caer un resultado descuidado de IA, y muchas pasarelas corporativas todavía los usan.
• El recorte oculta tu enlace de baja. Si un marcado inflado te empuja más allá del umbral de Gmail de unos 102KB, Gmail trunca el mensaje. Si tu enlace de baja quedaba por debajo del corte, quienes se frustran pulsan "marcar como spam" en su lugar. Ten en cuenta que los archivos de imagen externos no cuentan para ese límite, solo el marcado, que es exactamente lo que las herramientas de IA tienden a producir de más.
• El modo oscuro no se puede entregar de forma uniforme. La consulta @media (prefers-color-scheme) se queda cerca del 42% de compatibilidad, Gmail solo la respeta parcialmente (aplica su propio tratamiento del color en lugar de tu consulta) y Yahoo la reescribe con sintaxis inválida. Outlook para Windows la ignora y en su lugar inyecta sus propios atributos, a los que tienes que apuntar por separado, mientras que Apple Mail invierte automáticamente el texto en #FFFFFF puro, por lo que quienes diseñan con cuidado usan un blanco roto. Un modelo que emite una única regla pulcra de modo oscuro ha cubierto una minoría de los clientes de correo que van a recolorear tu email de verdad.
• El HTML roto es la norma, no la excepción. Esto no es exclusivo de nuestras cifras. El informe de accesibilidad del Email Markup Consortium de 2026 analizó 376.348 emails reales y encontró que el 99,88% salió con defectos de accesibilidad graves o críticos, y que solo 8 superaron todas las comprobaciones. Esos defectos (tablas de maquetación sin rol de presentación, textos alt ausentes, sin idioma de documento) se remontan a los mismos hábitos que ponen la web primero, y la lección se mantiene: un HTML de correo limpio es difícil incluso para profesionales, así que un volcado sin probar de un chatbot difícilmente va a superar esa línea de base.

Cuánto vale un punto porcentual de llegada a la bandeja de entrada

Lo que está en juego no es abstracto. Según lo que valga cada email para tu programa, un solo punto porcentual de llegada a la bandeja de entrada en un envío de un millón de emails va de unos $1.000 con un valor típico de $0.10 por email a $20.000 con una lista de alto valor. En cualquier caso, una plantilla que se rompe calladamente para una cuarta parte de tu lista son ingresos recurrentes reales, no un fallo cosmético. Si quieres ver cómo puntúan tu propio dominio de envío y tu contenido en estos factores, el benchmark de entregabilidad de Unspam muestra datos agregados de millones de tests, y puedes pasar tu propio mensaje por las comprobaciones de abajo antes de enviarlo.

Qué significa de verdad estar listo para el correo: la lista de comprobación previa al envío

A estas alturas el patrón está claro: un borrador de IA puede parecer terminado y estar aún lejísimos de poder enviarse. Así que ayuda sustituir la vaga sensación de "esto parece terminado" por un estándar explícito. Este es el que aplicamos a un email antes de que salga, lo haya escrito quien lo haya escrito.

La vista previa es la señal más engañosa del correo

Merece la pena ser tajante sobre por qué. El código que se renderiza a la perfección en una pestaña del navegador, o en el panel de vista previa de un chatbot, se desmorona con frecuencia en Outlook, en la app de Gmail, en el webmail de Yahoo y AOL, y en pantallas móviles pequeñas. Ninguno de esos fallos aparece en un navegador, porque un navegador no está ejecutando ninguno de esos motores. La única prueba con sentido es abrir el HTML real en una comprobación de renderizado en clientes de correo reales y mirar las capturas. Todo lo que hay en la lista de abajo es algo que esa comprobación, no una vista previa, puede confirmar.

La lista: doce cosas que tienen que ser ciertas antes de enviar

Por qué un email casi perfecto sigue fallando

Lo importante de esa lista es que no es una media de puntos. Un email puede bordar once filas y seguir siendo imposible de desplegar por culpa de la duodécima. Un solo enlace de baja ausente, una fuente sin alternativa o una hoja de estilos sin poner en línea bastan para hundir el envío, y por eso "parece terminado al 90%" y "se puede enviar" son afirmaciones sin relación. Los borradores de IA fallan así constantemente: el diseño se ve genial y luego un único defecto bloqueante hace calladamente que todo el conjunto sea inservible.

La mayoría de esos defectos bloqueantes se remontan a un solo cliente de correo. El Outlook clásico para Windows, es decir, las versiones de 2007 a 2019 y el cliente de correo clásico de escritorio de Office 365, renderiza con el motor de Microsoft Word en lugar de con un navegador. Ese motor tiene un conjunto concreto de comportamientos que todo el mundo que desarrolla correo se ha memorizado:

• Ignora width y height en CSS, así que tienes que usar los atributos HTML width y height en las imágenes
• Quita padding y margin de las imágenes, así que en su lugar aplicas el relleno a la celda de tabla que las rodea
• Ignora width y padding en los divs, que es la razón de que las maquetaciones usen tablas en vez de divs
• Descarta por completo el estado :hover
• Muestra solo el primer fotograma de un GIF animado

También introduce sus propios errores. En pantallas de Windows escaladas al 125% o más distorsiona las maquetaciones a menos que declares el espacio de nombres de Office y fijes PixelsPerInch a 96 en un bloque condicional. Cae a Times New Roman siempre que una fuente web va primera en la pila, a menos que envuelvas la regla @font-face para que Outlook nunca la vea. Estos no son casos límite. Son el comportamiento por defecto del motor que hay detrás de una buena parte del correo corporativo, y un modelo entrenado con páginas web no tiene ninguna razón para escribir el andamiaje que los sortea.

Hay luz en el horizonte. El nuevo Outlook para Windows, en beta desde 2022 y en la tienda de Windows desde 2023, usa un motor de renderizado web en lugar de Word, y Microsoft ha empezado a dirigir a la gente hacia él. El cliente de correo clásico con motor de Word se irá apagando durante los próximos años, pero Microsoft se ha comprometido a mantenerlo hasta 2029 en muchos planes, así que todavía tienes que programar para el motor de Word, porque eso es lo que sigue usando una parte significativa de quienes te reciben.

Pasa tu borrador por esto antes de que salga

La lista solo sirve si pasas de verdad un email por ella, y no tienes que hacerlo a ojo. Manda el mensaje terminado a una herramienta que lo abra en clientes de correo reales y compruebe estos factores por ti. Nuestro comprobador de spam de Unspam cubre la parte de contenido, autenticación y calidad del código, y la prueba de Inbox Placement muestra dónde aterriza realmente el mensaje en Gmail, Outlook y Yahoo. Esa es la diferencia entre creer que un email está listo y saberlo.

Qué te da un editor específico, y dónde encaja la IA

Esta es la respuesta a la pregunta original.

Teclear nunca fue la parte difícil

Un editor de emails nunca fue para ahorrarte teclear HTML. La parte difícil es producir HTML que se renderice igual en decenas de clientes de correo inconsistentes, satisfaciendo cada fila de esa lista a la vez, y esa es la parte que resuelve un editor probado y no resuelve un chatbot.

El resultado de un LLM frente a un editor, estándar por estándar

Pon los dos uno al lado del otro frente a los estándares que de verdad deciden si un email se renderiza y aterriza. Esto es el resultado en bruto de un LLM de propósito general frente al HTML que emite un editor específico y probado en distintos clientes de correo.

El patrón es consistente: el LLM optimiza para lo que se ve bien en un navegador, y el editor optimiza para lo que sobrevive a la bandeja de entrada.

Cómo se satisface la lista por defecto

Toma Postcards como ejemplo trabajado. Sus más de 100 módulos están construidos a mano y, según cuenta Designmodo, probados en Litmus y Email on Acid en 16 clientes de correo, incluidos los que rompen el HTML web: Outlook de escritorio, la app de Gmail, Apple Mail, Yahoo, incluso clientes de correo antiguos como Lotus Notes. Cada plantilla se comprueba en responsive y en modo oscuro, y puedes verla en previsualizaciones en dispositivos reales en lugar de en una aproximación de navegador. El código exportado es HTML limpio y listo para producción que puedes enviar con un clic a los principales ESP, incluidos Mailchimp, HubSpot, Klaviyo, SendGrid, Brevo, Constant Contact, Zoho y SendPulse, o simplemente descargar como HTML en bruto. Los precios empiezan gratis, con planes de pago a $16 y $24 al mes.

Traslada eso a la lista y el valor se vuelve concreto. Las alternativas para Outlook y MSO, el CSS en línea, el comportamiento en modo oscuro y el renderizado en distintos clientes de correo no son cosas que compruebas a posteriori: vienen ya satisfechas, porque los módulos ya se construyeron y probaron así. Empiezas desde un aprobado en lugar de trabajar hacia atrás para conseguirlo.

El mismo prompt, un resultado seguro para el correo

Aquí está la parte que resuelve la cuestión de la IA en vez de pelearse con ella. Postcards te da el flujo de IA completo que la gente quiere de verdad: describe el email y te construye uno, y después edita el diseño, tradúcelo o cámbiale el estilo, todo desde un chat de prompts. La diferencia está en lo que sale. Un chatbot general te entrega HTML web en bruto y deja el renderizado al azar. Postcards genera contra sus módulos probados en distintos clientes de correo, así que la misma velocidad guiada por prompts produce HTML portable y seguro para el correo que ya satisface casi toda la lista. Consigues la experiencia de la IA sin heredar el problema de renderizado de la IA.

El flujo de trabajo que sí funciona

No tienes que elegir entre la IA y un editor. Los equipos que consiguen buenos resultados usan ambos, en el orden correcto.

Redacta con IA

Haz una lluvia de ideas del concepto, escribe los textos y genera opciones de asunto. Aquí es donde brillan los modelos, y no hay riesgo de renderizado en un párrafo de texto. Nuestra guía de prompts de ChatGPT está pensada para este paso.

Construye la plantilla en algo probado

Lleva esos textos a un editor cuyo HTML ya esté validado en distintos clientes de correo o, si programas, convierte el resultado de la IA a un framework de correo en lugar de enviar HTML en bruto de un chatbot. Los frameworks comparten un movimiento: un paso de compilación que transpila una sintaxis moderna y amable al HTML de tablas anidadas, estilos en línea y comentarios condicionales que los clientes de correo admiten de verdad:

• MJML compila su propio marcado de componentes a HTML responsive basado en tablas con estilos en línea
• React Email convierte React y Tailwind en un resultado probado en Gmail, Apple Mail, Outlook y Yahoo
• Maizzle compila Tailwind a HTML de producción con los estilos en línea y los condicionales mso ya incorporados

Ese paso de traducción es precisamente el trabajo que se salta el resultado en bruto de la IA.

Verifica antes de enviar

Pasa el email terminado por una comprobación de renderizado y de entregabilidad, que es donde de verdad lo enfrentas a la lista de antes. Usa la herramienta de previsualización de emails para ver capturas con precisión de píxel de tu HTML en más de 50 clientes de correo reales, en modo claro y oscuro, el comprobador de spam de Unspam para la autenticación y el contenido, y la prueba de Inbox Placement para ver dónde aterriza en Gmail, Outlook y Yahoo. Nuestra comprobación previa al envío de cinco minutos repasa toda la rutina.

Esa secuencia te da la velocidad de la IA en las partes que es seguro acelerar, y una base probada más una comprobación final en las que no lo es.

Entonces, ¿sigues necesitando un editor de emails?

Sí, pero la pregunta más útil es por qué, y la respuesta cambia según dónde te sitúes en la cadena de producción.

Si diseñas emails

Tu preocupación es la fidelidad de marca: la fuente del titular, la forma del botón, el cambio de color en modo oscuro, el espacio entre secciones. La IA es útil en la fase de briefing, generando direcciones de maquetación, iterando sobre conceptos visuales, probando una historia de color antes de comprometerte a construir nada. Pero en cuanto el diseño tiene que aguantar en bandejas de entrada reales, la brecha se abre rápido.

Las fuentes caen a Times New Roman en Outlook porque la declaración de la fuente web nunca se envolvió para ocultarla del motor de Word. Las esquinas redondeadas desaparecen porque el border-radius de CSS se ignora. Las imágenes de fondo se esfuman porque el motor de Word ignora los fondos en CSS, así que tu cabecera de marca oscura aterriza como una caja blanca vacía. Una maquetación de dos columnas cuidadosamente espaciada se derrumba en una sola columna apilada porque la estructura se construyó sobre flexbox y no sobre tablas anidadas. Nada de esto aparece en la vista previa de navegador que hizo que el resultado de la IA pareciera terminado.

Un editor probado resuelve esto a nivel de módulo. Los componentes ya se diseñaron para llevar los elementos de marca a través de los clientes de correo que te complican la vida: el botón sigue redondeado porque usa VML, el fondo aguanta porque hay un color de celda de tabla como alternativa, la maquetación se apila limpiamente en móvil porque la media query está escrita como toca. La visión de la IA es el briefing. El editor es donde el briefing se convierte en algo que una persona suscrita puede ver de verdad.

Si haces email marketing

Para quien hace marketing, la cuestión se reduce a los resultados de campaña. Los datos concretan el coste de un HTML malo: entre los emails comprobados a través de Unspam durante los últimos doce meses, solo el 30% supera las comprobaciones de buenas prácticas de HTML, la tasa de aprobado más baja de todo lo que medimos. La mayoría de campañas salen con defectos estructurales que quien las envía no sabía que estaban ahí.

Esos defectos aparecen en tus métricas. Un email que se renderiza roto baja la interacción porque se ve mal o cuesta leerlo. Una interacción más baja entrena a los filtros de la bandeja de entrada para dirigir los envíos futuros hacia spam. Un mensaje recortado por Gmail porque el marcado cruzó el límite de 102KB oculta el enlace de baja, y quienes se suscribieron pulsan frustrados "marcar como spam" en su lugar. Un punto porcentual de llegada a la bandeja de entrada en un envío de un millón de emails es una cifra de ingresos real, y se acumula en cada envío posterior.

La IA hace que el marketing vaya más rápido en todo lo que no toca el marcado: variantes de texto, tests de asuntos, tokens de personalización, ideas de secuenciación. Pero la plantilla tiene que salir de una base probada, porque un borrador rápido que se rompe en un tercio de las bandejas de entrada no es en realidad más rápido. Es un camino más rápido hacia un problema que no verás hasta que la campaña ya esté fuera.

Si desarrollas emails

Quien desarrolla ya sabe la respuesta, porque ha escrito bloques <!--[if mso]> y ha depurado por qué una maquetación que se renderiza limpiamente en Chrome se derrumba en Outlook con el escalado de pantalla al 125%. Su versión de la pregunta es más precisa: ¿en qué punto de la cadena encaja realmente la IA?

El encuadre útil es entrada frente a salida. La IA pertenece al lado de la entrada: redactar los textos de la plantilla, prototipar conceptos de maquetación antes de construirlos, escribir la versión en texto plano y, de vez en cuando, esbozar una primera pasada en MJML o React Email que después limpias. La salida, el HTML que llega de verdad a quienes se suscribieron, tiene que salir de un framework o de un editor probado que ya gestione las alternativas para el motor de Word, la puesta en línea del CSS, los condicionales MSO, la base de accesibilidad y el presupuesto de tamaño de archivo. Lo que produce la IA es un punto de partida. Lo que se envía es lo que sobrevive a un test real de renderizado en distintos clientes de correo.

Frameworks como MJML, React Email y Maizzle son la versión para quien desarrolla de la misma respuesta que un editor le da a quien diseña o hace marketing: una capa de traducción verificada entre una idea y una bandeja de entrada.

La respuesta es la misma desde los tres asientos

Tres roles, una conclusión. La IA trabaja en la capa del lenguaje, los navegadores renderizan en la capa web, y los clientes de correo operan en una tercera capa que ninguna de las dos entiende del todo. Un editor o un framework específico es la traducción entre el borrador de la IA y una bandeja de entrada que lo recibe correctamente.

Usa la IA para ganar velocidad en las partes donde la velocidad es segura: ideas, textos, asuntos. Usa el editor para el renderizado, donde no lo es. Haz la comprobación previa al envío en cualquier caso. Una vista previa de navegador te dice que un email parece terminado, nunca que se renderiza. El editor, más la comprobación, es lo que cierra esa brecha.