How the WarmySender leads database serves data — quality, freshness, and reporting
What this page covers
WarmySender includes a B2B lead database with hundreds of millions of contacts. This page explains how the database serves results — the freshest contacts first — what the email_status labels mean, how to report a bad lead, and the structural safeguard (cross-customer corroboration) that prevents a single misclassified bounce from removing a contact for every other customer.
The database focuses on fresh, contactable B2B people: each record is a real person with a name, job title, company, work email, and LinkedIn profile. You browse and narrow the pool by job title, company, industry, and location (country, state, city), plus a free-text keyword search — so you can build a targeted list of decision-makers in minutes.
WarmySender is a 4-pillar outreach platform — Cold Emailing, Email Warmup, LinkedIn Outreach, and Multichannel sequences. The leads database powers the prospecting input to the Cold Emailing pillar. Leads you save from the database flow into the same campaign-prospect schema as a CSV import; nothing about the campaign engine treats database-sourced contacts differently from manually-imported ones.
How results are ordered
Search results are sorted newest-first — the freshest contacts appear at the top of every page, so the most recently added people surface before older records. That's the single ordering; results are not re-shuffled by anything else. For example, a contact added this week appears above one added last year, regardless of its email-status label.
Separately, addresses that are confirmed bad are filtered out of search entirely — you never see them, and they never count toward the "X leads match" total. The email_status label (explained next) tells you how confident we are in each address that is shown; it does not change where a contact appears in the list.
What each email_status label means
Every email in the database carries one of these labels. They reflect how the address was obtained and how confident we are in it; they do not reflect whether the inbox is currently active (we do not re-verify in real time — see Account safety below), and they do not change a contact's position in your search results (that's always newest-first — see How results are ordered above).
Verified
The email was confirmed deliverable by a verification provider at the time of import. SMTP handshake completed, the recipient mailbox accepted the message, no catch-all flag. This is the highest-confidence label.
Valid
The email passes syntax + domain checks (MX record present, DNS resolves, no role-account heuristics like info@ or noreply@) but did not complete an SMTP-handshake verification. Lower confidence than Verified but higher than Extrapolated.
Pending Manual Verification
The email was flagged by automated verification for ambiguous response (greylist, transient 4xx, catch-all that accepted then bounced async). These contacts are served — they just carry less confidence than Verified or Valid. Use the Report bad email feature if you encounter a bounce on one of these.
Extrapolated (pattern-guessed)
The email was inferred from a company's email pattern (e.g., the company uses [email protected] and the lead's first and last names are known). Not directly verified, so it carries lower confidence than the labels above — but these contacts are still served because, in practice, well-extracted patterns hit between 60-80% deliverability. If you import a batch of Extrapolated leads into a campaign, expect a higher bounce rate than a batch of Verified leads — your warmup network and reputation will absorb the difference, and our bounce classification pipeline will not penalize you for the spike.
Unavailable (filtered out of search)
The email was confirmed undeliverable — hard-bounced on a verification probe, the mailbox was reported dead, or the address was synthesized but failed an MX check. Contacts with this label are filtered out of every search page — you will never see them, and they never count toward the "X leads match" total. We keep the rows in the database (rather than deleting them) so that future re-verification passes can flip the label back to Verified if the mailbox is reactivated, and so the cross-customer corroboration policy has a target row to update when bounces come in.
Report a bad email — the new feature
If you reach out to a contact and their email hard-bounces, click the Report link in the lead's row in your leads view. A small popover opens with an optional "Reason" textarea (free-form — used internally to spot patterns); click the Report CTA to submit. The endpoint is POST /api/leads/:leadId/report-bad-email and it's idempotent — you can click multiple times from the same workspace without duplicating the report.
After submission you'll see a toast: "Reported. Thanks — we'll review with cross-customer corroboration." Behind that line is the structural safeguard described next.
Cross-customer corroboration — why one report doesn't delete a lead
By design, the platform never acts destructively on a single workspace's bounce report. The structural pattern from warmup bounce classification applies to leads-database bounces too: at least 2 distinct workspaces must report the same email as bad within a 60-minute window before the lead's email_status is flipped to 'Unavailable' and the row drops out of search results.
Why a single workspace's report is not enough
Three legitimate reasons a single bounce might be a false signal:
- Sender-side authentication failure. Your mailbox's SPF/DKIM/DMARC alignment failed at the recipient mail server, so it bounced — but the recipient mailbox is fine, and another sender with proper alignment would land. See Provider blocks for the full breakdown. We do not poison a global record on this signal class.
- Transient infrastructure failure. Your outbound mail host had a momentary DNS or TLS issue; the bounce was about your sending path, not the recipient. Our sender-DNS vs recipient-bounce distinction is the structural fix at the warmup layer.
- Spam-filter false positive on your specific domain. The recipient mail server rejected your message because of your domain's reputation, not the recipient's existence. Another customer with a clean domain reputation would land.
Requiring 2+ workspaces to agree means a single misclassified bounce structurally cannot poison the public lead pool. It also means a genuine bad email will be acted on quickly — typically within 5-30 minutes of the second report, because of the 60-minute corroboration window — without exposing the data to a single-customer attack vector.
What happens after corroboration triggers
- The lead's
email_statusflips to 'Unavailable'. - The row drops out of every customer's search results on the next query (no cache invalidation needed — the filter is applied on every read).
- The row is preserved in the database. Future re-verification passes can flip the label back to Verified if the address becomes deliverable again (operator policy: never delete, only re-label).
Common questions
What does 'Extrapolated' mean?
Extrapolated means the email was inferred from the company's email pattern. For example, if a company uses the pattern [email protected], and the lead's name is Jane Doe, the system extrapolates [email protected]. The address was not directly verified by an SMTP handshake, but well-extracted patterns typically hit 60-80% deliverability. Extrapolated contacts carry lower confidence than Verified or Valid ones, but they are still served (only confirmed-bad addresses are filtered out). If you import a batch of these into a campaign, expect a slightly higher bounce rate than a Verified batch — the platform's warmup network and bounce-fanout protection (see Why was this prospect skipped — bounce) absorb the difference without harming your sender reputation.
How do I report a bad lead?
Open your leads view, find the lead row, click the small Report link in the row's action column. A popover opens with an optional "Reason" textarea — write anything (or nothing) and click the Report CTA. The toast confirms: "Reported. Thanks — we'll review with cross-customer corroboration." A single report does not flip the lead's status; at least 2 distinct workspaces within a 60-minute window must report the same lead before its email_status changes to 'Unavailable' and the row drops out of search results.
Why did a lead disappear from my saved list?
Leads are never deleted from your saved list. A lead's email_status can flip from 'Verified' to 'Unavailable' if 2 or more distinct workspaces report a bounce within a 60-minute window — but the row stays in your saved list. What changes is whether the lead appears in fresh search results (it stops appearing) and whether a future verification re-check might re-flip the status. You can still export, import, or campaign a saved lead whose status flipped to Unavailable. The most common reason a "saved" lead seems to have vanished is filter state, not deletion — check your active filters.
Do other users see leads I reported?
Other users do not see your individual report. They see the aggregated outcome only after the corroboration threshold is met. If you are the only workspace to report a particular lead, no other customer's search results change. If a second workspace reports the same lead within 60 minutes of yours, the email_status flips to 'Unavailable' and the row drops out of search results for everyone on the platform. Your individual report-author identity is not exposed; only the aggregate count and timing.
What's a hard-bounce vs. a soft-bounce?
A hard-bounce is permanent — the recipient mailbox does not exist or has been closed (SMTP 5xx response codes 550, 553, etc.). A soft-bounce is transient — the mailbox exists but the message was rejected for a temporary reason (full inbox 4xx, greylist, momentary server unavailability). Only hard-bounces should trigger a "Report bad email" submission; soft-bounces typically resolve on retry.
How are search results ordered or sorted?
The freshest contacts come first. Results are sorted so the most recently added people appear at the top of every page, and they are not re-ranked by anything else — not by company size, not by email-status label, not by any hidden relevance score. A contact added this week appears above one added last year, regardless of its email-status label. Addresses that are confirmed bad are filtered out of search entirely, so they never appear and never count toward the "X leads match" total. The email-status label tells you how confident we are in each address that is shown; it does not change where that contact sits in the list (always newest-first — see How results are ordered above).
How fresh is the data, and how often are new contacts added?
The database is continuously refreshed with new B2B contacts, and the newest ones surface first in your search results — so the most recently added people are always the first you see. We're regularly adding fresh records and re-checking existing ones, which means each time you search you may see contacts that weren't there before. Because results are ordered newest-first, you don't need to do anything to find the latest additions — they're already at the top of the list.
Related guides
- Why was this prospect skipped — bounce — How bounce-fanout protects your domain reputation when a prospect bounces in one of your mailboxes
- Why was my prospect skipped — no LinkedIn URL — Companion explainer for LinkedIn-side URL resolution (Sales Navigator vs public profile)
- Page Speed & Performance FAQ — How the leads table renders without breaking Core Web Vitals (entry bundle <400 KB rule)
- Provider blocks (Gmail, Outlook, Yahoo) — Why a sender-side rejection should not be reported as a bad-email recipient
- Full documentation — All guides
- Support — How to get in touch
Still have questions? Email [email protected] with the lead ID or your search query, and we'll dig in.