How email verification works, step by step.

Email delivery uses SMTP, a conversation between two servers. The sending side says hello, names the sender with MAIL FROM, then names each recipient with RCPT TO. The receiving server replies to each line with a code. A 250 reply to RCPT TO means "I will accept mail for this person". A 550 reply usually means "no such user".

A verifier walks through that conversation up to the recipient line, reads the reply, and then quits before the DATA step where the message body would go. Nothing is delivered and nobody receives anything. This is the only way to learn about a specific mailbox from the outside, and it depends entirely on the receiving server answering honestly.

Disposable domains hand out temporary inboxes that expire after minutes or days. People use them to get past sign-up forms. The address may be valid today and dead tomorrow, so it is worth flagging even when the mailbox exists.

Role accounts are addresses for a function rather than a person: info@, sales@, admin@, support@. They often reach several people, or a ticket queue. They are real, but they behave differently from a personal inbox, and some senders keep them out of marketing lists.

Free providers such as large webmail services tell you the address is personal rather than tied to a company domain. That matters for B2B work even when the mailbox is fine.

Greylisting is an anti-spam technique. When a server sees a new sender for the first time, it replies with a temporary failure (a 4xx code) and asks it to try again later. Real mail servers retry after a few minutes and get through. Many spam tools never retry, so they are filtered out cheaply.

For a verifier, a temporary failure is not an answer. The mailbox might exist or not. Retrying later can help, but some servers keep deferring, and some rate-limit or block connections that look like probing. Large mailbox providers often accept every recipient at the SMTP stage and decide later, which makes the check uninformative there too.

Because sometimes the server will not say. Timeouts, greylisting, blocked connections and providers that accept everything all end in the same place: the mailbox was not confirmed either way. A verifier can either admit that, or guess.

Ravn admits it. validate_email returns one of four statuses: valid, invalid, risky or unknown. It also reports mailbox_checked, so you can see whether the SMTP step ran. The mailbox check runs only where it is enabled, and if the mailbox was not checked the result is never valid. A risk_score from A to F summarises everything in one grade, and reason says why, for example mailbox_exists, mailbox_not_found or domain_accepts_mail.

A practical rule: send to valid with grade A or B, drop invalid, and handle risky and unknown by reason. The list verification playbook walks through it, and the email verification API page documents every field.

Not forever. People leave jobs, companies close mailboxes and domains lapse. A result describes the address on the day it was checked. Re-verify before a large send if the list has been sitting for a few months. Each check uses one lookup, and a miss is free. You can try single addresses at no cost with the free email verifier.