The free checks, and why an address failed them

POST /v1/check

curl -X POST https://api.sortance.com/v1/check \
  -H "Authorization: Bearer $SORTANCE_KEY" \
  -H "Content-Type: application/json" \
  -d '{"email":"test@mailinator.com"}'

An illustrative response:

{
  "email": "test@mailinator.com",
  "domain": "mailinator.com",
  "passes": false,
  "disposable": true,
  "suspected": false,
  "reason": "disposable_domain",
  "reasons": ["disposable_domain"],
  "checks": { "syntax": "pass", "mx": "pass", "disposable": "fail" },
  "esp": "self_hosted",
  "email_type": "disposable",
  "mx_hosts": ["mail.mailinator.com", "mail2.mailinator.com"],
  "mx_provider": "unknown",
  "latency_ms": 41,
  "trace_id": "ck_..."
}

• No verdict and no probability. Nothing here asks the mailbox, so the response does not claim to know whether it exists. passes means syntax is valid, the domain has mail servers, it is not a disposable domain and you have not blocked the domain or the address. Use /v1/verify when you need a bounce probability.
• Free. It does not count against your monthly quota. It shares the 600-a-minute rate limit of /v1/verify.
• Nothing is stored. No trace row and no cache entry. The ck_ trace id matches a log line if you ask support, and the log line carries no address and no domain.
• POST only. An address in a query string ends up in request logs. The same 4 KB body limit and address rules as /v1/verify apply.

Every field is listed in the API reference. The same object is returned by the MCP tool check_email, also free; see MCP server.

Reasons

reason is the first code that applies, in the order below, or null. reasons lists every code that applies, in the same order. The list is closed: a new code is added here before it can appear in a response.

On /v1/verify and in the verification embedded in /v1/decide, a code that ends the check means Sortance answered from the free gate: verdict invalid, the probability in the table, no provider called and no cost. When the paid providers drove the answer, reason is often null; the reason for that answer is in providers. Reasons are worked out again on every request, including cache hits, so one account’s domain rules never show up in another account’s answer.

The block and signal tiers are explained in domain validation, and your own rules, for domains and for single addresses, in Blocklists (address rules). On /v1/screen, address_blocklisted means review.

Email type

email_type says what kind of address it is, from the same facts the checks above use. It is one of six values, and when several apply the first in this order wins:

So info@gmail.com is role and jane@gmail.com is free. Broken syntax, and a domain that answered with no mail server, are unknown. Your own rules are part of it: a domain you block reads disposable, and a domain or address you allow is never disposable.

The type never changes the verdict or passes: a Gmail address delivers fine. To turn away free, role, relay or disposable addresses, use the Email types switches on the dashboard’s Policy screen, which act in /v1/decide (see email types in policies), or read email_type yourself. The SDK has isBusinessEmail and emailType for that (SDK).

Moving from the standalone email-check service

The email check is part of the Sortance API and is maintained by Sortance. The earlier standalone email-check service is being shut down, and its routes are not reproduced. Each one maps to a native endpoint below. Every call needs a Sortance key as a bearer token, and the address always goes in a POST body, never in a URL.

# Is this domain disposable? (replaces GET /get?id=)
curl -X POST https://api.sortance.com/v1/domains/check \
  -H "Authorization: Bearer $SORTANCE_KEY" \
  -H "Content-Type: application/json" \
  -d '{"domain":"mailinator.com"}'

# Block domains for your account (replaces POST /set?id=)
curl -X POST https://api.sortance.com/v1/domains/blocklist \
  -H "Authorization: Bearer $SORTANCE_KEY" \
  -H "Content-Type: application/json" \
  -d '{"domains":["new-burner.example"]}'