Email Signature Policy: Free Template, Rules and How to Enforce It (2026)

TL;DR: An email signature policy says what every company signature must contain, what it must never contain, who approves changes, and how the rules are enforced. Write it as a short document with four parts: required fields, legal and regulatory text, brand rules, and banned items. Then make the policy enforceable rather than advisory: one centrally managed template per audience, fields filled from the directory, manual edits overwritten, a server-side fallback for devices the template can't reach, and a monthly audit of install status and missing data. A copy-ready template is below.

Last reviewed: October 2026.

This is general information, not legal advice. Disclosure requirements depend on your entity type, sector and jurisdiction; confirm the legal parts of your policy with counsel. The legal rules referred to here are set out, with their sources, in the Handbook's email disclaimers guide.

Most companies already have signature guidelines: a PDF from the brand team, a page on the intranet, or a paragraph in the onboarding pack. What most don't have is a policy that anyone checks. Six months after a rebrand, a company with a few hundred employees typically has old logos, personal quotes, missing registration details and three versions of the phone number in circulation. This guide gives you a policy template written for IT, marketing and legal to sign off together, a split of responsibilities, and the technical controls that turn the policy from a request into a default.

What should an email signature policy cover?

Keep the policy to what can be checked. Every rule should be either filled in automatically, enforced by the tool, or verifiable in an audit. A useful policy covers five areas.

1. Required fields

• Identity: full name as recorded in the directory, job title, department or team where it helps the recipient.
• Contact: one work phone number (direct line or switchboard), and the company website. Mobile numbers only where the role needs them and the employee agrees; see GDPR and email signatures for why.
• Company: legal entity name and logo. In groups with several entities, the entity is the one that employs the sender.
• Source of truth: each field names the system it comes from (Entra ID, Google Workspace Directory or your HRIS) so that a wrong title is fixed in the directory, not in the signature. See Entra ID attributes for signatures and HRIS-driven signatures.

2. Legal and regulatory text

Separate what the law requires from what you choose to add. Mandatory items are things like UK company registration details, German Pflichtangaben or a regulator's required statement; voluntary items are confidentiality, privilege and "no contract" notices. The policy should list, per entity, the exact approved wording, the rule it relies on, and the date it was approved. Sector rules (financial promotions, attorney advertising, healthcare notices) belong here too: see the guides on financial services, law firms and healthcare.

3. Brand and format rules

• One approved layout per audience (for example: standard external, internal, reply, shared mailbox, executive).
• Text in live HTML, not a single image. Images are blocked by default in many clients and are invisible to screen readers unless they carry alternative text, which WCAG treats as the baseline for non-text content (WCAG 2.2, success criterion 1.1.1).
• Approved fonts and colors only, a logo hosted at a stable URL, and image dimensions kept small; see email signature image size.
• Gmail limits signatures to 10,000 characters, so the design has to fit within it; see Gmail signature too long.

4. Banned items

• Personal quotes, slogans, religious or political statements.
• Personal social media accounts unless the employee's role includes representing the company there.
• Unapproved banners, badges, awards or rankings. In regulated sectors these can turn an ordinary email into a regulated communication, so marketing content in signatures goes through the same review as other promotions.
• Link shorteners and unbranded redirect domains, which look like phishing to recipients and filters.
• Patient, client or customer information of any kind.
• Animated content that flashes more than three times per second (WCAG 2.2, 2.3.1).

5. Tracking and marketing rules

If your signature tool measures views or clicks, the policy says so, states who decided it was lawful for which recipients, and names the owner of the setting. Banner campaigns need a start date, an end date and an approver. Banners that promote products can make a one-to-one email commercial, which brings rules such as CAN-SPAM into play (FTC: CAN-SPAM compliance guide). See banner campaigns.

Email signature policy template

Copy this and replace the bracketed items. Section 4 should be approved by legal or compliance before you publish it.

EMAIL SIGNATURE POLICY
Owner: [IT / Marketing]  Approvers: [Legal], [Brand], [IT Security]
Version: [1.0]  Effective: [date]  Next review: [date + 12 months]

1. PURPOSE AND SCOPE
1.1 This policy sets the content and format of email signatures for all
    employees, contractors and shared mailboxes sending from [company domains].
