Email Deliverability Check API: Handling Deliverable and Undeliverable Outcomes

Integrate the Email Deliverability Check API to distinguish deliverable and undeliverable addresses from undetermined catch-all domains across synchronous and bulk workflows.

EmailCheckPro provides an email deliverability check API that determines whether an address is deliverable (able to receive mail) or undeliverable at check time. A deliverable verdict indicates the address can accept messages when checked, whereas an undeliverable verdict identifies an address unable to receive mail. The service evaluates addresses across virtually any domain without dispatching messages to target recipients. By integrating real-time and bulk API workflows, engineering teams can separate active recipient addresses from undeliverable records and undetermined catch-all domains, improving transmission quality while maintaining data hygiene across ingestion systems.

Core Deliverability Verdicts and Operational Scope

Evaluating recipient addresses requires clear distinctions between deliverable, undeliverable, and undetermined outcomes.

A deliverable verdict confirms that the recipient address was reachable and prepared to receive mail when verified. Conversely, an undeliverable outcome indicates that the address is unable to receive messages. Both verdicts represent completed verification results.

Deliverability assessments provide point-in-time reachability signals rather than persistent guarantees. Development teams use these signals to remove dead addresses from communication queues, helping protect infrastructure performance while respecting European data minimization principles under GDPR Article 5 (Regulation (EU) 2016/679).

Synchronous Integration for Single and Batch Checks

Applications capturing contact data at sign-up or profile updates require rapid, synchronous evaluation. EmailCheckPro provides two dedicated real-time endpoints for interactive workflows.

For individual submissions, developers query POST /api/v1/check with a single complete address.

When handling small batches of user inputs, POST /api/v1/batch-check processes 1 to 100 addresses synchronously within a single HTTP request. The multi-check response maintains the exact sequence of the input list. Each record includes an exists property alongside verification details. In this schema, exists=false indicates that the service generated no completed result for that entry, rather than an undeliverable verdict. This distinction allows ingestion systems to retry transient issues while safely filtering confirmed undeliverable entries.

Asynchronous Bulk Tasks for List Processing

Maintaining large database archives requires an asynchronous processing architecture. When auditing contact stores, systems submit verification jobs via POST /api/v1/bulk-tasks.

Bulk submissions accept structured TXT or CSV files containing one complete email address per line. During file intake, the platform automatically removes duplicate lines and malformed entries, preparing a clean task. Documented count limits apply per product; teams should review the official documentation for current task limits.

Because bulk jobs execute asynchronously, applications monitor progress using GET /api/v1/bulk-tasks/{id}. Client workflows should poll this endpoint no more frequently than once every 30 seconds. Once processing completes, the endpoint provides a result_url linking to a CSV file containing each identifier and its activated outcome. The generated download link remains valid for 12 hours and refreshes whenever querying that task status again.

Handling Undetermined Catch-Alls and Formatting Exceptions

Reliable data quality pipelines must differentiate between explicit deliverability failures and ambiguous or malformed inputs.

Under RFC 5322: Internet Message Format, an email address consists of a local part and domain joined by an @ symbol. If an incoming entry lacks this structure, the API treats the payload as an invalid format. An invalid format remains distinct from an undeliverable verdict, representing a structural syntax failure.

Catch-all mail servers present another operational category. These domains accept messages addressed to any arbitrary local username, preventing the verification engine from definitively isolating valid mailboxes. Rather than guessing, EmailCheckPro marks catch-all configurations as undetermined. In real-time verification, catch-all domains return status code 42200 with no completed result. Undetermined, invalid, and failed checks incur no charges, allowing teams to route catch-all records to separate review queues.

FAQ

What distinguishes an undeliverable verdict from an undetermined result?

Real-time checks for catch-all domains return status code 42200 without a completed verdict, leaving these addresses unbilled and available for separate review policies.

How do multi-check API requests differ from asynchronous bulk tasks?

Multi-check calls use POST /api/v1/batch-check to validate 1 to 100 addresses synchronously, returning results directly within the HTTP response while preserving input order. Asynchronous bulk tasks use POST /api/v1/bulk-tasks to process large TXT or CSV lists. Bulk tasks run offline, require polling GET /api/v1/bulk-tasks/{id} at 30-second intervals, and output a downloadable CSV via result_url valid for 12 hours.

Learn More

Choose the product information that fits the next step in your workflow.

• View the product documentation →
• Talk to the team →