How deliverability is determined
Deliverability scored separately from risk
A perfectly deliverable address on a disposable domain is still high risk — the two are never conflated.
MX / SPF / DMARC health
The domain-level signals that indicate actively maintained mail infrastructure.
Live SMTP mailbox confirmation
A real RCPT TO handshake, stopping before DATA — no message is ever sent.
Catch-all domain detection
A second RCPT TO probe against a random address on the same domain, in the same SMTP session.
Honest "unknown" results
When the mail server's response doesn't confirm anything, the API says so — never a guessed pass or fail.
Example request
curl https://api.emailriskradar.com/v1/email/check \
-H "Authorization: Bearer $API_KEY" \
-H "Content-Type: application/json" \
-d '{"email": "user@example.com", "mode": "full"}'FAQ
Partially. Syntax, domain, MX, SPF/DMARC, and SMTP RCPT TO probing all run without sending a message — but full certainty in every case generally requires a confirmation click or an actual send.
It means the check couldn't reach a confident answer — a catch-all domain, an ambiguous SMTP response, or a timeout. It's genuinely undetermined, not a soft pass.
SMTP acceptance at check time isn't a permanent guarantee — mailboxes get deleted, quotas fill up, and some servers accept everything up front and filter afterward.
No — a disposable-domain address can be perfectly deliverable and still high risk. See the Email Risk API for how the two are scored independently.