Contact enrichment is the process of taking a partial record about a person and filling in the attributes a workflow needs: role, company, location, contact channels and the evidence behind each field. The mistake that quietly breaks CRM data quality is treating enrichment as one pass/fail check. A useful contact record actually answers three independent questions, and each can be true or false on its own:
- Identity confidence. Is this the specific person we think it is?
- Mailbox verification. Does a mail server accept messages for this address?
- Current employment. Does this person hold this role at this company today?
A record can pass any two and fail the third. A mailbox can be valid for a person who left the company last quarter. An identity match can be certain while the domain refuses to confirm any address. Conflating these into a single "verified" flag is the root cause of a familiar failure: outreach that lands technically but reaches the wrong person, or a clean-looking CRM full of stale employment data.
Three questions, three kinds of evidence
Each layer is established from different evidence, decays at a different rate, and fails in a different way.
| Layer | What it asserts | Typical evidence | How it decays | What it does not prove |
|---|---|---|---|---|
| Identity confidence | This record refers to one specific person | Name plus corroborating attributes: employer, title, location, profile consistency across sources | Slowly; identity is stable, but ambiguity grows with common names | That the person is reachable or still in the role |
| Mailbox verification | A server appears to accept mail for the address (an estimate; checks can be inconclusive) | SMTP-level acceptance checks, domain configuration, bounce history | Quickly after job changes, domain migrations, or mailbox policy changes | Who reads the inbox, inbox placement, permission to contact, or intent |
| Current employment | The person holds this role at this company now | Recent public role data, company announcements, hiring signals, recency of last confirmation | Continuously; roles change without notice | That the work email still routes to them |
The last column matters most. Mailbox verification in particular gets overloaded in practice. It is an estimate of server acceptance behavior, nothing more, and the check can come back inconclusive. Google's sender guidelines make a related point from the delivery side: authentication and sender reputation govern whether mail is accepted and where it lands, so a verified address is not a delivery guarantee and certainly not permission to send (Google sender guidelines).
CRM platforms increasingly bundle enrichment natively. HubSpot, for example, documents built-in contact and company enrichment for records in the CRM (HubSpot enrichment docs). Whatever tool performs the enrichment, the three-layer distinction still applies: the platform can fill fields, but your team decides what each status is allowed to mean downstream.
Worked example: four synthetic contacts
The following contacts are entirely synthetic and illustrative. Together they cover the four cases that a one-flag verification model handles badly.
| Contact (synthetic) | Identity confidence | Mailbox status | Employment status | Correct CRM handling |
|---|---|---|---|---|
| Dana Reyes | Low: two people with this name at similar companies in the same metro | Valid | Unconfirmed | Hold from outreach; enrich for disambiguating attributes before any write to primary fields |
| Marcus Oyelaran | High | Valid at old employer's domain | Changed employers 6 weeks ago per role data | Flag employment as stale; do not send to the valid-but-wrong mailbox; re-enrich at new company |
| Priya Shah | High | Catch-all: domain accepts everything, no per-address confirmation possible | Current, confirmed recently | Eligible for workflows; label mailbox as unknown, not verified; consider non-email channels first |
| Tom Keller | High | Valid | Current | Suppressed: prior opt-out on file; exclude from all outreach and from audience exports regardless of data quality |
Now apply an explicit written policy instead of a single flag. Illustrative example of a routing rule:
- Outreach-eligible requires identity = high AND employment confirmed within the last 90 days AND mailbox = valid AND no suppression.
- Enrich-first applies when identity is below high or employment is unconfirmed.
- Channel-shift applies when only the mailbox layer is unknown (catch-all).
- Suppressed overrides everything.
Run the four contacts through it: Dana routes to enrich-first because identity fails even though the mailbox passes. Marcus routes to enrich-first because employment fails even though identity and the mailbox both pass; a message accepted at his old address would reach nobody relevant. Priya routes to channel-shift; three of four conditions pass and only the mailbox is unknowable. Tom fails on suppression alone despite passing all three data layers. One "verified" checkbox would have cleared three of these four for outreach. The layered policy clears zero of them today, and that is the correct outcome. Note that this is a policy your team defines and enforces in its own workflows; enrichment tooling supplies the evidence, and your routing rules decide what each status is allowed to mean.
Writing enrichment into the CRM
Enrichment output is only as useful as the write discipline behind it. Three practices keep the layers separate inside the CRM:
Store statuses as fields, not implications. Mailbox status, identity confidence and employment-last-confirmed date should each be a visible property. If the only artifact of verification is that the email field is populated, every downstream user will assume all three layers passed.
Record where each field came from. When two sources disagree about employer, the tiebreaker is provenance and recency, not whichever value arrived last. See data provenance for how source and timestamp metadata makes conflicts resolvable instead of silent.
Gate destructive writes. Overwriting a company field because of a job-change signal is often warranted, but it should be reviewable. AstroFabric approaches this with approval-gated writes and audit trails, so enriched values land in the CRM through a step a human can inspect rather than a blind overwrite. Waterfall-style enrichment, where multiple sources are tried in sequence and the best-evidenced value wins, pairs naturally with this; see AI agents for waterfall data enrichment and the broader data enrichment term page.
Tradeoffs and failure handling
Strictness versus coverage. The 90-day employment window in the example above is a dial, not a truth. Tighten it and you exclude reachable people whose confirmation is merely old. Loosen it and stale roles leak into outreach. Pick the window per workflow: a high-stakes account motion can afford strictness; broad audience building for suppression or matching can tolerate more staleness.
Catch-all handling. Quarantining every catch-all address discards real people, since many legitimate company domains are configured this way. Treating catch-all as valid corrupts your quality reporting. The workable middle is an explicit "unknown" state with its own routing.
Name collisions do not resolve themselves. The Dana Reyes case can fail silently in a pipeline because both candidate identities produce plausible enrichment. The fix is requiring a second and third corroborating attribute (employer plus location plus title history) before identity is marked high, and refusing to merge candidate records until then. Treat merges as high-cost decisions; an incorrect merge is difficult to unwind cleanly.
Suppression must outrank quality. The most dangerous record in the example is Tom Keller, precisely because every data layer passes. Suppression status has to be checked last-before-send and first-in-routing, and it must survive re-imports and re-enrichment. Deleting suppressed contacts, rather than retaining them as blockers, is how opt-outs get violated by a future list upload.
For how these statuses feed downstream automation and lifecycle stages, the lifecycle CRM automation guide covers the workflow side.
FAQs
Does a valid mailbox mean I have the right person? No. Mailbox verification only estimates whether a server accepts mail for an address, and the check can be inconclusive. It does not establish who reads it, whether the name matches the person you researched, or whether they still work there. Identity confidence needs separate corroborating evidence.
How should a CRM handle catch-all domains? As an explicit unknown state. Keep the record eligible for enrichment and non-email workflows, exclude it from "verified" counts in reporting, and decide per workflow whether unknown mailboxes may receive email at all.
Why keep suppressed contacts instead of deleting them? Because deletion destroys the blocker. If the same person reappears through enrichment or an import, nothing stops the new record from entering outreach. A retained suppression record with reason and date lets matching logic catch the re-import first.
Next step
Write the three statuses into your CRM as separate fields this week, then run one segment through the four-way routing table above and count how many records a single verified flag would have mis-cleared. If you want autonomous agents to run that enrichment, verification and routing against your own objective, start with AstroFabric.