1.2 It applies to email sent from any device or application, including
    mobile apps and CRM or sales tools that send through company mailboxes.

2. HOW SIGNATURES ARE MANAGED
2.1 Signatures are created and deployed centrally by [team] using [tool].
    Employees do not create or edit their own signatures.
2.2 Signature data comes from [Entra ID / Google Workspace / HRIS].
    To correct a name, title, phone number or office, raise a request with
    [HR / IT]; the signature updates automatically.
2.3 Manual changes to a signature in an email client are overwritten.

3. REQUIRED CONTENT (EXTERNAL EMAIL)
3.1 Full name, job title, [department], work phone, company website.
3.2 Company logo from the approved asset library.
3.3 The legal block for the sender's employing entity (section 4).

4. LEGAL AND REGULATORY TEXT
4.1 Approved text per entity is held in [location] with its legal basis
    and approval date. Only [Legal / Compliance] may change it.
4.2 Role-specific disclosures (for example licence or registration numbers)
    are added from directory fields and omitted when the field is empty.
4.3 Internal email may use a shorter internal signature without the legal block.

5. FORMAT
5.1 Approved templates only: [list templates].
5.2 Text in live HTML; images carry alternative text.
5.3 Fonts: [list]. Colors: [list]. Maximum logo size: [width x height].

6. NOT PERMITTED
6.1 Personal quotes, slogans, political or religious statements.
6.2 Personal social media links unless approved for the role.
6.3 Banners, awards, rankings or badges not approved under section 7.
6.4 Link shorteners or unapproved redirect domains.
6.5 Any client, patient or customer information.

7. BANNERS AND CAMPAIGNS
7.1 Signature banners are scheduled by [Marketing] with a start and end date.
7.2 Banners promoting products or services are reviewed by [Compliance]
    before publication where sector rules apply.

8. TRACKING
8.1 Signature view and click tracking is [enabled / disabled] for
    [regions / audiences], as assessed by [DPO / Privacy lead] on [date].

9. COMPLIANCE AND AUDIT
9.1 [IT] reviews install status, missing directory data and template
    versions [monthly] and reports exceptions to [owner].
9.2 Changes to templates and legal text are logged with date and approver.

10. EXCEPTIONS
10.1 Exceptions require written approval from [owner] and are reviewed
     at each policy review.

Who owns what: IT, Marketing, Legal and HR

Signature projects stall when nobody knows who decides. Agree the split before rollout:

Area	Owns	Approves	Is informed
Mail routing, add-in or relay, directory connection, security review	IT	IT Security	Marketing
Template design, banners, campaign calendar	Marketing	Brand lead	IT
Legal block, regulatory disclosures, tracking decision	Legal or Compliance (DPO for tracking)	General Counsel	Marketing, IT
Names, titles, departments, offices in the directory	HR (via HRIS) or IT (via directory)	HR	Marketing
Exceptions to the policy	Policy owner	Policy owner plus Legal	IT

In Scribe's own description of a typical setup for companies above about 50 employees, IT connects the email provider and configures the sending domain once, and Marketing then designs, assigns and deploys signatures without further IT involvement; Security and Legal may review data handling, SSO and compliance (Scribe: which departments are involved).

Map those responsibilities to tool permissions. Scribe documents three workspace roles: Owner (full control, one per workspace), Admin (settings and invitations) and Member (can edit and install only their own signature, with no access to templates, campaigns or settings) (Scribe: Members). In practice that means giving Admin to the few people who publish templates, and Member to everyone else who logs in. Scribe's plans page also lists "role permissions" on paid plans and an audit log as a paid add-on (Scribe: Plans); if you need, for example, Legal to edit only the disclaimer block, confirm with Scribe what the role model supports, because field-level permissions and approval workflows aren't described in the public documentation.

How do you enforce an email signature policy technically?

A policy that depends on each employee copying a template will drift. Four controls do most of the work.

Central templates and directory data

Each audience gets one template, assigned by rule rather than by hand. In Scribe, a signature can be assigned to individual teammates, groups, administrative units or a Smart Field condition (for example "department is any of Sales, Sales & Marketing"), with an option to auto-assign it to all future teammates synced from the identity provider (Scribe: assign teammates). When a teammate belongs to several signatures, priority decides which one installs (Scribe: signature priority). Fields are filled from the directory or HRIS, and a block whose field is empty is left out rather than printed with a blank label (Scribe: Smart Fields).

