What's new in RocketVerifier

You can now pin how the API maps results to statuses by sending a RocketVerifier-Version header:

curl -X POST https://api.rocketverifier.com/v1/verify \
  -H "Authorization: Bearer $RV_API_KEY" \
  -H "RocketVerifier-Version: 2026-11-01" \
  -H "Content-Type: application/json" \
  -d '{"email": "jane.doe@acme-corp.com"}'

Version	Catch-all addresses are returned as
2026-11-01	risky, with sub_status: catch_all and a catch_all_verdict
2025-01-01	unknown, as before

The catch-all mailbox exists and accepts mail, so 2026-11-01 treats it as a real answer you can act on, with a verdict to guide the send.

Defaults

• API keys created from 1 November 2026 default to 2026-11-01.
• Existing keys keep 2025-01-01 until you send the header or update the key’s version setting.
• The dashboard always uses the current version.

Every other field and status is the same in both versions.

Knowing that an address is risky or undeliverable is useful. Knowing exactly why is better. Every result now explains itself in more detail.

sub_status on every result

A new sub_status field gives the precise reason behind the status. It is returned by POST /v1/verify, GET /v1/jobs/{id}/results and job downloads (as a CSV column and a JSON field):

mailbox_not_found, account_disabled, mailbox_full, does_not_accept_mail, invalid_syntax, invalid_domain, dns_error, greylisted, blocked, smtp_timeout, no_connect, smtp_unavailable, catch_all, role_based, disposable, possible_trap, toxic, do_not_mail, possible_typo, alias and none.

A verdict for catch-all addresses

catch_all_verdict tells you what to do with an address on a domain that accepts all mail: send_safe, send_with_caution or avoid. It is null for every other domain. A new catch_all object adds the score, the method used and up to five reasons. How catch-all resolution works.

More detail on every result

• verified_at: when the result was produced, in ISO 8601 UTC, on single results and job rows.
• verdict_source: whether the verdict came from SMTP, DNS, syntax, a list match or an earlier result.
• retry_after: on unknown results, how many seconds to wait before retrying.
• smtp_provider, gateway, mx_found and mx_record: the mailbox provider, any security gateway in front of it, and the primary mail server.

Related changes

• reason is now derived from sub_status. A 5.1.1 rejection is reported as rejected_email, and the new values blocked, timeout, toxic, suppressed and unknown can appear.
• Addresses on your suppression list are returned as risky with sub_status: do_not_mail.

All new fields are additive. Existing fields keep their names and meaning.

An address marked undeliverable gets removed from your list, so that answer has to be right. This release makes RocketVerifier stricter about when it says so.

Smarter reading of mail server replies

• If a server also rejects postmaster@, which every mail domain must accept, its rejections are reported as unknown rather than undeliverable.
• A bare 550 with no reason is unknown, unless it is identical to the reply for an address that cannot exist. Then it is undeliverable with sub_status: mailbox_not_found.
• Policy, blocklist and reputation rejections are unknown with sub_status: blocked, never undeliverable.
• Accepts from a third-party backup mail server are only trusted after an accept-all check on that server.

Better DNS handling

• Temporary DNS failures and timeouts are unknown with sub_status: dns_error instead of invalid_domain.
• Domains with no MX record but a valid A or AAAA record are verified, as mail servers would deliver to them.
• Domains that publish a null MX are undeliverable with sub_status: does_not_accept_mail.

More honest answers

• Addresses whose mail server blocked, greylisted or timed out the check are now unknown instead of deliverable or risky, including on Google Workspace and Microsoft 365.
• Common names and department addresses such as assistant@ and claims@ are no longer flagged as toxic.
• Typo suggestions no longer “correct” domains that really receive mail, such as company.co.

unknown results, and addresses on your own suppression list, are never charged.

You can now lock each API key down to exactly what it needs. Set these controls from API keys in the dashboard.

Monthly spend caps

Give a key a monthly credit limit, counted per UTC calendar month. A request that would go over the limit is rejected with 402 api_key_spend_cap_reached, and the error details include monthly_limit, used_this_month and required. Refunds for unknown results and failed or cancelled jobs give the quota back.

Expiry dates

Keys can expire on a date you choose. An expired key is rejected with 401 api_key_expired, so temporary keys for contractors, tests or one-off migrations clean themselves up.

Organization keys and IP allowlists

Organization API keys spend the organization’s pooled credits when credit pooling is on, share one rate limit for the organization, and only accept requests from the organization’s IP allowlist when one is set. Requests from any other address get 403 ip_not_allowed.

Switching to RocketVerifier no longer means rebuilding the spreadsheets, formulas and import rules that expect another provider’s columns. Add the columns parameter when you download a completed job:

curl "https://api.rocketverifier.com/v1/jobs/$JOB_ID/download?columns=zerobounce" \
  -H "Authorization: Bearer $RV_API_KEY" -o results.csv

• Supported layouts: zerobounce, bouncer and kickbox.
• Each RocketVerifier result is mapped to the closest equivalent value in that layout.
• Leave out columns to keep the standard RocketVerifier layout, which is unchanged.

Addresses on internationalised domain names (IDNs), such as info@bücher.de, are now fully verified: DNS, MX records, catch-all analysis and the live SMTP mailbox check all run as they do for any other domain.

The domain is checked in its ASCII form (xn--bcher-kva.de), which is exactly what mail servers see, so the result reflects real deliverability.

• Works in the dashboard, bulk uploads and the API.
• No changes are needed on your side.
• The part before the @ must still use ASCII characters. Addresses with non-ASCII characters there are returned as undeliverable with sub_status: invalid_syntax.