Contact Enrichment API Verification Workflow: Confidence Scoring & Bounce Risk

Most teams think they have a verification problem. What they actually have is a routing problem. The enrichment call returns a contact, the contact has an email, the email gets a green checkmark somewhere in the UI, and the record flows straight into a sequence. Three weeks later the domain is throttled, the SDR team is complaining about "bad data," and nobody can point to the exact step where a bad address slipped through.

The green checkmark is the problem. A single boolean — verified or not — collapses six or seven independent signals into one bit of information, and then asks you to make a spend decision, a sending decision, and a CRM hygiene decision on top of it. That is not a verification workflow. That is a coin flip with a nice icon.

This article lays out a verification workflow you can actually defend: what each validation layer does, how confidence scores get constructed, where to gate and where to suppress, and how to wire the whole thing into a contact enrichment API so that verification becomes a measurable pipeline step instead of a black box.

Enrichment is the easy half. You send a domain, a name, a LinkedIn URL, or a company identifier, and you get back a record with an email, maybe a phone, a title, a company, and a handful of firmographic fields. That part is mostly a coverage question — does the provider have the record at all.

Verification is the hard half, because it is a question about the future. Will this address accept mail tomorrow? Will it accept mail from your domain, at your sending volume, from your IP pool? Coverage is a snapshot. Verification is a forecast.

Three costs stack up when verification is treated as a checkbox:

• Sender reputation damage. Hard bounces are one of the strongest negative signals mailbox providers use. A 3% hard bounce rate on a 20,000-send month is 600 failed deliveries, and the damage is not linear — it compounds across the shared reputation of your sending domain and any subdomains attached to it.
• Wasted credit spend. If you pay per enriched contact and then discard 15% of them post-verification, you paid full price for records you never used. Verification that runs before the expensive enrichment step changes the economics of the whole pipeline.
• Operational noise. Unverified records create downstream work: SDRs manually checking addresses, RevOps rebuilding suppression lists, analysts explaining why the "verified" segment still bounced.

The fix is not a better single check. It is a layered system where each layer produces a signal, the signals roll into a score, and the score drives a routing decision. Salesforce's own lead management guidance treats data quality and routing as a lifecycle concern rather than a one-time cleanup, which is the right mental model here — verification is a stage in the lifecycle, not a gate at the end of it. You can read their framing in the Salesforce Lead Management implementation guide.

When a provider says a record is "verified," they are usually describing the output of some subset of the following layers. Knowing which ones ran — and which ones did not — is the difference between trusting a score and guessing at one.

Does the address conform to RFC-shaped structure? Local part, @ symbol, domain, valid TLD. This catches typos, truncation, and malformed strings. It is nearly free and nearly useless on its own, because almost every address that reaches a database has already passed a syntax check somewhere upstream.

Does the domain exist, and does it publish mail exchanger records? An MX check catches dead domains, parked domains, and domains that exist for web hosting but accept no mail. It is fast, cheap, and catches a meaningful slice of garbage — but it says nothing about whether the specific mailbox exists.

This is the layer people mean when they say "real verification." The verifier opens a connection to the mail server, issues a RCPT TO command for the specific address, and reads the response. A 250 response means the mailbox is accepted. A 550 means it is rejected. This is the strongest signal available without actually sending mail.

It is also the layer most likely to be blocked, rate-limited, greylisted, or answered dishonestly. Many large providers return a generic acceptance for every address to prevent exactly this kind of probing. That is where catch-all detection comes in.

A catch-all domain accepts mail for any local part — anything@company.com resolves. That means an SMTP 250 from a catch-all domain tells you nothing about whether the specific person exists. Catch-all detection works by probing a random, almost certainly nonexistent address at the domain and seeing whether the server accepts it anyway.

Catch-all addresses are not invalid. They are unresolved. Treating them as verified is how teams end up with 8% bounce rates on segments that reported 95% verification.

info@, sales@, support@, admin@, hr@. These addresses are usually deliverable but behave differently: lower engagement, higher spam-complaint rates, often routed to a shared inbox or a ticket queue. They are not a deliverability risk in the way a dead mailbox is, but they are a performance risk. Classifying them lets you route them to a different sequence rather than suppressing them outright.

Disposable domains (throwaway inbox providers) and honeypot addresses (seeded traps designed to catch scrapers and bulk senders) are the highest-severity category. A single honeypot hit can meaningfully damage reputation. These should be suppressed unconditionally, regardless of what the SMTP probe said.

One more distinction matters operationally. Some verification signals are computed at request time — the SMTP probe, the catch-all check, the MX lookup. Others are static: a "last verified on" timestamp, a source-of-record flag, a historical deliverability score. Static signals are cheap and fast but decay. A record verified fourteen months ago is not a verified record; it is a record that used to be verified.

For additional context, see HubSpot on sales prospecting.

If your provider does not expose which signals are live and which are cached, ask. It changes how you should treat the output.

