¿Puede un administrador de Google Workspace configurar las firmas de correo electrónico de todos los usuarios?

De forma nativa, solo en parte. La opción Append footer de la Consola de administración aplica un pie de página por unidad organizativa, con un límite de 10.000 caracteres, sin campos del directorio y sin HTML (las imágenes, solo mediante una URL pública). Para firmas con imagen de marca que tomen el nombre, el cargo y el número de teléfono de cada usuario, los administradores usan la API de Gmail, que guarda la firma en el servidor como una propiedad del alias de envío.

¿Por qué mis usuarios acaban con dos firmas?

Porque el pie de página que añade la Consola de administración se coloca debajo de lo que el usuario ya haya configurado en Gmail. Google no sustituye la firma del usuario, sino que añade el pie debajo. Si tu personal tiene sus propias firmas y activas un pie de página para toda la organización, cada mensaje lleva las dos.

¿Puedo configurar firmas distintas por departamento en Google Workspace?

De forma nativa, no más allá de las unidades organizativas. Append footer asigna una plantilla por UO, así que los departamentos que no estén modelados como UO separadas no pueden recibir pies de página distintos. Reestructurar el árbol de UO para encajar las reglas de firma suele ser un mal negocio, porque las UO también rigen la herencia de políticas de todo lo demás.

¿Llegan a los teléfonos las firmas configuradas con la API de Gmail?

Sí, en el caso normal. La firma se guarda en el servidor, asociada al alias de envío, y no como una opción del cliente en cada dispositivo, así que se aplica en la web y en las aplicaciones móviles de Gmail sin instalar nada. La excepción es un usuario que haya configurado una firma para móviles en la aplicación de Gmail de su dispositivo: en ese dispositivo, esa firma tiene prioridad.

Gestión de firmas de correo electrónico en Google Workspace

Google Workspace tiene los controles nativos de firmas más débiles de todas las grandes plataformas de correo y la API más limpia para corregirlos. Entender qué límites son reales y cuáles se sortean mal es la mayor parte de la decisión.

En resumen: la Consola de administración te da un pie de página por unidad organizativa, con un límite de 10.000 caracteres, sin campos del directorio, sin HTML (las imágenes, solo mediante una URL pública) y añadido debajo de lo que el usuario ya haya configurado, que es de donde sale la doble firma. La API de Gmail escribe una firma de verdad como propiedad, guardada en el servidor, de cada alias de envío, y esa firma llega a la web y a las aplicaciones móviles sin instalar nada. Esa diferencia es la razón de que existan herramientas de firmas para una plataforma que, en apariencia, ya incluye la función.

Qué hace realmente la Consola de administración

Los administradores de Google Workspace tienen exactamente un mecanismo nativo: Append footer, en la configuración de cumplimiento de Gmail. Conviene tener claro cómo es exactamente, porque el nombre sugiere algo más potente de lo que es.

Limitación	Qué significa en la práctica
Una plantilla por unidad organizativa	Ventas y Soporte no pueden tener pies de página distintos salvo que sean UO separadas. Reestructurar las UO para encajar las firmas significa dejar que un requisito estético dicte el árbol que rige todas las demás políticas que heredas.
Sin HTML	Texto con formato y una imagen mediante una URL pública, pero sin maquetación ni diseño de marca. Un pie de página legal, no una firma.
Límite de 10.000 caracteres	Rara vez limita por sí solo, pero combinado con avisos legales para varias entidades o en varios idiomas empieza a limitar antes de lo esperado.
Sin campos del directorio	El pie de página es texto estático. No puede mostrar el nombre, el cargo ni la línea directa de quien envía, que es precisamente para lo que sirve una firma.
Se añade debajo de la firma del propio usuario	El problema de la doble firma, más abajo.
Se aplica en tránsito	Los usuarios nunca lo ven mientras redactan, y no aparece en la copia de sus mensajes enviados.
Se recorta en las respuestas en texto sin formato	El formato y los enlaces no sobreviven, así que el pie de página se degrada justo donde los hilos se alargan.

El problema de la doble firma

Es la queja sobre firmas más habitual en Google Workspace, y es una decisión de diseño, no un error.

