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.
The honest limitation, on our platform as on most, is that verification runs per contact today. Cleaning a whole list before a campaign still means an export, and the workaround is hitting the API by hand. George, our CEO, calls that out as a real deliverability blocker for users, and he is right.
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 we explicitly document as bypassing warmup, CAN-SPAM footers, List-Unsubscribe, and tracking. 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, I stack the checks. Before one recovery send I 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.
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.