Gmail signatures for aliases, groups and shared mailboxes

The short answer

Gmail does not attach a signature to a mailbox. It attaches one to each address a mailbox can send from, which Gmail calls a Send mail as address and the Gmail API calls a send-as alias. A person’s primary address is the first of these. Every other address they send from, whether an alias the admin created, a group they are allowed to post as, or an external address, is another entry with its own signature.

That one fact explains most of the confusion. The admin adds sales@ as an alias and nothing changes in anyone’s Gmail. Someone sends as support@ and the signature says their name and direct line. The group footer is set and the company signature still does not appear on replies from the collaborative inbox. Each of these is Gmail doing exactly what the model says. The rest of this article goes case by case.

The five kinds of address, and where the signature lives

Google Workspace gives a company five ways to put a second name on an email. They look the same to the recipient and behave differently inside Gmail.

Google puts the limits in its help pages: up to 30 aliases per user in the Admin console, up to 99 Send mail as addresses in Gmail, up to 10,000 characters per signature, and a 1,000-character text-only footer per group. Those numbers were read on 28 October 2026 and are linked in the sources below.

Aliases: the step the admin cannot see

An email alias is an extra address on one user. The admin adds it at Users → the user → Add Alternate Emails, and mail to it lands in that person’s inbox within a day, usually within minutes. Receiving is the easy half.

Sending from it is not automatic. Google’s Admin Help says it plainly: to send email from an alias, the user must set up a custom From address in Gmail, and that setting is not visible to the admin in the Admin console. The person opens Gmail Settings → Accounts and Import → Send mail as → Add another email address, enters the alias, and keeps Treat as an alias ticked so replies come back to the same inbox. An alias on the company’s own domain does not need the verification email that an outside address does.

Only once that entry exists can the alias have a signature. In the Signature settings, a drop-down above the signature box lists every Send mail as address; the person picks the alias and writes or chooses a signature for it, and picks a default for new emails and for replies. If the drop-down is missing, the alias has not been added under Send mail as yet. That is the whole fix for “I added the alias and there is no signature option”.

For a company this is a list problem. Thirty people with a regional alias each means thirty Send mail as entries that each need adding and each need a signature, and the admin cannot check any of them from the console. The ways around that are in the last two sections.

Groups: a footer is not a signature

support@ is usually a Google Group, often a collaborative inbox. The group receives mail, members read it, and some of them reply. Where the signature comes from depends on which address the reply leaves under.

If the group’s default sender is the author, the reply goes out from the member’s own address with the member’s own primary signature. If the group allows posting as the group and the member does so, the reply goes out under support@, and the signature is whatever that member has set for support@ in their own Send mail as list. Each member has their own entry and their own version. Five people answering support@ can have five different signatures under the same address, and one of them will have none.

The group itself has no signature setting. Google Groups offers an email footer, either the standard Groups footer with a link to the conversation and subscription settings, or a custom one of up to 1,000 characters of plain text. It is useful for a legal line or an unsubscribe note. It cannot carry a logo, a name or a phone number, and it is appended to messages the group distributes, which is not the same as the messages a member sends out from it.

Delegated and shared mailboxes

The other way to run info@ is to make it a real user, pay for the licence, and give people delegate access to it. A delegate opens the mailbox from their own Gmail, reads and sends from it. Google allows up to 1,000 delegates on a work account, with around 40 using it at the same time in typical use.

Signatures are simple here, because there is only one account. A message sent from the delegated mailbox carries that mailbox’s own signature, the one set in its Send mail as entry, whoever is typing. Google notes that the delegate’s address appears on the message, so the recipient can see who sent it, but the signature does not change per delegate. One account, one signature per address, set once.

The trade-off is that the signature cannot say who answered. If the team wants “Maya, Customer Support” on each reply, a delegated mailbox gives you “Customer Support” and nothing more. If that matters, the group route, with each member’s send-as signature for the group address, is the one that can carry a name.

Which to use for which address

Three questions decide it: does the address belong to one person or a team, should replies show who answered, and does anyone need to read the mailbox as a whole.

• One person, a second name (first.last@ and f.last@, a regional sales address, a brand domain). An alias. Add it in the Admin console, have the person add it under Send mail as, set the signature for it.
• A team, replies in each person’s name (support@, sales@ for a pod). A Google Group with posting as the group allowed, each member’s send-as entry carrying the company template filled with their own name, and a short group footer for the legal line.
• A team, replies in the company’s name (info@, press@, accounts@). A delegated mailbox with one signature, set once, no personal fields.
• An address someone sends from outside the domain (a contractor’s own address, a legacy domain not yet moved in). An external Send mail as entry. The user owns it and its signature; the admin has no reach into it.

Pick per address, not per company. A support team and a press inbox usually want different answers.

Setting all of them without a spreadsheet

For a handful of aliases, the steps above are the job. Past about twenty, the problem is that every send-as entry is a separate setting on a separate account that the admin cannot see, and three tools reach them.

The Gmail API and GAM

The Gmail API exposes each account’s send-as entries at users.settings.sendAs. Each entry has a signature field; the primary address is the entry with isPrimary set, and every alias is another entry with a verificationStatus of accepted or pending. With domain-wide delegation, an admin can list every entry on every account, create the send-as entry for an alias the user has not added, and write a signature into each one. GAM wraps the same calls. We walk through the GAM route in the guide to setting a signature for all users; the alias case is the same command with the alias address in place of the primary.

Two limits. A Google Group is not an account, so the API cannot set anything on support@ itself; it can only set the support@ send-as entry on each member’s account, member by member. And a script is a snapshot: a new alias added next month, or a member added to the group, has no signature until someone runs it again.

A signature tool

A tool like Signifier does the same writes continuously. It reads the directory, fills one template per team, and writes the signature into each person’s primary send-as entry and into each of their aliases, so sales@ carries the same template as first.last@ with the same name and title. When the directory or the template changes, it rewrites; when a person gains an alias, it follows. Its people list shows each address with the signature that was written and whether Gmail still has it, which is the view the Admin console does not give.

A checklist for the admin

1. List every address that is not a person. For each, decide: alias, group or delegated mailbox, using the three questions above.
2. For each alias, confirm the user has added it under Send mail as and set a signature for it. Through the API or GAM, list the send-as entries on each account rather than asking.
3. For each group members post as, write the company template into each member’s send-as entry for the group address, and set the group footer for the legal line.
4. For each delegated mailbox, set one signature with no personal fields and check it in the mailbox itself, not from a delegate’s view.
5. Re-check when aliases are added, when group membership changes and after each new-starter batch. A new send-as entry starts empty.