What one check call covers
Sent to a dead address, an email doesn't just fail, it testifies against you: every hard bounce tells mailbox providers you don't know your own list. A check API runs the layers before that happens: syntax, then MX records on the domain, then whether the mailbox itself exists and accepts, then disposable and role-address flags.
We run those layers against ourselves before we run them for anyone else. Malformed domains are rejected before our domain verifier ever calls provider setup. The syntax layer sounds trivial until you meet production data: we once had contacts arriving through our own API with a blank email address, and nothing downstream can rescue that. The DNS layer holds surprises too. Our record validator once reported a managed sending domain's records as missing when they existed, because a Cloudflare proxy flattens delegation CNAMEs to A records and the CNAME lookup came back blank. A failed DNS check is a symptom to inspect, not a verdict.
Two more things we hold ourselves to. A check that passes is a bounded claim: verified means the DNS records are valid, not allowed to send right now. And the MX layer earns its keep outside email. In our own lead grading, a domain with no MX records grades the lead invalid before anyone wastes a call on it.
Explicit validation operations
Nitrosend validates an exact audience as a durable prepaid operation. Quote it without mutation, inspect the maximum charge, then start it with an idempotency key. Choose exactly one audience selector: contact channel IDs, contact IDs, a list, or a segment. Contact-profile enrichment is separate, and when we shipped it we deliberately scoped it to go-forward contacts only, keeping backfill of existing unenriched contacts out.
curl -X POST https://api.nitrosend.com/v1/my/validation_operations/quote \ -H "Authorization: Bearer $NITROSEND_API_KEY" \ -H "Content-Type: application/json" \ -d '{"contact_channel_ids": [123]}' curl -X POST https://api.nitrosend.com/v1/my/validation_operations \ -H "Authorization: Bearer $NITROSEND_API_KEY" \ -H "Content-Type: application/json" \ -H "Idempotency-Key: validation-channel-123" \ -d '{"contact_channel_ids": [123]}' → { "operation_id": "...", "status": "held" }
Poll GET /v1/my/validation_operations/{id} for durable state and GET /v1/my/validation_operations/{id}/items for per-candidate results. Nitrosend does not trigger paid validation automatically on signup, import, schedule, or send, and no plan includes an allowance. If your product needs validation at signup, call this operation explicitly.
Verification is not limited to one contact at a time. In Contacts, Verify list runs a whole audience through the verifier after you review the maximum prepaid charge, and it never runs automatically during import, scheduling or sending.
Signup is also where we check ourselves. After a bot wave hit our own signup form with disposable-domain addresses, we hardened the gate with a curated blocklist, subdomain-aware matching, and closed the side doors the bots were routing through. And every brand-new account's first multi-recipient campaign without a verified sending domain lands in a manual review queue before it goes anywhere. That synchronous gate is narrow by design: out-of-scope brands and send-from-your-own-lookalike phishing still pass it, and comprehensive recall belongs to a separate AI content-risk review layer. The checks we sell are the checks we live behind.
The gate exists because abuse buys accounts. One spammer signed up for a paid plan and pushed mail through our transactional send API, the path that skips CAN-SPAM footers and List-Unsubscribe because it assumes event-triggered mail to one recipient. Validation has to assume a paying customer can still be hostile. The infrastructure under it is locked the same way: TCP 2525 is firewall-restricted to our API host, TLS and exact SMTP authentication are mandatory, and every one-recipient route snapshot is HMAC-signed, with unsigned or replayed requests rejected.
When the send really matters, stack the checks. Before one recovery send, George Hartley, our CEO, filtered on prior-blacklist flags, plus the full suppression list, plus verification-valid, plus a real engagement signal, and only then let the send go. Belt, braces, and a second belt. That send recovered the domain's reputation.
Checking the recipient is half the job. The sender address deserves the same treatment: when a from_email is set on a template, a flow, or a brand sender config, check it against the account's verified domains at save time and warn on a mismatch. The cheapest place to catch a bad sender is before anything sends.
Full parameters and responses live in the REST API docs and the API reference.
Explicit operations, idempotency keys, per-candidate polling: all of that assumes a developer is calling the API directly. Increasingly it's an agent doing the calling, reading your list, quoting the operation, and asking you to approve the charge before it runs. That's why Nitrosend is a listed app in the ChatGPT app marketplace rather than just an endpoint with a price per check.
Go deeper
Why the bounce math is unforgiving: the email validation API guide, with the 22.8%-to-0.20% story. Security side: API-based email security. A clean list is the shortest path to a low bounce rate, and it keeps you clear of blacklist monitoring.
FAQ
What is an email check API?
An API that verifies an address can receive mail before you send: syntax, domain MX records, mailbox existence, and disposable/role detection. It keeps hard bounces, and the reputation damage they cause, out of your sending.
When should I check email addresses?
At signup (catch typos live), on any list import (old lists decay), and periodically as hygiene. Checking at the moment of capture is worth the most: the user is still there to fix the typo.