1
Server connectivity
A connection signal helps distinguish a reachable mail system from a domain or server that cannot participate in the check at that moment.
Mail-server and mailbox signals
SMTP email verificationUseful evidence, not an inbox guarantee
Paste a list or upload a CSV to review how recipient mail systems respond, while keeping catch-all, temporary, and hidden-status limitations explicit.
- Input
- Paste addresses or upload CSV
- Output
- Verdicts with supporting signals
- Fair billing
- Unknown results do not use credits
What it means
SMTP checks ask the receiving system—not a static database
An SMTP mailbox check uses the early part of an email-delivery conversation to request a response for a recipient, then stops before message content is submitted. That response can be useful evidence. It is not universal proof because each server controls what it reveals and may change its answer over time.
Useful context
How to read SMTP-derived evidence
2
Recipient response
When the server gives a clear response for the requested recipient, it can support a positive or negative mailbox verdict without sending message content.
3
Server-imposed ambiguity
Catch-all behavior, temporary failures, throttling, filtering, and deliberately hidden mailbox status can make an SMTP result inconclusive.
The dashboard workflow
From raw list to a usable decision
No developer integration is required. Work through a list in the browser and keep the result attached to the address.
- 01
Paste or upload
Sign in to the dashboard, create a list, then paste email addresses or upload a CSV. Keep the original file as your source of record.
- 02
Run verification
Peopledat processes the list and returns verdicts with the supporting signals available for each address.
- 03
Review and export
Inspect uncertain and risk-marked results, decide what fits your sending policy, and export the list for your next workflow.
Read the result
Verdicts are decision support
Keep the verdict and its context together. A single label cannot account for consent, engagement, sender reputation, or a receiving server changing its behavior later.
Safe
The available checks support using the address. It is a positive verification signal, not a promise of delivery or inbox placement.
Invalid
The checks found a strong reason not to use the address, such as invalid structure, domain, or mailbox response.
Review the signal
Catch-all, disposable, role-account, inbox-full, disabled, and similar conditions need a policy decision rather than one universal rule.
Unknown
The receiving system did not provide a decisive answer. Peopledat does not deduct credits for results classified as unknown.
Put the result to work
Turn a server response into a measured list decision
Act on strong negatives
A clear invalid response can support removing or suppressing an address, subject to your own data-retention and source-of-truth rules.
Treat positives as current evidence
A favorable response is useful, but it cannot promise future delivery, inbox placement, engagement, or permanent mailbox availability.
Preserve inconclusive results
Keep catch-all and unknown conditions separate for review or later retesting. Results classified as unknown do not consume credits.
Clear limits, so you can use the result responsibly
- Email verification cannot guarantee delivery, inbox placement, engagement, or future mailbox availability.
- Receiving servers may hide mailbox status, throttle checks, or accept every recipient. Those cases can remain uncertain.
- Risk flags are context, not proof of fraud, consent, or a person's intent.
- Use the dashboard for list work, the versioned REST API for server integrations, or the origin-bound widget for advisory form checks. No official SDK is required.
Questions, answered plainly
Frequently asked questions
What is SMTP email verification?
It is a mailbox-checking technique based on the early exchange with a recipient mail server. The check asks how the server responds to a recipient and stops before submitting message content.
Does an SMTP check send an email?
The verification exchange is designed to stop before a message is delivered. It does not open or access the recipient inbox. Receiving systems can still log or restrict the connection.
Why can an SMTP result be unknown?
Servers may time out, throttle verification traffic, temporarily reject connections, hide recipient status, or use catch-all behavior. An honest verifier preserves that uncertainty instead of inventing a definitive answer.
Does SMTP verification guarantee delivery?
No. It is a point-in-time technical signal. Later delivery also depends on server policy, mailbox state, sender reputation, content filtering, authentication, and other factors outside a mailbox check.
Bring a list. Leave with a clearer decision.
Paste addresses or upload a CSV, review the evidence behind each result, and pay nothing for verdicts classified as unknown.
Create an account