Skip to content

Accuracy

How RocketVerifier verifies emails with 99.5% accuracy

Every address goes through 7 layers of checks, ending in a live conversation with the mail server. No email is ever sent, and if a server will not give a clear answer, you are not charged.

Start free See the pipeline
  1. Syntax
  2. Domain and DNS
  3. MX records
  4. Disposable and role
  5. Catch-all analysis
  6. SMTP mailbox check
  7. Risk signals

The pipeline

7 checks, from format to mailbox

Cheap, certain checks run first, so the live mailbox check only runs when it is needed. Every step can stop an address and record exactly why.

  1. Step 1

    Syntax

    RFC-compliant format, typo detection and internationalised domains.

    Malformed addresses are rejected before any network call. Common typos in popular domains, such as gmial.com, come back with a did_you_mean suggestion so you can fix the address instead of losing it.

    Sub-statuses: invalid_syntaxpossible_typo

  2. Step 2

    Domain and DNS

    The domain exists and resolves.

    We resolve the domain to confirm it is registered and live. Expired and misspelled domains are caught here, long before a mail server is involved.

    Sub-statuses: invalid_domaindns_error

  3. Step 3

    MX records

    The domain is set up to receive mail.

    We look up the domain's mail exchangers and identify the provider behind them, such as google.com. A domain with no way to receive mail is marked undeliverable.

    Sub-statuses: does_not_accept_mail

  4. Step 4

    Disposable and role

    Throwaway domains and shared inboxes such as info@ and sales@.

    Throwaway domains are matched against a continuously updated database of tens of thousands of disposable providers. Shared inboxes such as info@ and sales@ are flagged so you can decide how to treat them.

    Sub-statuses: disposablerole_based

  5. Step 5

    Catch-all analysis

    Accept-all servers get a verdict: send safe, send with caution or avoid.

    Some servers accept mail for every address at the domain, so a simple check cannot tell real mailboxes from made-up ones. We detect this behaviour and give each address a verdict instead of a shrug.

    Sub-statuses: catch_all

  6. Step 6

    SMTP mailbox check

    A live handshake confirms the mailbox exists, without sending an email.

    We connect to the mail server and ask whether it will accept mail for this exact mailbox. The conversation ends before any message is sent.

    Sub-statuses: mailbox_not_foundmailbox_fullaccount_disabledgreylistedsmtp_timeout

  7. Step 7

    Risk signals

    Spam-trap patterns, toxic and do-not-mail addresses, and a 0 to 100 score.

    Finally, we look for spam-trap patterns and addresses known for complaints or abuse, then combine every signal into a 0 to 100 score.

    Sub-statuses: possible_traptoxicdo_not_mail

The SMTP handshake

Ask the mail server, without sending a message

The most reliable source of truth about a mailbox is the server that hosts it. We ask it directly.

Sending an email happens in stages. First the sender introduces itself, then names a recipient, and only then transfers the message. The receiving server answers each stage with a status code.

When we name the recipient, the server says whether it will accept mail for that mailbox. A 250 means yes. A 550 means the mailbox does not exist. Then we politely end the conversation, before any message is transferred.

The result comes from the same server that would receive your campaign, which is why it is so dependable. Nothing reaches the recipient's inbox.

Catch-all domains

A clear verdict for accept-all servers

Catch-all servers say yes to every address, so the handshake alone cannot separate a real person from a made-up one. Instead of leaving you guessing, every catch-all address gets a verdict.

  • send_safe

    Send safe

    Strong signals that the mailbox is real and active. Safe to include in your sends.

  • send_with_caution

    Send with caution

    Mixed signals. Send in smaller batches or to your most engaged segments first.

  • avoid

    Avoid

    Signals point to a mailbox that does not exist or will not engage. Leave it out.

Catch-all addresses carry the catch_all sub-status, and the verdict appears in catch_all_verdict. More on catch-all resolution

Greylisting, handled with patience

Some servers temporarily turn away any sender they do not recognise, expecting a genuine sender to try again later. A verifier that gives up at the first refusal reports good addresses as bad.

RocketVerifier retries greylisted addresses automatically, the way a real mail server would, so a temporary deferral does not become a wrong answer.

