Email Verification in Rust: Building a High-Performance Validation Client with Reqwest

Why Rust for Email Verification

Rust is increasingly the language of choice for backend services that demand both performance and reliability. Its ownership model eliminates data races at compile time, and its async ecosystem (powered by Tokio) enables high-concurrency I/O without the overhead of garbage collection or green thread runtimes.

For email verification workloads, these properties translate directly to practical advantages. A Rust verification client can process thousands of addresses concurrently with **predictable memory usage and zero runtime panics** from null pointer exceptions or race conditions that plague equivalent implementations in other languages.

This guide walks through building a production-ready verification client using reqwest for HTTP, serde for JSON deserialization, and tokio for async execution. By the end, you will have a client that handles single verifications, batch processing, and structured error management.

Testing the API with cURL First

Before writing any Rust code, verify your API key and understand the response format with a quick cURL call:

curl "https://emailverifierapi.com/v2/verify?apikey=YOUR_API_KEY&email=test@example.com"

The response JSON includes fields like status, isDisposable, isFreeService, isRoleAccount, isGibberish, smtp_check, and sub_status. Each of these maps directly to the Rust struct we will define next.

Project Setup and Dependencies

Start by creating a new Rust project and adding the required dependencies to your Cargo.toml:

[dependencies]
reqwest = { version = "0.12", features = ["json"] }
serde = { version = "1", features = ["derive"] }
serde_json = "1"
tokio = { version = "1", features = ["full"] }

Defining the Response Types

The email verifier API endpoints return a JSON response with verification status, flags for disposable and role accounts, and SMTP check results. Define a Rust struct that maps directly to this response:

use serde::Deserialize;

#[derive(Debug, Deserialize)]
#[serde(rename_all = "camelCase")]
pub struct VerifyResponse {
    pub status: String,
    pub is_disposable: bool,
    pub is_free_service: bool,
    pub is_role_account: bool,
    pub is_gibberish: bool,
    pub smtp_check: String,
    pub sub_status: String,
}

The #[serde(rename_all = "camelCase")] attribute handles the conversion between the API's camelCase JSON fields and Rust's snake_case conventions automatically. This is one of the advantages of Rust's type system: the compiler ensures you handle every field correctly.

Building the Verification Client

Next, create an async function that calls the EmailVerifierAPI v2 endpoint. Here is a complete single-address verification with proper error handling:

use reqwest::Client;

const API_URL: &str = "https://emailverifierapi.com/v2/verify";

pub async fn verify_email(
    client: &Client,
    api_key: &str,
    email: &str,
) -> Result<VerifyResponse, reqwest::Error> {
    let response = client
        .get(API_URL)
        .query(&[("apikey", api_key), ("email", email)])
        .send()
        .await?
        .json::<VerifyResponse>()
        .await?;

    Ok(response)
}

#[tokio::main]
async fn main() {
    let client = Client::new();
    let api_key = "YOUR_API_KEY";

    match verify_email(&client, api_key, "test@example.com").await {
        Ok(result) => {
            println!("Status: {}", result.status);
            println!("Disposable: {}", result.is_disposable);
            println!("SMTP: {}", result.smtp_check);
            println!("Sub-status: {}", result.sub_status);
        }
        Err(e) => eprintln!("Verification failed: {}", e),
    }
}

The reqwest::Client maintains a connection pool internally, so reuse the same client instance across all verification calls rather than creating a new one per request.

Batch Verification with Controlled Concurrency

For verifying large lists, spawn concurrent tasks with a semaphore to control parallelism. This prevents overwhelming the API while maximizing throughput:

use std::sync::Arc;
use tokio::sync::Semaphore;

pub async fn verify_batch(
    client: &Client,
    api_key: &str,
    emails: Vec<String>,
    max_concurrent: usize,
) -> Vec<(String, Result<VerifyResponse, String>)> {
    let semaphore = Arc::new(Semaphore::new(max_concurrent));
    let client = Arc::new(client.clone());
    let api_key = Arc::new(api_key.to_string());

    let mut handles = Vec::new();

    for email in emails {
        let sem = semaphore.clone();
        let cl = client.clone();
        let key = api_key.clone();

        handles.push(tokio::spawn(async move {
            let _permit = sem.acquire().await.unwrap();
            let result = verify_email(&cl, &key, &email)
                .await
                .map_err(|e| e.to_string());
            (email, result)
        }));
    }

    let mut results = Vec::new();
    for handle in handles {
        if let Ok(r) = handle.await {
            results.push(r);
        }
    }
    results
}

Set max_concurrent to a value that respects your API plan's rate limits. A value of **10-20 concurrent requests** provides excellent throughput for most use cases without triggering rate limiting.

Interpreting the Verification Response

The status field returns one of four values: passed (valid, safe to send), failed (invalid, do not send), unknown (could not determine, treat with caution), or transient (temporary issue, retry later). Build your application logic around these statuses:

• passed: Add to your verified sending list.
• failed: Remove from your list. Check sub_status for the specific reason (e.g., mailboxDoesNotExist, domainDoesNotExist).
• unknown: Quarantine and retry after 24 hours. Some servers are temporarily unreachable.
• transient: Retry with exponential backoff. The receiving server is experiencing a temporary issue.

The boolean flags (is_disposable, is_role_account, is_gibberish) provide additional filtering criteria beyond the primary status. Even a "passed" address might be a disposable inbox you want to block from signups.

For production systems, consider wrapping the verification result in a domain-specific enum rather than matching on raw strings. This pushes invalid state handling to compile time and makes your verification logic easier to test and maintain as the API evolves.

If you need to verify addresses across multiple languages or platforms beyond Rust, the email verification integrations hub provides client examples for over a dozen languages. The same v2 endpoint and response format apply regardless of which client you use, so the struct definitions and status handling logic from this guide translate directly.

For the complete API reference and additional response fields, see the real-time email validation API documentation. For more Rust-specific patterns, visit the email verification in Rust integration page. To test your implementation with complimentary credits, try email verification free with 100 credits on signup.

Frequently Asked Questions

What Rust version is required for this implementation?

This code requires Rust 1.75 or later for stable async trait support. The reqwest 0.12 and tokio 1.x crates are compatible with any recent stable Rust toolchain. Run rustup update stable to ensure you are on the latest version.

How do I handle API rate limits in the batch verification function?

The semaphore-based approach controls concurrency, but you should also implement retry logic with exponential backoff for HTTP 429 (Too Many Requests) responses. Add a match on the response status code before deserializing, and sleep with tokio::time::sleep before retrying.

Can I use this client in a web server like Axum or Actix?

Yes. Create the reqwest::Client once during server initialization and share it across handlers using Axum's State extractor or Actix's web::Data. The client is designed to be cloned cheaply and used concurrently from multiple tasks.

What is the typical response time for a single verification call?

Most verification requests complete in 200-800 milliseconds, depending on the target mail server's response time. The API performs real-time SMTP checks, so response times vary by destination domain. Factor this into your timeout configuration by setting a reasonable timeout (e.g., 10 seconds) on the reqwest client builder.