Docs

Email validation: classify recipient risk before you send.

Understand WillItInbox recipient validation, including syntax, DNS domain resolution, MX discovery, SMTP probes, catch-all domains, disposable addresses, role accounts, typos, confidence, guidance fields, and pending verification follow-up.

Open validator Validation API

validation layers

CSV

bulk uploads

API

automation ready

Validation result categories

WillItInbox avoids false certainty. It separates confirmed failures from risky or inconclusive results, then adds guidance fields so users know whether to send, suppress, wait, or review.

Status	Meaning	Typical action
valid	The mailbox appears reachable.	Keep, but still monitor bounces.
invalid	Syntax, domain, or mailbox evidence says it should not receive mail.	Suppress before sending.
risky	Catch-all, role, disposable, or policy signals raise risk.	Segment or verify with care.
unknown	The domain or mailbox probe did not provide reliable evidence.	Wait for follow-up when pending; otherwise review or send conservatively.

Guidance fields

Every result can include a user-facing answer and next step so apps do not have to interpret raw SMTP evidence themselves.

deliverability_answer: safe_to_send, do_not_send, pending_verification, or use_caution.
recommended_action: send, do_not_send, wait_for_verification, send_with_caution, or review.
user_message: plain-language explanation for the status.
next_step: follow-up type, status, reason, and expected final timing.

Signals WillItInbox checks

The validator combines deterministic checks, network evidence, conservative SMTP interpretation, and account-owned trust signals.

Syntax normalization, typo detection, disposable domains, role accounts, free-provider hints.
DNS domain resolution and MX record discovery before attempting mailbox-level checks.
SMTP mailbox probe, catch-all detection, and provider-aware response classification.
Manual suppressions, DSN bounce uploads, and ARF complaint uploads can mark addresses that should not be mailed again.

Trust signals and suppressions

Trust signals explain why an otherwise valid-looking address may still be unsafe for your account to contact.

Manual suppression

Add an address your team already knows should not receive campaigns, such as unsubscribed, blocked, or sensitive contacts.

DSN bounce

Upload delivery-status notifications so hard-bounce evidence can suppress repeat sends.

ARF complaint

Upload complaint feedback reports so complaint evidence becomes visible before the next list import.

Where validation fits

Validation is strongest before imports, cold outbound, signup enrichment, reactivation campaigns, and list hygiene sweeps.

Before import

Reject obvious bad addresses before they enter your CRM or product database.

Before campaigns

Reduce hard bounces and risky recipients before reputation damage happens.

In product

Use the API to validate signups or high-value workflow addresses.

Policy

Validation is a decision system, not a single yes/no answer

Mailbox providers do not all expose the same SMTP evidence, and some domains intentionally accept all recipients. WillItInbox separates confirmed failures from risk and uncertainty so teams can choose an appropriate suppression, segmentation, or retry policy.

Result	Risk	Typical policy
valid	Low technical risk	Accept, but still monitor bounces and complaints.
invalid	High hard-bounce risk	Suppress before sending.
risky	Context dependent	Segment catch-all, role, disposable, or policy-blocked addresses.
unknown	Inconclusive evidence	Wait for pending follow-up when `pending_verification` is present; otherwise review or send conservatively depending on campaign value.

Automation

Use the same policy everywhere addresses enter the system

Validation is strongest when signup forms, lead imports, outbound lists, support tools, and reactivation campaigns share the same evidence model. Use /docs/api for product workflows and /validator/bulk for CSV hygiene.

Run a real-message test

Use /test when the question is whether the exact production email is technically ready.

Validate recipients

Use /validator or /validator/bulk before imports, outbound, newsletters, and reactivation.

Automate checks

Use /docs/api when deliverability QA belongs in CI, release tooling, or an internal workflow.

Email Validation API solution

Review the product workflow for teams operationalizing email validation api and bulk verification.

Validation API guide

Understand how risky, catch-all, unknown, role, disposable, and invalid verdicts should drive product decisions.

Validation API example

Review request and response patterns for single validation, bulk verification, suppression, and webhook flows.

Bulk validation docs

Review the CSV upload, progress, export, and webhook behavior for larger recipient-list checks.

API docs

Use the REST API reference when validation, bulk jobs, webhooks, reports, or usage need to run from your own systems.

Pricing

Compare validation volume, monitoring, API access, reporting, and workspace limits by plan.

FAQ

Can SMTP verification prove every mailbox exists?

No. Some providers block probes, greylist requests, or accept catch-all traffic. WillItInbox exposes evidence and confidence instead of pretending every result is absolute.

Should unknown emails be suppressed?

Not automatically. Unknown means inconclusive. If the result is pending, wait for the retry worker and download the latest CSV after the displayed recheck time. Otherwise, segment or send conservatively based on consent, campaign importance, and risk tolerance.