Unknown beats a wrong guess

Occasionally a server times out, blocks verification or never gives a clear answer. Guessing would inflate the share of deliverable results and send bounces your way.

We return those addresses as unknown, with the reason as the sub-status, and we never charge for them. You only pay for answers we can stand behind.

Infrastructure

Built for the mailbox check other verifiers get wrong

The live SMTP handshake is where accuracy is won or lost. Our verification network is engineered so mail servers keep giving it straight answers.

  • Dedicated verification IPs

    Every probing IP self-tests before it carries traffic: port 25 open, forward-confirmed reverse DNS, and a HELO name that matches. Probes come from a dedicated verification domain, never yours.

  • Automatic IP warm-up

    New IPs ramp through seven stages over about three weeks, move up only while blocklist checks stay clean, and step back automatically if one is listed.

  • Per-provider rate budgets

    Each IP has its own budget per receiving provider, with automatic back-off after a deferral, so Gmail, Outlook and Yahoo keep answering instead of blocking.

  • Provider-specific reply parsing

    Google, Microsoft, Yahoo, Mimecast, Proofpoint and Barracuda each word their SMTP replies differently. Each gets its own rules, so a policy block is never mistaken for a missing mailbox.

  • Greylisting handled for you

    Deferred addresses are retried automatically, up to three times about ten minutes apart, and a stalled bulk job is moved to another verification node.

  • Fresh data, cached smartly

    The disposable-domain list refreshes every day, MX lookups run once per domain per batch, and repeat checks are served from cache in milliseconds.

See it on your data

Measure accuracy on your own list

The best proof is your own bounce rate. Here is a simple way to check it.

  1. Verify a sample

    Pick a representative slice of your list, a few thousand addresses is plenty, and run it as a bulk job.

  2. Send to deliverable results

    Send your next campaign only to the addresses marked deliverable.

  3. Compare hard bounces

    Divide the hard bounces your sending platform reports by the number of deliverable addresses you sent to.

  4. Covered by the guarantee

    If more than 4% hard-bounce within 30 days, file a claim from the job page and get 1 credit back per bounce above 4%.

Start free with 100 free credits How the bounce guarantee works

FAQ

Accuracy questions, answered

How accurate is RocketVerifier?

RocketVerifier verifies email addresses with 99.5% accuracy. Every address runs through syntax, DNS and MX, disposable and role screening, catch-all analysis and a live SMTP handshake. Results we cannot confirm are returned as unknown and never charged.

Does RocketVerifier send an email to check an address?

No. The SMTP check opens a connection to the mail server, asks whether it would accept mail for the address, and closes the connection before any message is sent. The recipient never sees anything.

Why do some results come back as unknown?

Some mail servers time out, rate-limit verification or refuse to give a clear answer. Rather than guess and risk a wrong result, we return unknown. Unknown results are never charged, so you only pay for answers.

How do you handle catch-all domains?

A catch-all server accepts mail for any address at the domain, so the mailbox check alone cannot confirm a person. RocketVerifier detects catch-all behaviour and adds a catch_all_verdict of send_safe, send_with_caution or avoid, so you can decide what to send.

What is greylisting and how do you deal with it?

Greylisting is when a mail server temporarily turns away a sender it does not recognise and expects a retry later. RocketVerifier retries automatically. If the server still will not answer, the result is returned as unknown with the greylisted sub-status and is not charged.

How can I check accuracy on my own list?

Verify a sample, send only to the deliverable results, then compare hard bounces with the number of addresses you sent to. Connect SendGrid, Mailgun, Amazon SES or Postmark and every hard bounce of an address a job marked deliverable is refunded automatically within 30 days, 1 credit each, with no claim to file. Not connected? If more than 4% of a job's deliverable addresses hard-bounce within 30 days, file a claim from the job page and get 1 credit back for every bounce above 4%.

Can results change over time?

Yes. Mailboxes are created and closed every day, so a result reflects the moment it was checked. Every result includes a verified_at timestamp, and re-verifying lists before large sends keeps them accurate.

See the accuracy for yourself

Verify a sample of your list and compare the results with your next send. Unknown results are always free.

Start free See pricing

100 free credits · No card required · Credits never expire