Google no sustituye lo que el usuario ha puesto en la configuración de su propio Gmail. El pie de página se añade debajo. Así, una organización que lleva unos años funcionando —en la que el personal se ha hecho sus propias firmas, porque nada se lo impedía— activa un pie de página para toda la organización y, de inmediato, cada mensaje saliente lleva dos firmas: la que improvisó cada persona y, debajo, la oficial.

No hay ninguna opción nativa que suprima la firma del usuario. Eliminarlas significa pasar por cada cuenta, y nada impide que un usuario configure una nueva esa misma tarde. Es en este punto cuando la mayoría de los administradores empiezan a buscar una herramienta, y conviene entender que no buscan imagen de marca: buscan una forma de que la firma del usuario deje de importar.

Qué hace la API de Gmail en su lugar

Lo que Google ofrece por API es claramente mejor que lo que ofrece en la Consola de administración, y mejor que el equivalente de Microsoft.

Una firma de Gmail es una propiedad, guardada en el servidor, de un alias de envío, y se edita con users.settings.sendAs.update. Escribirla requiere una llamada por usuario. Como el valor reside en el perfil de correo y no en un cliente, se aplica desde dondequiera que envíe esa cuenta —el cliente web y las aplicaciones móviles de Gmail— sin instalar software, sin complementos, sin gestión de dispositivos y sin cambios en el enrutamiento del correo.

Esto importa más de lo que parece, porque los dispositivos móviles son el eterno punto débil de las implementaciones de firmas. En Microsoft 365, llegar a los teléfonos exige o bien un complemento con compatibilidad móvil limitada, o bien un servicio de retransmisión (relay SMTP) en la ruta del correo. En Google Workspace es la misma llamada a la API que se encarga de todo lo demás.

Dos salvedades honestas:

Las firmas para móviles del propio dispositivo siguen ganando. La aplicación móvil de Gmail tiene su propia opción de firma por dispositivo. Si un usuario ha configurado una, verá que tiene prioridad en ese dispositivo. La mayoría no lo ha hecho, pero “la mayoría” no es “todos”, y cualquier proveedor que prometa cobertura móvil incondicional en Gmail está exagerando.
Los usuarios pueden volver a cambiarla. La API escribe el mismo campo que el usuario puede cambiar en su propia configuración. Nada impide que alguien vuelva a su versión preferida diez minutos después. Una implementación del lado del cliente no es una imposición.

El permiso de OAuth que requiere

La gestión de firmas necesita gmail.settings.basic, que Google clasifica como permiso sensible. Para una aplicación distribuida a otras organizaciones, eso activa la verificación de aplicaciones OAuth de Google, y publicarla en Google Workspace Marketplace puede exigir además una evaluación de seguridad de terceros. Es un filtro real con plazos reales, y es la principal razón de que el mercado de firmas para Google Workspace sea más escaso de lo que haría prever el tamaño del problema.

Para scripts internos dentro de un único inquilino, la delegación de todo el dominio evita por completo el proceso de verificación. Si tienes un administrador competente y cuarenta usuarios, un script es una respuesta legítima, y preferimos decirlo antes que fingir lo contrario.

Cómo comprobar qué está implementado realmente

Antes de elegir una herramienta, conviene conocer el tamaño del problema. Google te da todo lo necesario para medirlo, y la respuesta suele ser peor de lo esperado.

1. Comprueba si hay un pie de página activado para toda la organización

En la Consola de administración: Apps → Google Workspace → Gmail → Cumplimiento → Append footer. Compruébalo en cada unidad organizativa, no solo en la de nivel superior: la configuración se hereda, y es fácil olvidarse de una UO que anula la heredada.

Si hay un pie de página activado y tus usuarios tienen sus propias firmas, cada mensaje que sale de tu organización lleva ahora mismo las dos. Ese es el problema de la doble firma, y conviene confirmarlo antes de atribuirlo a otra cosa.

2. Lee lo que tiene realmente cada usuario