A confidence score is a weighted rollup of the signals above, expressed as a number — usually 0 to 100. The exact formula varies by provider, but the inputs are fairly consistent. What matters more than the formula is that you know which inputs are in it and how the bands map to actions.

Notice that the score is not a probability of deliverability in a strict statistical sense. It is a provider's confidence that the record is safe to use. Those are close but not identical, and the difference shows up in how you set thresholds.

The bands are the tunable part. A team sending 500 highly personalized emails a week can afford a manual review queue and should set the review band wide. A team sending 50,000 a month cannot review anything manually and should set the review band narrow, accepting a slightly higher suppression rate in exchange for a predictable bounce ceiling.

What you should not do is treat the score as decoration. If your workflow reads the score, logs it, and then sends everything above zero, you have built a dashboard, not a gate.

Order matters because each layer costs something — latency, credits, or both — and you want to short-circuit as early as possible. A record that fails syntax should never reach an SMTP probe.

The practical rule: run layers 1 through 4 on every record, because they are cheap and they eliminate the obvious failures. Run layer 5 selectively — it is worth it on any domain where you plan to send at volume. Run layer 6 on the records that survive, and only when the record is actually going to be used.

That last point is where most credit waste happens. Teams verify entire lists on ingest, including records that will sit in the CRM untouched for six months. By the time those records are used, the verification is stale and you paid for it twice.

Bounce risk reduction is not a single decision. It is a decision tree that runs at three points: before enrichment, before sending, and after the first send attempt.

• Hard bounce: permanent failure. Mailbox does not exist, domain does not exist, address is blocked. These should trigger immediate suppression and never be retried.
• Soft bounce: temporary failure. Mailbox full, server temporarily unavailable, message too large, greylisting. These should be retried on a schedule, with a cap.
• Block bounce: your sending reputation or content triggered a rejection. This is not a data problem — it is a deliverability problem, and suppressing the address will not fix it.

Conflating these three is the most common cause of "our verification does not work" complaints. A soft bounce that gets suppressed as a hard bounce removes a perfectly good contact. A block bounce that gets treated as a data issue hides a reputation problem behind a suppression list.

Before any record enters a sequence, it should pass a gate. A workable version:

1. Is the record flagged disposable or honeypot? → Suppress permanently. Stop.
2. Is the confidence score below your suppression floor? → Suppress. Stop.
3. Is the record on your global suppression list (previous hard bounce, unsubscribe, competitor)? → Suppress. Stop.
4. Is the confidence score inside the review band? → Route to manual review or a secondary verification pass. Stop.
5. Is the record role-based? → Route to the role-based sequence, not the primary one.
6. Is the record older than your freshness window? → Re-verify before sending.
7. Otherwise → Send.

Steps 1 through 3 are free and should run on every record. Steps 4 through 6 are where your thresholds live and where you tune based on observed bounce rates.

The retry cap matters more than the interval. Unlimited retries on soft bounces turn a temporary server issue into a reputation problem, because mailbox providers see repeated delivery attempts as a signal of a sender who does not clean their list.

The most common architectural mistake is putting verification at the end — enrich everything, then verify everything, then send. That order maximizes credit spend and minimizes the value of the verification signal, because by the time you verify, you have already paid for records you will throw away.

A better sequence:

1. Search and filter. Narrow the ICP before spending anything. Use firmographic and role filters to cut the candidate set down. This is where most of your cost control actually happens.
2. Preview. Check the size and shape of the segment before committing credits. If a filter combination returns 40 records when you expected 4,000, you want to know that before enrichment, not after.
3. Enrich. Pull the contact fields you need — email, name, title, company, phone if relevant.
4. Verify. Run the layered validation on the enriched records. Cheap layers first, expensive layers only on records that survive.
5. Score. Roll the signals into a confidence score and attach it to the record as a field, not as a transient value.
6. Route. Send the score and flags into a routing decision: primary sequence, role-based sequence, manual review, or suppression.
7. Write back. Push the score, the flags, and the verification timestamp into the CRM so the next person who touches the record sees the same signal you did.

Steps 4 and 5 are where the short-circuiting happens. If a record fails syntax or matches a honeypot list, it should never reach the SMTP probe. If a record is a catch-all, you may choose to skip the probe entirely and route straight to review, because the probe will not resolve the ambiguity anyway.

Where credits get spent, in rough order of magnitude: enrichment is the largest line item, SMTP probing is second, and everything else is rounding error. That is why the ordering above matters — you want the cheap disqualifiers running before the expensive confirmations.

For additional context, see Salesforce guide to B2B lead generation.

If you are running this at scale across paginated result sets, the cost side is covered in the guide to B2B leads API credit consumption and cost control. Verification sits between enrichment and activation, and the credit math only works if the cheap disqualifiers run before the expensive confirmations.

A verification workflow without metrics is a workflow you cannot tune. These are the numbers worth tracking, and — more importantly — the decision each one should drive.

