Email Verification in Rust: Building a High-Throughput Validation Pipeline

Why Rust for Email Verification Pipelines

When you need to verify millions of email addresses, the choice of language matters. Rust offers a combination of raw performance, memory safety, and first-class async support that makes it particularly well-suited for high-throughput I/O-bound workloads like API-driven email verification. There is no garbage collector pausing your threads mid-request. There is no runtime overhead eating into your throughput ceiling. What you write is what runs.

This guide walks through integrating the EmailVerifierAPI v2 endpoint into a Rust application, starting with a basic single-request example and building up to a concurrent batch processing pipeline suitable for production workloads.

Prerequisites

Before starting, ensure your Rust environment includes Tokio for async runtime, reqwest for HTTP requests, and serde for JSON deserialization. Add the following to your Cargo.toml dependencies:

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

Testing with cURL

Before writing Rust code, confirm your API key works with a direct cURL request against the v2 endpoint:

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

A successful response returns a JSON object with the verification result:

{
  "status": "passed",
  "isDisposable": false,
  "isFreeService": true,
  "isOffensive": false,
  "isRoleAccount": false,
  "isGibberish": false,
  "smtp_check": "success",
  "sub_status": "mailboxExists"
}

Defining Response Types

Rust's type system is one of its greatest strengths for API integrations. Define a struct that maps to the EmailVerifierAPI response, and let serde handle deserialization automatically:

use serde::Deserialize;

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

pub async fn verify_email(
    client: &reqwest::Client,
    email: &str,
    api_key: &str,
) -> Result<VerificationResult, reqwest::Error> {
    let url = format!(
        "https://www.emailverifierapi.com/v2/verify?email={}&apikey={}",
        email, api_key
    );
    let response = client.get(&url).send().await?.json::<VerificationResult>().await?;
    Ok(response)
}

Concurrent Batch Processing

For high-volume workloads, you need to process many addresses concurrently while respecting rate limits. Tokio's semaphore primitive gives you precise control over concurrency. The following example processes a list of emails with a configurable concurrency limit:

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

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

    let tasks: Vec<_> = emails
        .into_iter()
        .map(|email| {
            let client = client.clone();
            let sem = semaphore.clone();
            let key = api_key.clone();
            tokio::spawn(async move {
                let _permit = sem.acquire().await.unwrap();
                let result = verify_email(&client, &email, &key)
                    .await
                    .map_err(|e| e.to_string());
                (email, result)
            })
        })
        .collect();

    let mut results = Vec::new();
    for task in tasks {
        if let Ok(result) = task.await {
            results.push(result);
        }
    }
    results
}

#[tokio::main]
async fn main() {
    let emails = vec![
        "user@example.com".to_string(),
        "test@tempmail.org".to_string(),
        "info@company.com".to_string(),
    ];
    let results = verify_batch(emails, "YOUR_API_KEY", 10).await;

    for (email, result) in results {
        match result {
            Ok(v) => println!("{}: {} ({})
", email, v.status, v.sub_status),
            Err(e) => eprintln!("{}: error - {}", email, e),
        }
    }
}

Understanding the Response Fields

Each response from the API includes a primary status ("passed", "failed", "unknown", or "transient") and several boolean flags that provide additional context. The "status" field is your primary routing decision. Addresses that return "passed" are safe to send to. Those that return "failed" should be suppressed immediately. The "unknown" status indicates the verification was inconclusive, typically due to a catch-all server or temporary connectivity issue. The "transient" status means the target server returned a temporary error and the address should be re-verified later.

The boolean flags add depth to your decision-making. An address might return "passed" (the mailbox exists) but also flag "isDisposable" as true, indicating it is a throwaway address. Depending on your use case, you may want to treat a valid-but-disposable address differently from a valid-and-permanent one. Similarly, "isRoleAccount" identifies addresses like sales@ or support@ that are unlikely to represent an individual, which matters for B2B prospecting and personalized marketing.

The "sub_status" field provides the most granular detail. Values like "mailboxExists" and "mailboxDoesNotExist" are self-explanatory. "isCatchall" tells you the domain accepts all mail, so the mailbox-level verification is inconclusive. "isGreylisting" means the server temporarily rejected the probe, and re-verification after a delay is recommended.

Production Considerations

For production deployments, add retry logic for transient failures using exponential backoff. Set the concurrency limit based on your API plan's rate allowance. Log all results with timestamps for audit trails and debugging. Consider writing results to a database or message queue rather than holding them all in memory, especially for batches exceeding 100,000 addresses.

Rust's ownership model and error handling ensure that your pipeline handles failures gracefully without leaking connections or corrupting state. Combined with EmailVerifierAPI's fast response times and detailed result data, this creates a verification pipeline that can process large volumes reliably and efficiently.

Frequently Asked Questions

What concurrency level should I use for batch verification in Rust?

Start with 10 concurrent requests and increase gradually while monitoring response times and error rates. Your optimal concurrency depends on your API plan's rate limits. The semaphore pattern shown above makes it easy to tune this value without changing your code structure.

How do I handle rate limiting from the API?

If you receive HTTP 429 (Too Many Requests) responses, implement exponential backoff with jitter. Reduce your semaphore concurrency and add a delay between retries. In Rust, the tokio::time::sleep function combined with a retry counter provides a clean implementation for this pattern.

Should I use reqwest or hyper for the HTTP client?

For most use cases, reqwest is the better choice. It provides a high-level API with built-in JSON support, connection pooling, and TLS handling. Hyper is the lower-level HTTP library that reqwest is built on. You would only need hyper directly if you require custom protocol handling or are building an HTTP framework, not consuming a REST API.