Email verification results usually fall into four groups. Valid means the address passed every check and is safe to mail. Invalid means it can’t receive email, so remove it. Risky means it can probably receive mail but carries a known problem, such as a catch-all domain, a disposable inbox, or a role address like info@. Unknown means the verifier couldn’t get a clear answer, usually because the mail server timed out or deliberately refused to say. The labels differ between tools, but the decisions behind them are the same.

This guide explains each status, the signals that typically produce it, and what to do with the addresses in each bucket.

The four main email verification results at a glance

Result	What it means	Typical action
Valid	Format, domain, and (if checked) mailbox all look good	Send normally
Invalid	Address can’t receive mail	Remove or suppress
Risky	Deliverable but with a known risk factor	Decide by sub-status and use case
Unknown	No clear answer from the mail server	Re-check later or send cautiously in a small batch

Most tools also attach a sub-status or reason, such as mailbox_not_found, no_mx, disposable, role_based, or accept_all. The sub-status matters more than the headline, because two “risky” addresses can need opposite treatment.

Valid

A valid result means the address passed every check the tool runs. For a DNS-level verifier that means correct syntax, a real domain, working MX records, and no disposable, role, or typo flags. For a tool that also runs SMTP checks, it additionally means the mail server accepted the recipient during a RCPT TO test.

Keep two caveats in mind:

Valid isn’t a delivery guarantee. A server that accepted the recipient during verification can still reject your actual message for authentication or reputation reasons.
Valid is a snapshot. The mailbox existed when it was checked. People change jobs and abandon inboxes, so a valid result from six months ago is weaker than one from yesterday.

What to do: Mail it. Keep processing bounces as usual.

Invalid

An invalid result means the verifier found a definite reason the address can’t receive mail. Common sub-statuses:

Syntax error

The address breaks basic format rules: missing @, spaces, consecutive dots, or a length beyond the limits in RFC 5321 (64 octets for the local part) and RFC 3696 erratum 1690 (254 characters overall).

Domain doesn’t exist

DNS returns NXDOMAIN. The company may have shut down, rebranded, or let the domain lapse, or the domain was mistyped.

No mail server / null MX

The domain exists but has no way to receive mail. A special case is the null MX record from RFC 7505, which looks like this:

example.org.   IN MX 0 .

That’s an explicit “this domain accepts no email.” RFC 7505 says servers rejecting mail for this reason should use reply code 556 with enhanced status code 5.1.10.

Mailbox not found

Only tools that run SMTP checks can produce this. The server answered RCPT TO with a permanent rejection like:

550 5.1.1 The email account that you tried to reach does not exist.

RFC 3463 defines X.1.1 as “bad destination mailbox address,” and Google uses that code in its Gmail SMTP error list for accounts that don’t exist.

Mailbox disabled

Some servers distinguish a deleted mailbox from a disabled one. Gmail uses 550 5.2.1 for an inactive account. RFC 3463 notes that X.2.1 can be permanent or temporary depending on whether the mailbox will be re-enabled, but in practice, treat it as invalid.

What to do with invalid addresses: Remove them from active sending and add them to your suppression list so they don’t sneak back in through a later import. If the address came from a form, and the reason is syntax or a typo, ask the person to correct it. Our post on what belongs on a suppression list covers retention and re-import rules.

Risky

“Risky” is the catch-all bucket for addresses that can likely receive mail but come with a known problem. The right action depends entirely on the sub-status.

Accept-all (catch-all) domain

The domain’s mail server accepts every recipient during SMTP, so there’s no way to tell jane@ from nobody-here@. Many corporate domains work this way. The address may be perfectly real, or mail to it may be silently discarded or bounced later. See how to handle catch-all domains.

What to do: For marketing to opted-in subscribers, these are usually fine. For cold outreach or a list of unknown origin, send them in smaller batches separate from your verified segment and watch bounces closely.

Disposable or temporary

The domain belongs to a throwaway inbox service. The address may work right now and disappear within hours.

What to do: Block these at signup if you’re offering trials, coupons, or anything people might abuse. On an existing list, they’re almost never worth mailing. Learn more in what a disposable email address is.

Role-based

The local part is a function name like info, sales, support, admin, or billing. Several of these names are standardized in RFC 2142. These inboxes are usually real and monitored, but they’re shared by several people, many of whom never signed up for anything.

