Can a Google Workspace admin set email signatures for all users?

Partly, natively. The Admin console's Append footer setting applies one plain-text block per organisational unit, capped at 10,000 characters, with no directory fields and no images. For branded signatures that pull each user's name, title and phone number, admins use the Gmail API, which writes the signature as a server-side property of the send-as address.

Why do my users end up with two signatures?

Because the Admin console append footer is added below whatever the user already set in Gmail. Google does not replace the user signature, it appends beneath it. If your staff have their own signatures and you enable an org-wide footer, every message carries both.

Can I set different signatures per department in Google Workspace?

Not natively beyond organisational units. The append footer is assigned one template per OU, so departments that are not modelled as separate OUs cannot receive different footers. Restructuring your OU tree to fit signature rules is generally a bad trade, because OUs govern policy inheritance for everything else too.

Do signatures set through the Gmail API reach phones?

Yes, in the normal case. The signature is stored server-side against the send-as address rather than as a per-device client setting, so it applies on web and in the Gmail mobile apps without anything being installed. The exception is a user who has set a device-level mobile signature in the Gmail app, which takes precedence on that device.

Google Workspace email signature management

Google Workspace has the weakest native signature controls of any major mail platform and the cleanest API for fixing them. Understanding which limits are real and which are worked around badly is most of the decision.

The short version: the Admin console gives you one plain-text footer per organisational unit, capped at 10,000 characters, with no directory fields, no images, and appended below anything the user already set — which is where double signatures come from. The Gmail API writes a real signature as a server-side property of each send-as address, which reaches web and mobile with nothing installed. That gap is why signature tools exist for a platform that appears to include the feature.

What the Admin console actually does

Google Workspace administrators have exactly one native mechanism: Append footer, found under Gmail's compliance settings. It is worth being clear about its shape, because the name suggests something more capable than it is.

Constraint	What it means in practice
One template per organisational unit	Sales and Support cannot have different footers unless they are separate OUs. Restructuring OUs to fit signatures means letting a cosmetic requirement drive the tree that governs every other policy you inherit.
Plain text only	No logo, no brand colours, no layout. A legal footer, not a signature.
10,000-character cap	Rarely binding on its own, but combined with multi-entity or multi-language disclaimers it becomes so faster than expected.
No directory fields	The footer is static text. It cannot say the sender's name, title, or direct line, which is the entire point of a signature.
Appended below the user's own signature	The double-signature problem, below.
Applied in transit	Users never see it while composing, and it is absent from their Sent Items copy.
Stripped on plain-text replies	Formatting and links do not survive, so the footer degrades exactly where threads get long.

The double-signature problem

This is the single most common Google Workspace signature complaint, and it is a design decision rather than a bug.

Google does not replace what a user has configured in their own Gmail settings. The append footer is added beneath it. So an organisation that has been running for a few years — where staff have made their own signatures, because nothing stopped them — turns on an org-wide footer and immediately every outbound message carries two signatures: the employee's improvised one, then the official one underneath.

There is no native setting that suppresses the user signature. Clearing them means visiting every account, and nothing stops a user setting a new one that afternoon. This is the point at which most administrators start looking for a tool, and it is worth understanding that they are not looking for branding — they are looking for a way to make the user-level signature stop mattering.

What the Gmail API does instead

Google's API story is markedly better than its Admin console story, and better than Microsoft's equivalent.

A Gmail signature is a server-side property of a send-as address, editable through users.settings.sendAs.update. Writing it takes one call per user. Because the value lives on the mail profile rather than in a client, it applies wherever that account sends from — the web client and the Gmail mobile apps — with no software installed, no add-in, no device management, and no change to mail routing.

This matters more than it sounds, because mobile is the perennial hole in signature deployments. On Microsoft 365, reaching phones means either an add-in with bounded mobile support or a relay in the mail path. On Google Workspace it is the same API call that handles everything else.

Two honest caveats:

Device-level mobile signatures still win. The Gmail mobile app has its own per-device signature setting. A user who has set one will see it take precedence on that device. Most have not, but "most" is not "all", and any vendor promising unconditional mobile coverage on Gmail is overstating it.
Users can edit it back. The API writes the same field the user can change in their own settings. Nothing prevents someone reverting to their preferred version ten minutes later. Client-side deployment is not enforcement.