Las firmas se pueden leer con la misma API que las escribe. Para cada usuario, users.settings.sendAs.list devuelve todos los alias de envío de la cuenta junto con su firma. El permiso es gmail.settings.basic y, dentro de un único inquilino, la delegación de todo el dominio lo cubre sin ninguna verificación de la aplicación.

Si prefieres no escribir código, GAM lo hace directamente:

gam all users show sendas

3. Cuenta lo que importa

La salida en bruto no es una respuesta. Cuatro recuentos la convierten en una:

Firmas vacías. Usuarios que envían sin nada en absoluto. Suelen ser más de lo que nadie imagina y se concentran en las incorporaciones recientes.
URL de imágenes obsoletas. Busca con grep en el HTML el nombre de archivo o el host del logotipo anterior. Es el mejor indicador, por sí solo, de cómo ha calado realmente un cambio de imagen de marca.
Falta el texto del aviso legal. Busca una frase característica de la redacción obligatoria. Si tienes una obligación legal, este recuento es tu exposición en materia de cumplimiento.
Cargos que no coinciden con el directorio. Compara cada firma con el registro del Admin SDK del mismo usuario. Los ascensos son la causa más habitual de desviación, porque nadie piensa en la firma como parte del cambio.

Dos puntos ciegos que conviene conocer

Los alias llevan sus propias firmas. sendAs.list devuelve todos los alias de envío, no solo el de la dirección principal. Un usuario con un alias de función —support@, billing@— tiene en él una firma aparte, que una auditoría ingenua que solo lea la primera entrada pasará por alto por completo.

Las firmas para móviles del dispositivo son invisibles. La opción de firma de la propia aplicación móvil de Gmail se guarda en el dispositivo, no en el perfil de correo, así que ninguna API puede leerla. Si un usuario ha configurado una, no puedes verla ni contarla. Cualquier auditoría —la nuestra incluida— mide la firma guardada en el servidor, y conviene decirlo en lugar de dar a entender una cobertura total.

Lo que nadie mide

Todas las herramientas de firmas del mercado —para Google Workspace o para cualquier otra plataforma— imponen la firma en el momento de crearla. Se define una plantilla, se escriben las firmas y se da el trabajo por terminado.

Ninguna responde a la pregunta que los administradores se hacen de verdad seis meses después: ¿quién se sale de la marca ahora mismo?

La misma API que escribe una firma puede leerla. Eso hace medible la distancia entre la plantilla y la realidad: cuántas personas siguen usando el logotipo anterior, cuántas no tienen aviso legal, cuántas muestran un cargo que dejaron atrás al ascender el año pasado. En una plataforma en la que los usuarios pueden volver a cambiar su propia firma, esa vía de lectura no es un simple extra: es la única forma de saber si la implementación se ha mantenido.

Ascripto está construido en torno a esto, y por eso nuestro nivel gratuito es la auditoría y no un editor de plantillas. Ver que 31 de 47 personas se salen de la marca es un punto de partida más útil que una plantilla en blanco.

Cómo elegir un enfoque

Si necesitas…	Usa
Un aviso legal en todo el correo saliente, nada más	Append footer de la Consola de administración. Es gratuito y suficiente justo para esto.
Firmas con imagen de marca y datos de cada usuario, un solo inquilino, personal técnico disponible	API de Gmail mediante delegación de todo el dominio. Un script y una plantilla.
Reglas por departamento, automatización de incorporaciones y salidas, y saber cuándo se producen desviaciones	Una herramienta gestionada. Aquí es donde los scripts dejan de escalar, normalmente cuando alguien se va y nadie se acuerda de ejecutarlo.
Imposición garantizada que ningún usuario pueda revertir	Retransmisión SMTP de correo saliente. Más pesada, y una dependencia en la ruta de tu correo: solo vale la pena cuando la imposición es de verdad el requisito.

Si también usas Microsoft 365

Los entornos mixtos son habituales, y aquí las dos plataformas no son comparables. La vía programática de Microsoft, Exchange Web Services, se está desactivando por fases entre octubre de 2026 y abril de 2027, y Microsoft Graph nunca ha admitido la gestión de firmas. Si parte de tu organización está en Exchange Online, conviene leer ese calendario antes de elegir una herramienta para cualquiera de los dos lados.