Overwrite manual edits

Native signature settings in Outlook and Gmail can be edited by users. A client-side signature manager can put the approved version back. Scribe documents that its add-in injects the approved signature every time a teammate opens the compose window in Gmail or Outlook, so a local edit lasts only until the next email (Scribe: manual edits). Scribe's plans page also describes "Scribe radar", which monitors team signatures daily and updates those that don't match (Scribe: Plans).

Server-side fallback for devices you can't reach

Client-side injection depends on the app. Gmail for Android and Apple Mail don't let a signature tool set the compose signature, so mail from those apps can leave without the approved block (Scribe: mobile). If your policy treats the legal block as mandatory, add a server-side layer: a mail flow rule, Google's footer setting, or a signature relay. With Scribe, client-side and server-side can be connected together; Scribe then uses client-side where it's available so people see their signature while writing, and server-side covers the rest (Scribe: Microsoft 365 server-side). The trade-offs, including the fact that server-side signatures don't appear in the sender's Sent Items, are in client-side vs server-side signatures and mobile email signatures.

Controlled publishing

Changes should go live in one step for everyone, not trickle out. In Scribe a signature is either Draft or Published; teammates keep the last published version until an admin publishes the change, which is then pushed automatically (Scribe: signature status). Use draft as your review stage: build the change, have the approver preview it, then publish.

The native alternatives are covered in the Microsoft 365 and Google Workspace guides. Exchange Online's "Apply disclaimers" mail flow rule enforces a block in transit on every client (Microsoft Learn), but it can't produce designed, per-person signatures from directory data without considerable work, and users can't see the result while writing.

How do you audit compliance with the policy?

Run the same checks every month and keep the output. A policy audit answers four questions.

1. Is everyone covered? Compare the number of active mailboxes with the number of assigned and installed signatures. Scribe's Signatures page shows assigned teammates against total team size and installed signatures against the total expected, and each signature card shows design, teammate and installation status (Scribe: signature status).
2. Did installs fail? Look for Failed, Pending and Access lost statuses and their reasons: user not found, forbidden access, signature over Gmail's limit, or a lost integration (Scribe: installation statuses and errors).
3. Is the data complete? Filter teammates whose Smart Field information is missing. Missing data usually means a required field (title, phone, licence number) isn't in the directory yet (Scribe: assign teammates).
4. Which version was live, and when? Keep a change log of template and legal-text versions with publish dates and approvers. If you need a system record, Scribe's audit log is a paid add-on (Scribe: Plans), and its webhooks emit signature.published, signature.installation.failed, integration.disconnected and teammate events that you can write to append-only storage (Scribe: webhook events). Note that the documented signature.published payload identifies the signature and time but not the person who published it, so record approvals in your own change process.

For larger estates, automate the audit. Scribe's API can list every signature with its publish and installation status and the email addresses each one is assigned to (Scribe API: use cases), and the Scribe MCP server lets an AI assistant run the same checks in plain language; see managing signatures with AI (MCP) and the signature API and webhooks.

How do you update the policy without a new rollout?

If the policy is enforced through central templates, most changes are edits, not projects:

• New legal text: Legal approves the wording, an admin edits the block in the draft, previews it for one person per entity, and publishes. Every assigned teammate gets it at once.
• New title or office: change it in the directory or HRIS. Scribe's Smart Fields sync daily and can be refreshed manually (Scribe: Smart Fields).
• New entity or brand: add a template, assign it by a directory condition, and set its priority above the old one.
• Rebrand: treat it as a scheduled publish with a freeze on other changes; see the rollout playbook.
• Shared mailboxes and aliases: decide whether they carry a team signature or the sender's; see shared mailbox, alias and reply signatures.

Review the policy itself at least once a year and whenever a trigger occurs: a new entity, a director change in Germany, a new regulated role, a new market, or a change in your tracking assessment.

How should the policy handle special cases?

Most policy exceptions come from the same handful of situations. Decide them in advance so they don't become one-off requests.

