¿Gmail y Outlook bloquean los adjuntos .html?

No. Ambos publican los tipos de archivo que bloquean, sobre todo ejecutables y scripts como .exe, .js y .vbs, y .html no está en esas listas. El riesgo está del lado del destinatario: muchas pasarelas corporativas marcan o eliminan en silencio los adjuntos .html, porque un archivo HTML puede suplantar una página de acceso o ejecutar un script, lo que lo convierte en una herramienta de phishing habitual. No ves ese filtro desde tu lado, así que no puedes saber de antemano si tu archivo llega.

¿Qué experimenta el destinatario con cada opción?

Adjunto: un filtro corporativo puede marcarlo, o llega como descarga sin vista previa. El destinatario tiene que guardar el archivo y saber abrirlo en un navegador en lugar de hacer doble clic como si fuera un documento. Enlace: una URL de aspecto normal en el cuerpo del correo. Un clic abre una página renderizada en el navegador, exactamente como se pretendía.

¿Cuál permite saber si se abrió?

Solo el enlace. Una página alojada puede registrar una vista, una marca de tiempo, y (según el servicio) un país aproximado y el tiempo dedicado. Un adjunto no da nada después de enviarlo, no tienes forma de saber si se abrió alguna vez.

¿Y el tamaño del archivo o la interactividad?

Los adjuntos están limitados por los servidores de correo del remitente y del destinatario, a menudo unos pocos megabytes, y cualquier recurso externo referenciado por el HTML (imágenes, fuentes, scripts alojados en otro sitio) no cargará desde un archivo local. Un enlace alojado sirve el archivo como una página real, con toda su interactividad, formularios y recursos funcionando como se diseñaron.

¿Hay alguna situación en la que un adjunto sea la opción correcta?

Escenarios genuinamente sin conexión, enviar a alguien que abrirá el archivo sin ningún acceso a internet, o traspasos internos entre desarrolladores donde el destinatario quiere explícitamente el código fuente en bruto. Para cualquier cosa que llegue a un cliente, un prospecto, o un destinatario no técnico, un enlace es la opción por defecto más segura.

Guía

Enlace HTML vs adjunto de correo: cuál funciona de verdad

Un enlace gana en todo lo que importa para un archivo HTML. Un adjunto .html no lo bloquean Gmail ni Outlook, pero algunos filtros corporativos lo marcan o eliminan por precaución antiphishing, y aunque se entregue, se abre como archivo local en vez de como página en un servidor. Un enlace a una versión alojada del mismo archivo parece texto normal para un filtro antispam, se abre directamente en el navegador, se puede actualizar sin reenviar nada, y se puede rastrear para saber si se abrió. El único caso en que gana el adjunto es el acceso sin conexión, sin internet en absoluto.

La comparación, lado a lado

Pregunta	Adjunto	Enlace
Pasa los filtros antispam	Puede ser marcado	Sí
Se abre como página renderizada	No, descarga	Sí
Los recursos externos cargan bien	A menudo roto	Sí
Sabe si se abrió	No	Sí, con el servicio adecuado
Se puede corregir tras el envío	Requiere reenvío	Sí, misma URL
Funciona totalmente sin conexión	Sí	No, necesita conexión

Por qué el adjunto pierde específicamente en la entrega

El problema de fondo no es preferencia, es que el HTML es especialmente propicio para el phishing: un archivo que parece un documento también puede ser un formulario de acceso falso funcional o una redirección. Gmail y Outlook no bloquean la extensión, pero las pasarelas corporativas suelen marcarla o eliminarla, y el destinatario ve una descarga, no una página. Nada de esto depende de si tu archivo concreto es seguro, el filtro no puede distinguirlo en el momento de decidir marcarlo.

Convertir un archivo en enlace lleva más o menos el mismo esfuerzo que adjuntarlo

La objeción habitual a usar un enlace es que añade un paso. En la práctica, soltar el .html en un servicio pensado para esto (LiveSend, por ejemplo) y copiar la URL devuelta lleva menos de un minuto, más o menos lo mismo que localizar el archivo para adjuntarlo en primer lugar. La diferencia es que un camino llega al destinatario como página y el otro como descarga.

Resumen

A menos que el destinatario realmente no tenga acceso a internet, envía un enlace. No encuentra ningún filtro de adjuntos, se abre correctamente sin aviso de descarga, y permite saber si realmente se abrió.

¿Listo para convertir un archivo en enlace? Mira el camino más corto, sin conocimientos de hosting.

Preguntas frecuentes

¿Gmail y Outlook bloquean los adjuntos .html?
No. Ambos publican los tipos de archivo que bloquean, sobre todo ejecutables y scripts como .exe, .js y .vbs, y .html no está en esas listas. El riesgo está del lado del destinatario: muchas pasarelas corporativas marcan o eliminan en silencio los adjuntos .html, porque un archivo HTML puede suplantar una página de acceso o ejecutar un script, lo que lo convierte en una herramienta de phishing habitual. No ves ese filtro desde tu lado, así que no puedes saber de antemano si tu archivo llega.
¿Qué experimenta el destinatario con cada opción?
Adjunto: un filtro corporativo puede marcarlo, o llega como descarga sin vista previa. El destinatario tiene que guardar el archivo y saber abrirlo en un navegador en lugar de hacer doble clic como si fuera un documento. Enlace: una URL de aspecto normal en el cuerpo del correo. Un clic abre una página renderizada en el navegador, exactamente como se pretendía.
¿Cuál permite saber si se abrió?
Solo el enlace. Una página alojada puede registrar una vista, una marca de tiempo, y (según el servicio) un país aproximado y el tiempo dedicado. Un adjunto no da nada después de enviarlo, no tienes forma de saber si se abrió alguna vez.
¿Y el tamaño del archivo o la interactividad?
Los adjuntos están limitados por los servidores de correo del remitente y del destinatario, a menudo unos pocos megabytes, y cualquier recurso externo referenciado por el HTML (imágenes, fuentes, scripts alojados en otro sitio) no cargará desde un archivo local. Un enlace alojado sirve el archivo como una página real, con toda su interactividad, formularios y recursos funcionando como se diseñaron.
¿Hay alguna situación en la que un adjunto sea la opción correcta?
Escenarios genuinamente sin conexión, enviar a alguien que abrirá el archivo sin ningún acceso a internet, o traspasos internos entre desarrolladores donde el destinatario quiere explícitamente el código fuente en bruto. Para cualquier cosa que llegue a un cliente, un prospecto, o un destinatario no técnico, un enlace es la opción por defecto más segura.

Guías relacionadas

¿Quieres probar LiveSend?

Pega tu HTML y obtén un enlace permanente. Gratis para los primeros 3 documentos.

Empezar gratis