Firma de email

Los clientes de correo, en especial Outlook en Windows (que renderiza con el motor de Word), ignoran o distorsionan CSS moderno como display:flex, grid, float y position. La tabla es el único mecanismo de layout con soporte universal: usa <table cellpadding="0" cellspacing="0" border="0"> con border-collapse:collapse y controla columnas con <td> y vertical-align:top. Un layout en flexbox se ve perfecto en el navegador y colapsa en una sola columna apilada al llegar a Outlook.

La mayoría de gestores de firma (Outlook, Gmail, Apple Mail, herramientas corporativas) eliminan los bloques <style> y las hojas externas al pegar o procesar la firma. Solo los estilos inline sobreviven al copiado y al saneamiento del cliente. Cada propiedad visual (tipografía, color, margenes) debe declararse en el atributo style del elemento; una clase CSS que apunta a un bloque <style> deja la firma sin formato en cuanto sale del editor.

Las fuentes web (Google Fonts, Typekit, corporativas vía @font-face) no cargan en la mayoría de clientes de correo, que caen a la fuente del sistema y rompen la tipografía planeada. Declara siempre una pila web-safe de amplio soporte: Arial, Helvetica, Verdana, Georgia o Times New Roman, con el genérico (sans-serif/serif) al final. La firma se verá consistente en Outlook, Gmail y Apple Mail solo si la primera fuente de la pila ya existe en todos los sistemas.

El ancho recomendado de firma en desktop es 600 px (puede bajar a 450 px para mayor compatibilidad). En mobile las pantallas van de 320 a 500 px, así que diseñar para 320 px garantiza que nada se corte en el dispositivo más pequeño. Los layouts de dos columnas se rompen en mobile: prefiere columna única para los datos de contacto, con el logo arriba y el texto debajo, de modo que la firma fluya sin scroll horizontal.

Una firma armada como un solo archivo de imagen parece practica pero falla en dos frentes criticos: los clientes bloquean imagenes por defecto pidiendo confirmación manual, y el texto en píxeles no es seleccionable, copiable ni accesible para lectores de pantalla. Construye la firma en HTML con texto en vivo y reserva la imagen solo para el logo, optimizado bajo 50 KB en total (PNG con alfa comprimido). Si el destinatario tiene imagenes desactivadas, una firma de texto en vivo sigue siendo completamente legible.

Cuando las imagenes se bloquean (algo habitual en varios clientes), el alt es la única información visible: para el logo usa el nombre de la empresa, para iconos de red el nombre de la red ("LinkedIn", "X"). El texto debe cumplir contraste WCAG AA: ratio mínimo 4.5:1 para texto normal y 3:1 para texto grande (18 pt, o 14 pt bold). Un gris claro tipo #aaaaaa sobre blanco no llega a 4.5:1 y vuelve ilegible el cargo o el telefono.

Apple Mail, Outlook desktop y Gmail mobile invierten o ajustan colores en dark mode. Un logo con fondo blanco sólido aparece como un parche brillante sobre fondo oscuro, y fijar background-color:#ffffff en la tabla raiz choca con las inversiones automáticas del cliente. La estrategia segura: logo PNG con fondo transparente, texto en gris oscuro (no negro puro #000000, que el cliente puede no invertir) y sin background fijo en el contenedor principal.

Incluir 8-10 iconos de redes debilita el CTA y satura la firma: selecciona solo las redes con presencia activa y relevante para el receptor (3-4 máximo). El tamaño estandar de icono es 22x22 px, uniforme en estilo y paleta. En mobile el área tactil efectiva debe ser de al menos 32-40 px, lograda con padding en el enlace contenedor (<a style="padding:8px">), de modo que el toque no falle aunque el icono sea pequeño.

Los disclaimers no son obligatorios universalmente: su necesidad varia por industria (healthcare bajo HIPAA §164.530, finanzas bajo FINRA, empresas UK bajo Companies Act 2006 §82) y jurisdicción. Un disclaimer genérico en todos los correos, incluidos replies internos, anade ruido sin valor legal real. Cuando si aplica: 10-11 px, color de menor contraste que el bloque principal, separado por un <hr> o espacio generoso, y omitido en replies si ya aparecio en el mensaje inicial.

El receptor necesita identificar a la persona antes que a la empresa, y poder contactarla directamente antes de seguirla en redes. La jerarquía recomendada: nombre completo en negrita y mayor tamaño, cargo, empresa con logo, telefono directo y email, web, iconos de redes y disclaimer si aplica. El telefono debe usar el esquema tel: para ser tocable en mobile y el email mailto:. Invertir el orden (logo gigante primero, nombre diminuto al final) obliga a buscar el dato más importante.

En un hilo largo la firma completa se repite en cada mensaje, acumulando logos, banners y disclaimers. La buena practica es configurar una firma alternativa para replies/forwards que incluya solo nombre, cargo y telefono directo en una línea. Gmail permite firmas diferenciadas por tipo (nuevo correo vs respuesta) en Configuración > Firmas, y los disclaimers que ya aparecieron en el mensaje inicial no necesitan repetirse en cada respuesta.

Sin control central las inconsistencias proliferan: logos viejos, telefonos erroneos, colores fuera de marca, fuentes distintas. La solución es una plantilla que genere la firma HTML a partir de los datos del directorio (nombre, cargo, departamento) y la empuje automáticamente; herramientas como Exclaimer (70,000+ organizaciones) o WiseStamp lo hacen. Para equipos sin presupuesto: una plantilla HTML documentada con variables reemplazables, de modo que un cambio de logo se propague en un solo lugar en vez de pedir a cada persona que edite la suya.

El banner de firma sirve para promocionar eventos o lanzamientos, pero solo con un mensaje único. Banners de más de 650 px de ancho o 100 px de alto se ven como spam visual; el rango sano es 300-650 px de ancho por 90-150 px de alto y peso bajo 40 KB. El enlace debe llevar parámetros UTM para medir clicks, y el banner se omite en firmas de reply (solo en correos nuevos). Tres CTAs distintos en el mismo banner diluyen el único click que ibas a conseguir.

En 2026 los reguladores europeos (CNIL en Francia, Garante en Italia) emitieron guías que aplican el Reglamento ePrivacy y el GDPR a los tracking pixels en correo: usar un píxel exige informar al destinatario de antemano, incluso en firmas corporativas que monitorizan comunicaciones internas. Para correos transaccionales y replies, elimina cualquier píxel; para campanas outbound medibles, usa parámetros UTM en los enlaces en vez de un píxel oculto de 1x1. Asumir que el consentimiento de marketing cubre el tracking no es valido.

Un enlace "Guardar contacto" que apunta a un archivo .vcf alojado en el servidor permite agregar los datos al directorio del dispositivo con un toque, sin copiar a mano. El enlace debe ser texto descriptivo claro o un icono etiquetado, nunca una imagen sin alt ni un "click aquí" ambiguo. No adjuntes el .vcf directo al correo: los filtros de seguridad lo bloquean. Es compatible con Outlook, Gmail, Apple Mail y la mayoría de clientes modernos.