Import Email Signatures Into Your CRM With an Agent

Email signatures are the most valuable dataset your CRM is throwing away. Roughly 82% of business email carries a signature with at least a name and title — and usually a phone number, a LinkedIn URL, a company name, sometimes a whole org-chart hint. That's structured data masquerading as prose, delivered free with every message, and most platforms scroll right past it.

You don't need a data vendor or even an LLM to harvest it. A few hundred lines of regex, a cross-referencing trick, and a dedicated inbox for the agent doing the work gets you to production-usable accuracy. Here's the build.

Regex beats the LLM here (really)

For genuinely unstructured prose, a model wins. Signatures aren't unstructured — they're predictably structured: 3–6 lines, often separated from the body by the RFC 3676 -- delimiter, drawing from a small set of field types. A regex pass catches over 95% of well-formed signatures, runs in microseconds, and costs nothing per message. Keep the LLM as a fallback for the weird 5%, and skip it entirely in version one.

Find the boundary first:

import re

SIG_DELIMITERS = [
    r"\n--\s*\n",                # RFC 3676 standard
    r"\nSent from my (iPhone|iPad|Android)",
    r"\nBest,?\s*\n",
    r"\nRegards,?\s*\n",
    r"\nCheers,?\s*\n",
]

def split_signature(body: str) -> tuple[str, str]:
    for pat in SIG_DELIMITERS:
        m = re.search(pat, body)
        if m:
            return body[:m.start()], body[m.end():]
    return body, ""

Then pull fields — phone, LinkedIn (/in/ only; the /pub/ URL shape was retired years ago), website, plus title and company against a keyword vocabulary. The detail that makes this sales-relevant: classify titles into tiers (C-suite, VP, Director, Manager, IC). "CEO" as a routing signal is worth far more than the raw title string.

The trick that takes you from 67% to 91%

One email rarely gives you a complete picture. The "Sent from my iPhone" reply has nothing. The quick thank-you has just a name. The mid-thread message has the full block.

So don't extract from one message — pull the last three from the same sender, extract from each, and merge, taking the most complete value per field:

def enrich(sender_email: str, n: int = 3) -> dict:
    messages = list_messages_from(sender_email, limit=n)
    signatures = [split_signature(m["body"])[1] for m in messages]
    fields = [extract(s) for s in signatures]
    return merge_fields(fields)

The lift is the headline number: single-message extraction nets about 67% field completeness; three-message cross-referencing hits about 91%. That's the difference between a column nobody trusts and one your sales team filters on.

Bonus intelligence that costs three DNS queries: the sender's domain reveals their mail host via MX records, their tooling via SPF includes (SendGrid, Salesforce...), and their security maturity via DMARC. Free enrichment, no email body required.

Give the agent its own inbox

Where does the mail come from? Two patterns, same infrastructure — a dedicated Agent Account (Nylas-hosted mailboxes, currently in beta) with a message.created webhook.

Pattern one: passive enrichment. The agent's own inbox — support@, outreach@ — already receives business mail. Every inbound message is a parsing opportunity; the webhook handler extracts, cross-references, and writes to the CRM.

Pattern two: user-initiated import. Stand up [e-mail] and tell users: forward any email that has the signature you want. Your handler identifies the forwarder, extracts the signature HTML, and saves it to their grant:

app.post("/webhooks/signature-import", async (req, res) => {
  res.status(200).end();

  const event = req.body;
  if (event.type !== "message.created") return;

  const msg = event.data.object;
  if (msg.grant_id !== IMPORT_GRANT_ID) return;

  // The webhook payload is a summary — fetch the full body.
  const full = await nylas.messages.find({
    identifier: IMPORT_GRANT_ID,
    messageId: msg.id,
  });

  // Whoever forwarded this is the user whose grant gets the signature.
  const forwarder = msg.from[0].email;
  const targetGrant = await db.grants.findByEmail(forwarder);
  if (!targetGrant) return; // unknown address — log and ignore

  const signatureHtml = await extractSignature(full.data.body);
  if (!signatureHtml) return;

  await saveSignature(targetGrant.grantId, signatureHtml, forwarder);
});

The mapping lookup is the load-bearing line: your app needs a table from user email address to grant_id, and an unknown forwarder should be ignored, not guessed at. The save itself goes through the Signatures API:

const signature = await nylas.signatures.create({
  identifier: targetGrantId,
  requestBody: {
    name: "Imported signature",
    body: signatureHtml,
  },
});

One import inbox serves every user — route by the from address on the forwarded email. The saved signature then attaches to outbound sends with a signature_id parameter, which works on agent mailboxes too: an outreach agent can send with a real, human-looking signature imported this way.

Edge cases that will find you

• Multiple signatures per email. A forwarded thread can contain blocks from several people. If you want the most recent sender's, extract above the first Forwarded message boundary.
• Oversized extractions. A sanity check earns its keep: a block over 20 KB is probably not just a signature. Log and skip.
• Per-grant ceiling. Each grant holds up to 10 signatures — check the count and update an existing one instead of failing on the eleventh.
• HTML only. The Signatures API stores HTML; a plain-text-only forward has nothing to extract.
• Image-heavy signatures. Corporate signatures often embed <img> tags pointing at company-hosted logos and headshots. Those URLs keep working as long as the company's servers do — if you want self-contained signatures, download the images, host them on your own CDN, and rewrite the URLs before saving.
• Sanitization is handled, sanity-checking isn't. The Signatures API sanitizes HTML on input, stripping unsafe tags and attributes, so you don't need your own sanitizer. But it can't tell you that you extracted half the email by accident — that's what the size check above is for.
• Privacy context. The data was sent to you, but writing inferred attributes (job tier, buying signals) into a CRM is a different processing context. Put it in your privacy notice.

Build it this week

The two halves are documented separately: the signature import inbox recipe covers the forward-to-import flow end to end, and the signature enrichment recipe covers the regex vocabulary and the cross-referencing math.

Next step: grab the last 50 messages from your own inbox, run the boundary-splitter above over them, and count the hit rate. If it's anywhere near that 82% figure, you've got a CRM enrichment pipeline hiding in mail you already receive.