• Contractors and agency staff. If they send from your domains, they're in scope. Give them a template that states their relationship accurately (for example "on behalf of" or the contractor's own company), because a full employee signature can imply authority they don't have.
• Executives. Executive assistants often send on an executive's behalf, and executives often want a reduced signature. Agree a leadership template rather than letting each office improvise, and keep the legal block on it.
• Shared and departmental mailboxes. A support@ or billing@ address needs a team signature with no personal name or direct line. In Scribe, Microsoft 365 shared mailboxes are imported and get their own signature, and shared mailboxes also work in Front; on Google Workspace, add the team address as an alias for each person who sends from it (Scribe: aliases and shared mailboxes).
• Multiple languages. Use one template per language where recipients need it, and keep the statutory text in the language of the jurisdiction whose law requires it.
• Leavers. When someone leaves, their mailbox may stay open for forwarding. Decide whether it keeps a signature, gets a "no longer with the company" notice, or is converted to a shared mailbox, and tie the decision to your offboarding checklist so the directory change triggers it.
• Personal pronouns, photos and accessibility notes. Make them optional fields the employee controls, not mandatory ones. Photos and pronouns are personal data, and in the EU and UK you need a lawful basis for including them; see GDPR and email signatures.
• Mail sent by other systems. CRM sequences and marketing platforms are covered by the policy only if their mail passes through your mail system or the tool has its own signature integration. Marketing platforms that send from their own servers need their footer configured there. List these systems in the policy so nobody assumes they're covered.

Why do signature policies fail?

When a signature audit turns up a mess, the cause is usually one of these:

1. The policy lives in a document, not in the tool. If compliance depends on people reading and copying, it decays from the first week. The template is the policy.
2. The directory is wrong. A signature manager publishes whatever the directory says. Fix titles, phone numbers and offices at the source, and give HR a way to correct them.
3. Nobody owns the legal block. Marketing edits it during a redesign, or it survives a director's departure. Name a legal owner and record each version.
4. Mobile is forgotten. The desktop rollout looks perfect, and a third of external mail goes out from phones without the required text.
5. Banners never come down. Expired campaigns linger for months. Give every banner an end date.

Frequently asked questions

What should a company email signature policy include?

Required fields (name, title, work phone, website, logo), the approved legal text per entity, brand and format rules, banned items such as personal quotes and unapproved banners, rules for tracking and campaigns, an owner, and an audit schedule. A copy-ready template is in this guide.

Can employees be stopped from editing their email signature?

Native Outlook and Gmail settings stay editable by users. A signature manager can overwrite local changes: Scribe's add-in re-injects the approved signature each time the compose window opens, and a server-side relay adds the signature in transit regardless of what's in the client.

Who should own the email signature policy?

Usually IT or Marketing owns the document, Legal or Compliance owns the legal block and the tracking decision, HR owns the directory data, and IT owns enforcement. Write the split into the policy so changes have a clear approver.

Should internal emails use the same signature?

Usually not. Most policies allow a shorter internal signature without the legal block. In Scribe an internal variant applies when every recipient is on the sender's domain; it works in Outlook and with server-side routing, not with the client-side Gmail install.

Is there a legal requirement to have an email signature policy?

No law requires a signature policy as such. Some laws require specific content on business email, such as UK company registration details or German Pflichtangaben, and a policy is the practical way to make sure that content is on every message. This is general information, not legal advice.

Can I restrict who in Scribe can change templates?

Scribe documents three workspace roles: Owner, Admin and Member. Members can edit and install only their own signature and have no access to templates, campaigns or settings. Scribe's plans page also lists role permissions and a paid audit log add-on; confirm with Scribe whether finer-grained permissions or approval steps fit your process.

How often should a signature policy be reviewed?

At least once a year, and whenever something changes: a new legal entity, a director or registered-office change, a new regulated role, a new market, or a new assessment of signature tracking.

How do I check that every employee has the approved signature?

Compare active mailboxes with assigned and installed signatures each month, review failed or pending installs and missing directory data, and keep a dated log of template versions. Scribe shows these statuses in the dashboard and exposes them through its API, webhooks and MCP server.

Related Handbook guides

• Email disclaimers: legal requirements by country and industry
• Email signature rollout playbook
• Client-side vs server-side email signatures
• Entra ID attributes for email signatures
• HRIS-driven email signatures
• GDPR and email signatures