CRM Enrichment From an Agent-Owned Inbox

The best contact-enrichment vendor you'll ever use is the bottom three lines of the emails already sitting in your inbox. Roughly 82% of business email contains a signature with at least a name and title — job titles, direct phone numbers, LinkedIn URLs, company websites, all volunteered by the sender, all sitting unparsed while teams pay data vendors for stale versions of the same fields.

Two cookbook pages make the case for treating an inbox as a CRM data feed: the CRM integration overview maps the sync patterns, and the signature enrichment recipe shows the extraction itself. Run the pipeline against an Agent Account — a beta feature giving your app a mailbox it owns outright — and every message that lands at sales@ or partnerships@ becomes a structured enrichment event, no human forwarding required.

Regex beats an LLM here, and it's not close

Counterintuitive in 2026, but the recipe's argument holds: signatures aren't unstructured prose. They're predictably structured — 3 to 6 lines, separated from the body by -- per RFC 3676, drawing from a small set of field types. A regex catches more than 95% of well-formed signatures, runs in microseconds, costs nothing per message, and produces the same output every time. The LLM fallback is justified only for the last few percent, and the recipe's advice is to skip it for version one.

Boundary detection plus field extraction is compact:

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",
]

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, ""

def extract(sig: str) -> dict:
    return {
        "phone": re.search(r"(?:\+?1[-.\s]?)?\(?\d{3}\)?[-.\s]?\d{3}[-.\s]?\d{4}", sig),
        "linkedin": re.search(r"linkedin\.com/in/[\w-]+", sig),
        "website": re.search(r"https?://(?!.*linkedin\.com)[\w./-]+", sig),
    }

Title extraction adds a keyword vocabulary that buckets matches into tiers:

TITLE_KEYWORDS = {
    "C-suite":  ["CEO", "CTO", "CFO", "COO", "CIO", "CMO"],
    "VP":       ["VP", "Vice President"],
    "Director": ["Director", "Head of"],
    "Manager":  ["Manager", "Lead"],
    "IC":       ["Engineer", "Designer", "Analyst", "Specialist"],
}

def extract_title(sig: str) -> dict | None:
    for tier, keywords in TITLE_KEYWORDS.items():
        for kw in keywords:
            m = re.search(rf"\b({kw}[^\n,]*)", sig, re.IGNORECASE)
            if m:
                return {"raw": m.group(1).strip(), "tier": tier}
    return None

That tier field is what your sales team actually filters on; "raw title text" is trivia, "C-suite at an open opportunity" is a routing signal. Note the iteration order doubles as precedence — a "Director of Engineering" should match the Director tier before "Engineer" drags them down to IC.

The cross-referencing trick is the whole product

Any single email gives you a partial signature. The "Sent from my iPhone" reply has nothing. The quick thank-you carries just a name. The mid-thread message has the full block. Per the recipe's analysis, extracting from one message nets about 67% field completeness — annoying enough that people stop trusting the data.

The fix: pull the last three messages from the same sender, extract from each, and merge, keeping the most complete value per field. That alone lifts completeness to roughly 91%. From 67 to 91 with one loop and a merge function — there's no model upgrade anywhere in ML with that cost-benefit ratio.

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)  # most complete value per key wins

The same trick backfills the boundary-detection misses: inline signatures with no -- delimiter slip past split_signature, but the sender's other messages usually carry a well-formed block, so the merged record recovers what any single parse dropped.

Free intelligence from DNS

The sender's domain tells you things no signature does, in three lookups that never touch the message body:

import dns.resolver

def domain_intel(domain: str) -> dict:
    return {
        "mx":    [r.exchange.to_text() for r in dns.resolver.resolve(domain, "MX")],
        "spf":   [r.to_text() for r in dns.resolver.resolve(domain, "TXT")
                  if "v=spf1" in r.to_text()],
        "dmarc": [r.to_text() for r in dns.resolver.resolve(f"_dmarc.{domain}", "TXT")],
    }

MX records reveal whether the company runs Google Workspace, Microsoft 365, or self-hosted mail; SPF records expose the tools they've authorized to send (SendGrid, Salesforce, Mailgun); a DMARC record signals email-security maturity — sometimes a buying signal in itself if you sell security tooling.

Where the data lands

The CRM hub rounds out the destination side, and each target has a different shape to map onto. The Salesforce recipe maps senders to Contact / Account / Task records using the Composite and Bulk API 2.0 patterns. The HubSpot version leans on HubSpot's automatic company creation and batches contacts and engagements. Pipedrive wants senders mapped onto its Organization → Person → Deal hierarchy. There's also a scheduled sync recipe that pulls new senders from team mailboxes, enriches them with exactly this signature pipeline, and pushes them to the CRM on a timer rather than per message — the right call when your CRM rate-limits writes.

Beyond contact records, the same hub links a communication-patterns agent that scores every external contact from 0 to 100 across four signals and flags single-threaded accounts at churn risk — the kind of relationship intelligence that only works when the underlying contact data is complete. Enrichment is the input; those pipelines are where it compounds.

Two cautions from the docs before you ship. The privacy one: the sender gave you the email, but writing inferred attributes like job tier into a CRM is a different processing context — document it in your privacy notice. The mundane one: LinkedIn retired /pub/ profile URLs years ago, so match /in/ only, and the phone regex above leans North American — add E.164 patterns (\+\d{6,15}) for international correspondents.

Run it on your own sent folder first

Point the extractor at the last 50 messages you've received, eyeball the merged output, and count how many of those contacts your CRM currently has a title or phone number for. That delta is your business case, computed in an afternoon. What's the emptiest field in your CRM right now — and how many of its values are sitting in signatures you already have?

推荐订阅源