What to do: Accept them on contact forms and for transactional mail. For marketing, keep them only if they clearly opted in. Twilio SendGrid’s validation API, for comparison, returns role addresses as “Risky” rather than invalid. Our post on role-based email addresses explains the trade-offs.

Mailbox full

The server reported the mailbox is over quota. Gmail, per its SMTP error reference, uses 452 4.2.2 when an inbox is out of storage, and 552 5.2.2 when it’s out of storage and inactive. RFC 3463 says X.2.2 should be treated as a persistent temporary failure.

What to do: One “mailbox full” isn’t a reason to remove someone. A mailbox that’s been full for months usually means an abandoned account. Many platforms convert repeated soft bounces into hard bounces automatically; Mailchimp, for example, says it cleans an address after 7 soft bounces when there’s no subscriber activity, and after up to 15 for contacts with past activity.

Typo suspected

The domain is a near-miss of a major provider (gmial.com, yaho.com). Some tools label these invalid, others risky with a suggestion.

What to do: On a form, show the suggestion and let the person confirm. On a list, correct only obvious cases you can verify, or leave them out. See common email typos.

Free provider

Some tools flag Gmail, Yahoo, Outlook.com, and similar domains as “free.” This isn’t a risk to deliverability; it’s context. B2B teams use it for lead scoring.

Unknown

Unknown means the verifier tried and couldn’t get a definitive answer. Common causes:

Timeouts. The mail server didn’t respond within the tool’s time limit.
Greylisting. The server sent a temporary 421 or 450 on purpose. RFC 6647 describes this anti-spam technique, which expects legitimate senders to retry later, often within a window of minutes to hours.
Blocked verification. The server refused the verifier’s connection or rate-limited it.
Non-committal replies. Under RFC 5321, a server that won’t verify a user can answer 252, meaning it can’t verify but will accept and attempt delivery.

What to do: Re-run unknowns after a few hours; greylisted results often resolve on a second attempt. If they stay unknown, treat them like catch-all addresses: mail them in a small, separate batch and suppress whatever hard-bounces.

Turning results into actions

Here’s a practical default policy you can adapt. Adjust it for your list source and how much bounce risk your sending reputation can absorb.

Result / sub-status	Opted-in marketing list	Cold outreach	Signup form
Valid	Send	Send	Accept
Invalid (any reason)	Suppress	Suppress	Reject, ask to correct
Catch-all / accept-all	Send	Small separate batch	Accept
Disposable	Remove	Remove	Block or flag
Role-based	Send if opted in	Usually skip	Accept, tag
Mailbox full	Send; suppress if persistent	Skip this round	Accept
Typo suspected	Fix or skip	Skip	Suggest correction
Unknown	Re-check, then small batch	Skip or small batch	Accept, rely on confirmation email

Two numbers worth keeping in mind as you decide how aggressive to be: Amazon SES places accounts under review at a 5% hard-bounce rate and may pause sending at 10%. If you send through a provider like that, risky and unknown addresses are where most of your remaining bounce exposure lives.

What the verifier on this site reports

Our free email verifier reports results based on DNS-level checks: syntax, domain existence, MX and null MX records, disposable domains, role-based addresses, free-provider detection, and suggested fixes for common domain typos. Because it doesn’t open an SMTP connection to the recipient’s mail server, it never returns “mailbox not found” or “accept-all” verdicts, and a passing result means the address can plausibly receive mail rather than that the specific mailbox is confirmed.

FAQ

What’s the difference between “invalid” and “risky”?

Invalid means the address can’t receive mail at all, such as a dead domain or a rejected mailbox. Risky means it probably can receive mail but has a characteristic that raises the chance of a bounce, a complaint, or low engagement, like a catch-all domain or a disposable inbox.

Should I delete catch-all addresses from my list?

Not automatically. Many real businesses run catch-all domains, and those addresses may be your best B2B contacts. Send to them separately, watch bounces, and use engagement to decide whether to keep them.

Why did a valid address bounce?

The mailbox may have been deleted after verification, the server may have accepted during the check and bounced later, or your message may have been rejected for policy reasons like missing authentication. Check the bounce code; our guide to bounce classification explains how to read it.

How long are verification results good for?

There’s no fixed expiry, because addresses decay at different rates on different lists. A B2B list loses addresses as people change jobs, so results age faster than on a consumer list of active customers. Re-verify before sending to anything you haven’t mailed recently.

Email Verification Results Explained: Valid, Invalid, Risky, Unknown