Source: https://cli.nylas.com/guides/email-signature-extraction-cli

# Email Signature Extraction from the CLI

Nylas email now includes a signatures command group. Use it to manage stored signatures for outbound sends, then parse inbound signature blocks when you need contact enrichment from received messages.

Written by [Qasim Muhammad](https://cli.nylas.com/authors/qasim-muhammad) Staff SRE

Reviewed by [Qasim Muhammad](https://cli.nylas.com/authors/qasim-muhammad)

Updated May 15, 2026

> **TL;DR:** Use [`nylas email signatures create`](https://cli.nylas.com/docs/commands/email-signatures-create) and [`nylas email signatures list`](https://cli.nylas.com/docs/commands/email-signatures-list) to manage stored signatures, then send with `--signature-id`.

## Two signature jobs: outbound and inbound

The phrase email signature can mean two different things. Outbound signature management is the footer you attach to messages you send. Inbound email signature extraction is the process of parsing a sender's job title, phone number, company, or social links from a received message.

Nylas CLI helps with both. [`nylas email signatures create`](https://cli.nylas.com/docs/commands/email-signatures-create) manages stored outbound signatures, and [`nylas email read --json`](https://cli.nylas.com/docs/commands/email-read) gives you message bodies that can be parsed for enrichment.

## 1. Create a stored signature

Put the HTML signature in a file so it can be reviewed and versioned with the rest of your email assets.

```html
<p>Best,<br />Qasim</p>
<p>
  Nylas<br />
  <a href="https://www.nylas.com">nylas.com</a>
</p>
```

```bash
nylas email signatures create "$NYLAS_GRANT_ID" \
  --name "Default sales signature" \
  --body-file signature.html \
  --json
```

## 2. List and inspect signatures

Store the returned signature ID in your deployment config, inspect it with [`nylas email signatures show`](https://cli.nylas.com/docs/commands/email-signatures-show), or use [`nylas email signatures list`](https://cli.nylas.com/docs/commands/email-signatures-list) when setting up a local script.

```bash
nylas email signatures list "$NYLAS_GRANT_ID" --json

nylas email signatures show sig_123 "$NYLAS_GRANT_ID" --json
```

## 3. Send with a signature ID

Pass the ID to [`nylas email send`](https://cli.nylas.com/docs/commands/email-send) so automated messages use the same footer as interactive sends.

```bash
nylas email send "$NYLAS_GRANT_ID" \
  --to customer@example.com \
  --subject "Welcome to the project" \
  --body "Here are the next steps." \
  --signature-id sig_123 \
  --yes \
  --json
```

## 4. Extract signatures from received mail

For contact enrichment, use [`nylas email search`](https://cli.nylas.com/docs/commands/email-search) for recent messages, read the full body with [`nylas email read`](https://cli.nylas.com/docs/commands/email-read), and pass the text to a parser. Keep the first parser conservative: split near common sign-off lines and extract only fields with high confidence.

```bash
nylas email search "*" "$NYLAS_GRANT_ID" --from customer@example.com --limit 5 --json

nylas email read msg_123 "$NYLAS_GRANT_ID" --json > message.json
```

```javascript
const message = require("./message.json")
const body = String(message.body ?? "")
const signature = body.split(/best,|regards,|thanks,/i).at(-1) ?? ""

const phone = signature.match(/\+?[0-9][0-9 .()/-]{7,}/)?.[0]
const title = signature.match(/(?:Director|Manager|Engineer|Founder|VP)[^<\n]*/i)?.[0]

console.log({ phone, title })
```

For a deeper enrichment workflow, pair this page with [Parse Email Signatures for Contact Enrichment](https://cli.nylas.com/guides/enrich-contacts-from-email).

## Why manage outbound signatures as stored objects?

Stored signatures keep email footers out of ad hoc scripts. Instead of copying the same HTML into every send command, create the signature once, review it, and reference it by ID. That makes automated sends easier to update when branding, titles, legal text, or phone numbers change.

A stored signature also gives teams a cleaner permission boundary. The send workflow can use a signature ID without editing the signature body. Marketing or operations can update the stored footer separately, and the automation keeps using the same ID. This is less error-prone than embedding a footer inside every CI job or shell script.

Use clear names. `Default sales signature`, `Support escalation signature`, and `Billing notice signature` are easier to operate than `sig1` or `footer`. When multiple grants have different signatures, store both the grant ID and signature ID in configuration so the send script does not mix accounts.

## What makes a good HTML email signature?

Keep the HTML small. Many mail clients strip scripts, external CSS, forms, and complex layout. A signature should be plain HTML with text, a few links, and maybe an image if the organization already uses one. The more complex the footer, the more likely it is to render differently across clients.

Use absolute HTTPS links and short link text. A signature link to the company site, calendar page, or support page should be easy to inspect. Avoid tracking-heavy links in operational email unless the recipient expects them. Transactional and support messages should prioritize trust over marketing measurement.

Include only fields that are stable and useful. Name, role, company, website, and one reply path are usually enough. Long disclaimers, many social links, and large images can make automated messages feel noisy. If legal text is required, keep it in the stored signature so every send uses the approved copy.

## What can inbound signature extraction safely infer?

Inbound signature extraction should be conservative. A parser can often find phone numbers, names, titles, company names, and URLs, but it should not treat every line after `Thanks` as verified data. People forward messages, quote prior threads, and include multiple signatures in one body. Store extracted fields with confidence and source message ID.

Start with simple patterns before adding AI. Split near common sign-offs, remove quoted replies, and extract obvious fields such as phone numbers and LinkedIn URLs. Then add review or confidence thresholds before writing to a CRM. A wrong title or phone number can be worse than no enrichment at all.

Keep provenance. If a workflow updates a contact with a phone number from an email signature, store where it came from: message ID, sender, timestamp, and parser version. That lets support or sales operations explain why a field changed and roll it back if the parser made a bad guess.

## Where do signature IDs fit in send workflows?

Signature IDs work well in templates, CI notifications, onboarding emails, and manual support scripts. The script builds the message body for the specific event, then attaches the stored footer by ID. This keeps the body focused on the action while the signature handles identity and contact details.

For templates, store the signature ID next to the template name. A sales welcome email and a support update may use different signatures even when they send from the same account. Keeping the mapping in configuration avoids conditional footer logic inside the script.

For high-risk sends, print the signature ID in dry-run output. A human reviewing a campaign or operations message can confirm the sender, recipient list, subject, and signature before the script sends. The body preview does not need to include secrets or every HTML detail, but the chosen signature should be visible.

## How do you keep signature data clean?

Review stored signatures like any other customer-facing asset. Remove old job titles, stale links, retired phone numbers, and outdated legal copy. If a signature belongs to a team rather than a person, use team-owned contact details so the footer survives staffing changes.

When extracting inbound signatures, separate enrichment from overwrite. New data can enter a review queue, update empty fields automatically, or create suggestions for a contact owner. Directly overwriting populated CRM fields from email signatures can create churn when people change roles or use alternate footers.

Measure parser outcomes. Track how many messages contain candidate signatures, how many fields are extracted, how many are accepted, and how many are rejected. Those numbers help you tune patterns and decide whether a more advanced parser is worth the added complexity.

## How does signature extraction help CRM enrichment?

Email signatures often contain fields that users do not type into forms: direct phone numbers, titles, departments, company URLs, office locations, and social profiles. Extracting those fields can improve contact records, but the workflow should treat them as suggestions until confidence is high.

A good enrichment pipeline keeps the source message attached to each suggestion. If a sales operator sees a new phone number, they should be able to trace it back to the email where it appeared. That context helps them decide whether to accept the change or leave the existing CRM value alone.

Do not overwrite high-trust fields with low-trust extraction. If a contact record has a verified phone number, a parser should not replace it because a forwarded email contained another number. Add rules for empty-field fill, human review, and source priority before enabling automatic writes.

## Where should the signature parser stop?

A signature parser should not try to understand the full email thread. It should identify the likely footer for the newest sender and extract a small set of fields. Quoted replies, forwarded content, legal disclaimers, and newsletter footers can all look like signatures if the parser is too broad.

Use boundaries before patterns. Strip quoted text, remove previous message headers, and split around common sign-offs before extracting phone numbers or titles. Then apply field-specific patterns. This reduces false positives and makes parser behavior easier to explain.

When the parser is unsure, return `unknown` instead of guessing. Missing enrichment is safer than wrong enrichment. A future parser version can improve recall, but bad data in a CRM or customer profile can create support work and trust problems.

## How should teams govern outbound signatures?

Outbound signatures are customer-facing content. Treat them like templates: reviewed, versioned, and assigned to the right senders. If a signature includes legal copy or brand language, keep the source file in version control and create the stored signature from that file.

Use a naming convention that includes purpose and owner. For example, `support-default-2026`, `sales-us-default`, or `billing-notice-footer`. Clear names make list output useful and reduce the chance that a script sends with the wrong footer.

Review signatures after org changes. People change titles, teams rename products, URLs move, and disclaimers expire. A quarterly review is enough for many teams. The CLI makes it easy to list stored signatures and compare them with the approved source files.

## How do you test signature automation?

Test outbound signatures by sending to a managed test inbox and reading the delivered message. Assert that the expected footer text, links, and sender identity are present. Keep the assertion focused on stable markers so harmless HTML formatting changes do not fail the suite.

Test inbound extraction with saved message fixtures. Include a simple signature, a reply thread, a forwarded message, a long legal disclaimer, and a message with no signature. The parser should extract only high-confidence fields and return an empty result when the message does not contain a useful footer.

Run one live smoke test for the full path: send a message with a stored signature, read it back from the inbox, and pass it through the parser. That proves the stored signature, send command, read command, and extraction logic still agree.

## How do signatures work across multiple sending accounts?

Each sending account can have its own signature set. A sales mailbox, support mailbox, and billing mailbox may all need different footers. Store signature IDs per grant instead of treating one ID as global. That prevents a support script from sending with a sales footer.

When a workflow can choose among senders, validate the sender and signature together. The configuration should say which signature belongs to which grant. If a signature ID is missing or belongs to another account, fail before sending. It is better to stop than to send a customer-facing email with the wrong identity.

For shared team addresses, use team-owned signature text. A shared mailbox should not include one employee's title or phone number unless that person owns all replies. Team signatures age better and make automated email easier to maintain.

## What human review belongs in signature extraction?

Human review is useful when extracted data changes an important record. A parser can suggest a title or phone number, but a person may need to confirm it before it appears in a CRM, support profile, or account record. Review is especially valuable for high-value accounts and regulated data.

Build the review screen around the source text. Show the extracted field, the confidence reason, and a short excerpt from the signature. The reviewer should not need to open the full email thread unless the excerpt is unclear. This keeps review fast while preserving context.

Over time, accepted and rejected suggestions become training data for rules. If reviewers keep rejecting phone numbers from legal disclaimers, add a rule to suppress that pattern. If they keep accepting titles from a specific signature format, make that extraction more confident.

Keep reviewer actions reversible. A contact update that came from a signature should be easy to undo, and the old value should remain visible in history. Reversibility makes teams more willing to accept useful suggestions because mistakes are not permanent.

Record why a reviewer accepted or rejected a suggestion when the reason is not obvious. Short reason labels such as wrong person, old role, legal disclaimer, or personal phone number give maintainers better feedback than a simple approve or reject count. Those labels help improve extraction rules without storing more message text than the workflow needs.

## References for this workflow

- [Nylas email signatures documentation](https://developer.nylas.com/docs/v3/email/signatures/) -- stored signatures and signature IDs
- [Nylas Email API documentation](https://developer.nylas.com/docs/v3/email/) -- message read, send, and search concepts
- [RFC 5322 Internet Message Format](https://www.rfc-editor.org/rfc/rfc5322) -- message body and header format background

## Next steps

- [Send email from the terminal](https://cli.nylas.com/guides/send-email-from-terminal) -- outbound send patterns
- [Personalize outbound email from the CLI](https://cli.nylas.com/guides/personalize-outbound-email-cli) -- templates and mail merge
- [Parse email signatures for contact enrichment](https://cli.nylas.com/guides/enrich-contacts-from-email) -- inbound extraction pipeline
- [Command reference](https://cli.nylas.com/docs/commands) -- email send and signatures commands