The scope this requires

Signature management needs gmail.settings.basic, which Google classes as a sensitive scope. For an application distributed to other organisations, that triggers Google's OAuth app verification, and listing on the Google Workspace Marketplace can additionally require a third-party security assessment. This is a real gate with a real timeline, and it is the main reason the Google Workspace signature market is thinner than the size of the problem would predict.

For internal scripts inside a single tenant, domain-wide delegation avoids the verification path entirely. If you have a competent administrator and forty users, a script is a legitimate answer and we would rather say so than pretend otherwise.

How to check what is actually deployed

Before choosing a tool, it is worth knowing the size of the problem. Google gives you everything needed to measure it, and the answer is usually worse than expected.

1. Check whether an org-wide footer is switched on

In the Admin console: Apps → Google Workspace → Gmail → Compliance → Append footer. Check it at every organisational unit, not just the top — settings inherit, and an OU with its own override is easy to forget.

If a footer is enabled and your users have their own signatures, every message leaving your organisation currently carries both. That is the double-signature problem, and it is worth confirming before you attribute it to something else.

2. Read back what each user actually has

Signatures are readable through the same API that writes them. For each user, users.settings.sendAs.list returns every send-as address on the account along with its signature. The scope is gmail.settings.basic, and inside a single tenant, domain-wide delegation covers it without any app verification.

If you would rather not write code, GAM does this directly:

gam all users show sendas

3. Count the things that matter

Raw output is not an answer. Four counts turn it into one:

Empty signatures. Users sending with nothing at all. Usually higher than anyone guesses, and concentrated in recent joiners.
Stale image URLs. Grep the HTML for the previous logo’s filename or host. This is the cleanest single measure of how a rebrand actually landed.
Missing disclaimer text. Match on a distinctive phrase from your required wording. If you have a statutory requirement, this count is the compliance exposure.
Job titles that disagree with the directory. Compare each signature against the Admin SDK record for the same user. Promotions are the most common source of drift, because nobody thinks of the signature as part of the change.

Two blind spots to know about

Aliases carry their own signatures. sendAs.list returns every send-as address, not just the primary. A user with a role alias — support@, billing@ — has a separate signature on it that a naive audit reading only the first entry will miss entirely.

Device-level mobile signatures are invisible. The Gmail mobile app’s own signature setting is stored on the device, not on the mail profile, so no API can read it. If a user has set one, you cannot see it and you cannot count it. Any audit — ours included — is measuring the server-side signature, and it is worth saying so rather than implying total coverage.

The thing nobody measures

Every signature tool on the market — for Google Workspace and otherwise — enforces at the moment of creation. A template is defined, signatures are written, the job is considered done.

None of them answer the question administrators actually ask six months later: who is off-brand right now?

The same API that writes a signature can read it back. That makes the gap between the template and reality measurable — how many employees are running the previous logo, how many have no legal disclaimer, how many list a job title they were promoted out of last year. On a platform where users can edit their own signature back, that read path is not a nice extra; it is the only way to know whether deployment held.

This is what Ascripto is built around, and it is why our free tier is the audit rather than a template editor. Seeing that 31 of 47 employees are off-brand is a more useful starting point than a blank template.

Choosing an approach

If you need…	Use
A legal disclaimer on all outbound mail, nothing more	Admin console append footer. It is free and adequate for exactly this.
Branded signatures with per-user details, one tenant, technical staff available	Gmail API via domain-wide delegation. A script and a template.
Per-department rules, joiner/leaver automation, and to know when it drifts	A managed tool. This is where scripts stop scaling, usually at the point someone leaves and nobody remembers to run it.
Guaranteed enforcement that a user cannot revert	Outbound SMTP relay. Heavier, and a dependency in your mail path — worth it only when enforcement is genuinely the requirement.

If you also run Microsoft 365

Mixed estates are common and the two platforms are not comparable here. Microsoft's programmatic route, Exchange Web Services, is being disabled in phases between October 2026 and April 2027, and Microsoft Graph has never supported signature management. If part of your organisation is on Exchange Online, that timeline is worth reading before you choose a tool for either side.