A domain signature is one email footer, set once on a domain, that every mailbox on it inherits. The alternative is asking fifty people to maintain the same string by hand — and if you ask ten of them to paste it into their mail settings you'll get eleven versions of it. Two will have last year's job title. One will have the office phone number from before the move. Three will have pasted it as an image. One will have dropped the legal disclaimer because it looked too long, and one will have put the whole thing above their reply so every message in the thread ends with four stacked copies.
This isn't a discipline problem. It's a design problem, and shared strings maintained by hand always drift.
A domain signature moves it to one place instead. Everyone on that domain inherits it, including the mailbox someone creates next March.
Why Per-User Signatures Drift
Four failure modes account for nearly all of it.
Nobody updates on change. The company rebrands, moves office, or changes its registration number. An email goes out asking everyone to update their signature. About a third do. Two years later you've signatures citing an address you haven't occupied since.
New starters copy from whoever sits nearest. They ask a colleague to send them theirs, and inherit whatever that person's version happened to be — including its mistakes, which then propagate.
Images break. A signature built as one big image is unreadable when images are blocked, which is the default in most corporate clients, and is invisible to screen readers. What the recipient sees is an empty rectangle where your contact details should be.
Position is inconsistent. Some clients put the signature above the quoted text, some below. In a long thread this is the difference between one signature at the bottom and eleven signatures interleaved through the history.
A domain-level signature removes the first two entirely and lets you decide the fourth centrally.
Three Domain Signature Modes: Off, Default, Enforced
The Signature tab on a domain has three settings, and picking the right one is most of the decision.
| Mode | Behaviour | Use when |
|---|---|---|
| Off | No domain signature at all. Everyone manages their own. | Small teams, or a domain where signatures genuinely differ by person |
| Default | New sending identities are pre-filled with the domain signature, and users can then edit or replace it. | You want consistency for new starters without taking control away from people who have a reason to differ |
| Enforced | The domain signature is used on every identity on the domain, overriding personal ones. | Regulated industries, mandated disclaimers, or any case where "most people have it" isn't good enough |
The distinction between Default and Enforced is worth dwelling on, because it's a policy choice, not a technical one.
Default is a starting point. Change the domain signature later and existing identities keep what they have — you've seeded them, not bound them. Good when the domain signature is a convenience rather than a requirement.
Enforced is a guarantee. Every message from every mailbox on the domain carries it, and there's no per-user opt-out. Change it and the change is live for everyone at once, with no rollout campaign. This is the mode you want if a compliance officer will ever ask "can you prove every outbound message carries the disclaimer?", because in Default mode the honest answer is no.
A domain signature is set per domain, so a company running acme.com and acme-labs.com can enforce different footers on each — which is usually what you want, since the two entities frequently have different legal wording.
Where the Domain Signature Goes
The second setting is where the domain signature goes relative to quoted text, and it produces visibly different mail.
Before the reply puts the signature directly under what you just wrote, above the quoted history. The recipient reads your message and your details together, without scrolling. The cost is that a long thread accumulates one signature per message.
After the reply puts it at the very bottom, below everything. Exactly one signature per message, always in the same place. The cost is that on a long thread the recipient may never scroll far enough to see it.
The rule of thumb: before for a contact-details domain signature, where being seen is the point; after for a legal disclaimer, where being present is the point and nobody was going to read it anyway.
What It Covers and What It Doesn't
Being precise here matters more than making the feature sound bigger than it is.
The domain signature applies to sending identities — the addresses in the webmail composer's From menu, and the identities exposed over the API. Anyone composing in webmail on that domain gets it, on every device, with no local setup. New mailboxes get it from their first message.
It does not reach into a desktop mail client. If someone composes in Outlook or Apple Mail, that application builds the message and uses whatever signature is configured inside it. The message isn't rewritten in transit to add a footer.
That's a deliberate boundary. Injecting a footer at the mail-transfer layer means modifying the message body after it has been signed, which breaks the DKIM signature and hands you a deliverability problem far more expensive than an inconsistent footer. Systems that do body injection have to re-sign afterwards, and the failure mode when that goes wrong is mail landing in spam — see why DKIM fails for what that looks like from the receiving end.
Practically: if enforcement matters to you, standardise on webmail for the mailboxes that must carry the disclaimer. If a team must use a desktop client, their signature has to be configured there, and the domain setting is a source of truth to copy from rather than a mechanism that reaches them.
Legal Disclaimers, Honestly
Most email disclaimers have little legal force. "If you received this in error, please delete it" doesn't create an obligation on someone who never agreed to anything, and courts have been unimpressed by that argument for a long time.
What they are good for is narrower and real:
- Statutory disclosure. Several jurisdictions require company registration details in business correspondence — the UK's rules on company stationery and Germany's requirements for electronic business letters both apply to email. This isn't optional and it's exactly the thing enforcement mode exists for.
- Regulated communication. Financial services, healthcare, and legal practices frequently have supervisory requirements on outbound correspondence.
- Confidentiality notices. Weak on their own, but part of demonstrating that an organisation takes reasonable steps — which can matter in a dispute even where the notice itself isn't binding.
If yours is a paragraph of boilerplate nobody required, consider deleting it. If it's a statutory disclosure, put it in enforced mode and stop thinking about it.
Designing a Signature That Survives
Email clients render HTML inconsistently, and a signature is HTML that ends up quoted inside other people's messages, forwarded, printed, and read on a 5-inch screen. Constraints follow.
Keep it short. Name, role, company, one phone number, one link. Every additional line is repeated on every message in every thread forever.
Never make it an image. Blocked images mean an empty box, screen readers get nothing, and the text is unsearchable. Use real text; if you want a logo, use one small image alongside the text, with sensible alternative text.
Avoid social icon rows. Six small images that are usually blocked, contributing six broken-image placeholders under your name.
Don't use a table for layout unless you must. Some clients mangle nested tables inside quoted replies, and a signature that looks fine in the composer can arrive with a column collapsed.
Test in a reply, not in the composer. The composer is the one context where it always looks right. Send yourself a message, reply twice, then look at it — that's what recipients see.
Don't put confidential detail in it. Direct mobile numbers end up in every mailing list, forwarded thread, and archive your messages have ever touched.
Rolling It Out
- Write the signature and get whoever owns brand and legal wording to sign off on the exact text before it goes anywhere.
- Set the domain to Default mode first and check it on one mailbox — compose, reply, forward, and read the result on a phone.
- Decide position: before the reply for contact details, after for a legal footer.
- Switch to Enforced only if you need the guarantee. It overrides personal signatures, so tell people before you do it rather than after.
- Repeat per domain. Signatures don't inherit across domains, and usually shouldn't.
- Note anyone using a desktop client — they need it configured locally, and the domain setting is the text to copy.
Frequently Asked Questions
Does a domain signature replace what people already set up?
Only in Enforced mode. In Default mode existing identities keep their own signature and only newly created ones are seeded from the domain.
Can different departments have a different domain signature?
Not within one domain — the setting is per domain. If you run separate domains per brand or entity, each gets its own. Within a single domain, use Default mode so teams can adjust their own.
Will it appear on mail sent from Outlook or Apple Mail?
No. The domain signature applies to sending identities in webmail and over the API. A desktop client composes the message itself and uses its own configured signature. We don't rewrite message bodies in transit, because that breaks DKIM signatures.
Can I include a logo?
Yes, as one small hosted image with alternative text, next to real text. Don't build the whole signature as an image — blocked images are common and the result is an empty rectangle.
Does it apply to aliases?
Yes. Sending identities on the domain include aliases that have sending enabled, so mail from sales@ carries the same footer as mail from a personal address on that domain.
What happens when I change the domain signature later?
In Enforced mode the change is immediate for everyone on the domain. In Default mode it applies only to identities created after the change; existing ones keep what they have.
