The problem this solves
The list is ready, the sequence is written, and the only thing between you and the send is the question nobody wants to answer: how many of these addresses will bounce? Push the whole list into HubSpot and the answer arrives from the sending domain a week later, as a reputation problem that takes a month to repair.
Verification results are not binary, which is where lists go wrong. A deliverable address is safe and an invalid one is an easy removal. The two middle categories need their own bucket: risky addresses (role accounts, disposable providers, mailboxes with bounce history) and catch-all domains, where the server accepts anything and the check cannot confirm a person is behind the address. Treating them as clean inflates the bounce rate; treating them as invalid throws away real contacts.
Duplicates compound the problem. The same person appears twice with different casing, or two contacts share a domain when you wanted one per account. HubSpot uses the email address as the contact identifier, so the second copy silently updates the first, and the counts you see after the push never match the list you started with.
How the mission runs
- Read list <name> and estimate the work. The Lead Verification Agent opens the saved list <name>, counts the rows with an email present, and shows the credit estimate for the verification before it starts. Rows without an email are set aside with their own count rather than silently dropped, so the totals reconcile at the end.
- Verify every address and assign a status. Each address is checked for syntax, domain and mailbox and lands in one of four statuses: deliverable, risky, catch-all or invalid. The status and the reason behind it - mailbox confirmed, role account, disposable provider, accept-all server, no mail records for the domain - are written to the row, so a rep can see why an address was held back.
- Dedupe on email and on domain. Addresses are lowercased and trimmed, exact duplicates are collapsed to the row with the most complete data, and then the list is deduped on domain by your rule: one contact per company by default, or every contact when you ask for it. Each removal is logged with the row it was folded into.
- Push the clean rows to HubSpot as static list <name>. Only deliverable addresses go to HubSpot. The agent matches each against existing contacts by email so nothing is created twice, stages the new contacts and the list membership as one batch, and waits for your approval. On approval, static list <name> is created or updated in HubSpot with exactly the rows you reviewed.
- Email you the counts by status. A summary goes to your inbox through Gmail: total rows, deliverable, risky, catch-all, invalid, missing email, duplicates removed by email, duplicates removed by domain, and the number that landed in HubSpot. The risky and catch-all rows are attached as their own CSV so you can decide what to do with them separately.
The prompt
This is the exact objective the agent receives. Swap the obvious placeholders for your own domain, segment or channel and run it as-is from the console, Slack, or the API.
What comes back
A HubSpot static list named <name> containing only deliverable, deduplicated contacts, each matched to an existing record or created once after your approval. In the workspace, list <name> now carries a verification status, a reason and a verified-at date on every row, so it stays useful for the next mission. Your inbox gets the counts by status, the dedupe counts by reason and a CSV of the risky and catch-all rows held back, and every action sits in the audit trail with its credit cost.
Make it yours
- Send the catch-all rows to HubSpot as well, into a second static list named <name> - catch-all, so a rep can work them by phone instead of email.
- Replace HubSpot with Pipedrive, Attio or Zoho CRM; the verification and dedupe logic stays the same and only the destination step changes.
- Add a fit score before the push and ask for deliverable rows scoring 70 or above, so the static list is both clean and prioritized.
- Schedule it monthly against the persistent list so new rows are verified as they arrive and addresses that have gone stale are caught.
Frequently asked questions
What is the difference between risky and catch-all?
Risky describes the address itself: a role mailbox such as info@, a disposable provider, or a mailbox with recent bounce history. Catch-all describes the domain: the mail server accepts every address, so the check cannot confirm that a person is behind this one. They are reported separately because they call for different decisions.
Will this create duplicate contacts in HubSpot?
No. Every clean row is matched to existing HubSpot contacts by email before the push, and matches are added to the static list without changing their other properties unless you ask. New contacts are created once, in a staged batch you approve first.
Can the agent write the verification status into HubSpot?
Yes. Ask for the status and verified date on a custom contact property, and the agent proposes the property and includes the write in the same approval.
How is this metered?
Verification is charged per address checked, and the agent shows the estimate before it starts. Every step of the mission, including the HubSpot write, is listed in the audit trail with its credit cost.