PeopleDB
Docs Pricing | | Sign in Get API key
Email Verification API

Verify an email address
before you send.

The email verification API is one HTTP call that checks whether an address can receive mail: syntax, DNS, a live SMTP conversation with the receiving server, and the catch-all and disposable cases that make the answer hard. You get a classification of valid, risky, or invalid, a 0 to 100 score, and the individual check results, so your code can choose its own threshold.

Get 10 free credits → No card required.

The call

GET /api/v1/email_verifications 
curl "https://peopledb.co/api/v1/email_verifications?email_address=somebody@example.com" \
  -H "Authorization: Bearer $TOKEN"

// ←
{
  "email": "somebody@example.com",
  "valid": true,
  "classification": "valid",
  "score": 95,
  "checks": {
    "syntax": true,
    "mx_record": true,
    "smtp_deliverable": true,
    "disposable": false,
    "typo_suggestion": null,
    "accepts_any_email": false
  },
  "warnings": [],
  "errors": []
}

POST with the same parameters works too. Optional smtp_timeout (1 to 60 seconds, default 10) bounds the SMTP step. Full field reference in the API docs.

What one call checks

Syntax
A real RFC 5322 parse, not a regex. Catches malformed strings and common typos in well-known domains, which come back as a typo_suggestion instead of a silent failure.
MX records
A DNS lookup confirms the domain publishes a mail exchanger. No MX and no fallback A record means nothing can deliver there, and the address is invalid without an SMTP round trip.
SMTP deliverability
A conversation with the receiving server up to RCPT TO, stopping before any message is sent. This is the only check that speaks to the mailbox itself, and the one every "instant" verifier skips.
Catch-all detection
Some servers accept every recipient, so a positive SMTP answer proves nothing. The check probes for that behavior and reports it as accepts_any_email, which moves the result to risky rather than pretending it is valid.
Disposable domains
Throwaway providers are flagged so a signup form or a lead list can treat them differently from a real inbox.

How the score is built

The score is additive and transparent, so a threshold means the same thing on every address. Syntax contributes 20 points. A verified MX record contributes 40 (15 if it had to be assumed). A confirmed SMTP mailbox contributes 35; a catch-all server contributes 15 and an assumed result 10. Warnings such as a disposable domain or a typo suggestion subtract up to 25. The score_details object in the response shows exactly which of these applied.

The classification is the score read against the evidence: valid when the mailbox was confirmed, invalid when a check failed outright, and risky when the server would not say. Risky is the honest answer for catch-all domains, greylisting hosts, and the biggest inbox providers, which will not tell any verifier the truth over SMTP. The long version of why includes the protocol traces.

Signal Points Field
Syntax valid +20 checks.syntax
MX record verified (or assumed) +40 (or +15) checks.mx_record
SMTP mailbox confirmed +35 checks.smtp_deliverable
Server accepts any recipient +15 checks.accepts_any_email
SMTP result assumed (no answer) +10 checks.smtp_deliverable
Warnings (disposable, typo, other) up to −25 warnings[]

Where it fits

After enrichment, before a campaign
Addresses returned by any enrichment step, PeopleDB's /people endpoint included, are checked for deliverability already. Running a list through verification right before a send catches what changed since, which is what protects sender reputation.
Signup and lead forms
A typo suggestion at the moment of entry and a disposable flag before the record hits your CRM cost one credit and save a support ticket.
Lists from other tools
Domain-first finders are good at guessing patterns and less good at proving mailboxes. Verification is the second opinion, and it does not care which tool produced the address. See how PeopleDB compares to Hunter for the domain-first case.

Common questions

What does a verification cost?

One credit per address, unless the result is invalid: an address that fails a check outright is not charged. Valid and risky results are, since the checks ran to completion. Credits are the same ones used for lookups: 15¢ each at the smallest tier, 6¢ at volume, never expiring.

What does "risky" mean?

The address is well-formed and the domain accepts mail, but the server would not confirm the specific mailbox. Catch-all domains, greylisting hosts, and the large inbox providers all land here. The score tells you how much of the evidence was positive; pick a threshold per use case, stricter for cold outreach than for a password reset.

Does verifying an address send anything to it?

No. The SMTP check stops after the server answers RCPT TO, before any message body. The mailbox owner sees nothing.

How long does a check take?

Usually under two seconds. The SMTP step is the slow part and is bounded by the smtp_timeout parameter (default 10 seconds, maximum 60). Slow or greylisting servers return a risky result rather than blocking your request.

Can I verify addresses that came from another tool?

Yes. The endpoint takes any address, so it works as the last step after a domain search, a CSV import, or a signup form, whichever tool produced the list. The enrichment guide covers where verification belongs in a pipeline.
Pricing
One credit per address checked. Invalid results are free; valid and risky results are charged.
Credits are shared with lookups: 15¢ down to 6¢ each, prepaid, never expiring.
Get started → 10 free credits. No card required.

Need the address first? The LinkedIn lookup and GitHub lookup tools resolve a profile to a contact record, and the contact enrichment guide explains the whole pipeline.