The confidence distribution is the most underused of these. A batch where 80% of records score above 90 and 20% score below 40 tells you something specific: your filters are pulling from two different quality populations. That is a segmentation insight, not just a data quality number.

Track these per source and per filter combination, not just in aggregate. Aggregate numbers hide the fact that one filter is producing garbage while the rest of the pipeline is fine.

These are the ones that show up repeatedly once a verification workflow is running in production.

• Catch-all false positives. A catch-all domain returns 250 for every address, so the SMTP probe reports success and the record scores high. Fix: check the catch-all flag before trusting the probe result, and cap the score for catch-all records regardless of probe outcome.
• SMTP blocks mistaken for invalid. A server that greylists or rate-limits your probe returns a non-250 response, and your pipeline reads it as "mailbox does not exist." Fix: distinguish between a definitive rejection (550-class) and an inconclusive response (4xx, timeouts, connection refused). Inconclusive should route to review, not suppression.
• Role-based addresses flagged as risky. info@ is deliverable. Treating it as a deliverability risk removes usable contacts. Fix: classify role addresses separately and route them to a different sequence rather than suppressing them.
• Stale "verified" records. A record verified a year ago is not verified. Fix: store the verification timestamp as a first-class field and re-verify anything past your freshness window before it enters a sequence.
• Credit burn from re-verifying stable lists. Re-running full verification on a list that has not changed wastes credits. Fix: verify on ingest, re-verify on use, and only re-verify records past the freshness window.
• Verification results that never reach the CRM. The pipeline verifies, routes correctly, and then drops the score on the floor. The next campaign re-enriches the same record from scratch. Fix: write the score, flags, and timestamp back to the record as structured fields, not free-text notes, so they survive into the next workflow and remain filterable for reporting.
• Thresholds set once and never revisited. Bounce rates drift as your ICP, sending volume, and domain reputation change. Fix: review thresholds quarterly against observed bounce data.

The contact enrichment API returns verification signals alongside the enriched contact fields, so you are not making a second call or reconciling two systems. Records come back with the deliverability signals attached, and the confidence score is exposed as a field you can route on directly.

That matters for three reasons:

• You can gate before you spend. Verification signals arrive with the enrichment response, so a record that fails core checks can be discarded before it enters a sequence or a CRM sync.
• You can route on the score, not on a boolean. The score is a field, which means your routing logic can be as simple or as granular as your bounce data justifies.
• You can audit the decision later. Because the score and flags are stored with the record, you can reconstruct why a contact was sent, suppressed, or routed to review — which is what makes the workflow defensible when someone asks why a segment bounced.

For teams running recurring prospecting, the same signals apply to each refresh cycle, so a list that was clean last month gets re-checked rather than assumed. That pattern is described in more detail in the guide to lead generation API recurring list refresh.

Verification is the operational layer beneath the buying decision — it protects the value of the data you already paid for, and it gives you a defensible answer when someone asks why a segment bounced.

Verification does not live alone. It sits between enrichment and activation, and it touches everything downstream.

Pagination and scale. When you are pulling tens of thousands of records across paginated responses, verification has to run per page or per batch without blocking the pipeline. Design for streaming verification rather than a single end-of-job pass, or you will hold large result sets in memory waiting for the slowest SMTP probe to return.

Field mapping into CRM. The confidence score, the catch-all flag, the role flag, and the verification timestamp all need homes in your CRM schema. If they land in a notes field, nobody will use them. If they land in structured properties, they become filterable and reportable.

Agency delivery. Agencies running verification across multiple clients need predictable behavior: the same thresholds, the same suppression logic, the same reporting. Client-facing dashboards that show "verified contacts delivered" are only credible if the verification definition is consistent across accounts. The operational side of that — defining, measuring, and defending accuracy with clients — is covered in the guide to agency lead list data quality guarantees.

White-label workflows. When verification outputs feed a client-facing product, the score bands become a product decision, not just an internal one. You are choosing what "verified" means for your customers, and that definition needs to survive contact with their bounce data. The positioning side of that — building resellable B2B data products against competitor platforms — is covered in the guide to agency white-label lead list positioning.

1. Define your confidence bands and write them down. Safe-to-send, review, suppress.
2. Run cheap validation layers on every record; run SMTP probes only on records you are about to use.
3. Store the score, flags, and verification timestamp as structured fields.
4. Build the pre-send gate as an explicit decision tree, not an implicit assumption.
5. Separate hard bounces, soft bounces, and block bounces in your suppression logic.
6. Track hard bounce rate, soft bounce rate, catch-all share, and confidence distribution per source.
7. Re-verify on use, not just on ingest.
8. Review thresholds quarterly against real bounce data.

None of this is exotic. It is the difference between a verification checkbox and a verification workflow — and the workflow is what keeps your sending domain healthy, your credit spend controlled, and your bounce rate explainable when someone asks.

If you want to see how the signals are returned and how the score is exposed, start with the contact enrichment API and wire a single segment through the full pipeline before you scale it. One segment, one set of thresholds, one week of bounce data. Then tune.