# Mailbox signatures

A signature is a field on the mailbox row, not a workspace-wide setting, so each connected address signs off in its own name. It is applied to messages sent from that mailbox, whoever composed them — Connect or a person — because both go through the same send boundary. Changing it affects what leaves next, not what has already gone.

- **Status:** Available
- **Audience:** both
- **Channels:** email
- **In the app:** #/mailboxes
- **Last verified:** 2026-09-10
- **Canonical:** https://connectbyjbrh.com/docs/email/mailbox-signature/

## One signature per address

`signature` sits beside `role`, `autonomy` and the health verdicts on the mailbox row. That placement is the design: a workspace running a sales address and a support address is usually a workspace that wants two different sign-offs, and forcing one on both would make the mailbox distinction cosmetic.

It is also why there is nothing to reconcile when you add a mailbox. The new row carries its own signature or none; no other mailbox changes, and no workspace-level template has to be edited to accommodate it.

Both audiences edit it the same way, on the same screen, through the same `mailbox_console` policy. There is no operator-only signature control and no customer-only one.

## When it is applied

| Message | Signed | Why |
|---|---|---|
| A reply Connect drafted and sent autonomously | Yes, from the thread's mailbox | Sending is one boundary; the mailbox is settled by the thread |
| A reply you approved from Needs You | Yes, from the same mailbox | Approval releases the message through that same boundary — the mailbox is not editable at approval |
| A message you wrote by hand | Yes | A person's send and the engine's send are the same code path |
| A draft sitting in Needs You | As it will be sent | What you approve is what goes; editing the body does not detach the signature |
| A message from a different mailbox | That mailbox's own | Signatures do not inherit between rows |

> **Note** Because sending is one boundary rather than two, there is no state where Connect's mail is signed and yours is not. If a signature is wrong, it is wrong for everything leaving that address, which makes it easy to notice and easy to fix in one place.

## Editing, and what does not change

1. Open `#/mailboxes` and edit the signature on the row for that address.
   - Result: The change applies to what is sent afterwards. Messages already acknowledged by the provider are gone and are not rewritten.
2. Send one message and read it as the recipient would.
   - Result: That is the only check worth trusting. A signature is presentation, and presentation is verified by looking rather than by reading a setting back.
3. Repeat for each connected address you care about.
   - Result: Nothing propagates between mailboxes, deliberately — a workspace with four addresses has four signatures to set.

A signature is not memory and not knowledge. It is not consulted when a reply is written, it does not shape tone, and it cannot be used to smuggle a standing instruction to the model. If you want Connect to *behave* differently on one address — sign differently in the sense of writing differently — that belongs in [Memory](/docs/memory/) at the endpoint tier, which resolves per mailbox exactly as autonomy does.

## Footers, and what this page will not claim

What is appended to a message from a Connect mailbox is that mailbox's own `signature`. This documentation does not record any platform-added footer applied to a customer workspace's mail, and inventing one would be worse than useless — you would design around something that may not exist. If your workspace shows a footer you did not write, the mailbox row is the first place to look and your provider's own settings the second.

Compliance text is a related but separate matter. Unsubscribe handling, suppression, complaints and do-not-contact are checked in one place before any outreach, and outreach email and a reply to a customer are two paths with different gates that are never merged. What a given jurisdiction requires in the body of an outreach message is a decision for the workspace that sends it; [Outreach email versus a customer reply](/docs/email/outreach-email/) and [Unsubscribe](/docs/email/unsubscribe/) cover the machinery around it.

## Questions

### Can I use a different signature for one customer?

Not as a signature — the field lives on the mailbox and resolves per address. The narrower thing you probably want is memory at the contact tier, which does change how a reply is written for one person.

### Does an edited draft lose its signature?

No. What you approve is what is sent, and the signature belongs to the send rather than to the draft text you edited. If you paste a second sign-off into the body you will get two, which is the usual cause of a duplicate.

### Is HTML allowed in a signature?

What is rendered on the way in is sanitised aggressively by `mail_render.py`, and [Rendering HTML email safely](/docs/email/html-email/) explains that side. For what you compose, keep it simple: a signature that depends on remote images will behave unpredictably in recipients' clients, which is not something Connect can control.

## Related

- [Mailboxes](https://connectbyjbrh.com/docs/email/mailboxes/)
- [Mailbox roles](https://connectbyjbrh.com/docs/email/mailbox-roles/)
- [Sending email](https://connectbyjbrh.com/docs/email/sending/)
- [Outreach email versus a customer reply](https://connectbyjbrh.com/docs/email/outreach-email/)
- [Memory in Connect](https://connectbyjbrh.com/docs/memory/)

## What this page is based on

- Connect source pack — channels, §1: mailboxes carry a role, a signature and their own autonomy; one send boundary
- Connect source pack — memory tiers and the endpoint scope (`docs-source/sources/GENERAL.md` §5–6)
- Connect capability registry (`docs-source/facts.py`) — `mailbox_roles`, `html_mail_render`