Email verification colors in TOM: what green, yellow and red actually mean

The short version

Two things worth noticing immediately. First, the mapping is ordered: TOM reads the score bands from top to bottom, so each address lands in exactly one row. Second, there are seven verdicts behind three lights — red covers four different situations (unknown, disposable, risky, invalid) that fail for completely different reasons. The rest of this guide unpacks each one.

Before the color: what verification actually checks

The light is the last step of a six-stage pipeline. Knowing the stages matters because each color is really a statement about where the address failed or passed:

1. Syntax check. Is the address well-formed (one @, valid local part and domain)? A malformed address never gets past this stage — it becomes invalid with reason invalid_syntax.
2. Domain check. Does the domain exist and resolve in DNS? A dead or unregistered domain becomes invalid (no_mx_records, or spf_reject_all when the domain explicitly rejects all inbound mail).
3. MX record check. Does the domain publish mail servers that can receive email? No MX records means no inbox exists — again invalid.
4. Disposable detection. Is the domain on the list of 5,000+ known temporary email providers (Mailinator, 10MinuteMail, Guerrilla Mail and the like, updated daily)? A match becomes disposable, regardless of whether the mailbox technically exists.
5. SMTP check. The decisive step: BillionVerify connects to the recipient mail server and asks, via RCPT TO, whether the specific mailbox exists. A 250 OK confirms it (valid); a 550 user unknown kills it (invalid, mailbox_not_found). Everything ambiguous — timeouts, greylisting, rate limits, blocked probes — becomes unknown or catchall.
6. Score calculation. All stage results are combined into a confidence score from 0.0 to 1.0. SMTP confirmation carries the most weight (about 30%), followed by MX records, domain existence, disposable status and reputation signals.

On top of this pipeline there are two orthogonal detections: role-based patterns (is this a shared inbox?) and reputation screening against the Spamhaus Domain Blocklist (is this domain a confirmed spam, phishing, malware or botnet source?). They produce the role and risky verdicts respectively.

Green: valid

Green is the only verdict that confirms the individual mailbox, not just the domain. Syntax is valid, the domain exists, MX records are published, the address is not disposable, and the receiving server explicitly accepted the recipient. Confidence is high — in BillionVerify's scale this is the 0.9–1.0 band, "highly confident valid".

What to do: include in cold campaigns without hesitation. Green addresses are the backbone of every send; the campaign quality threshold in TOM exists precisely to keep their share high.

Yellow: catch-all

Catch-all is a property of the domain, not of the address. Small companies and self-hosted setups often configure their mail server — or a security gateway such as Mimecast or Proofpoint in accept-all mode, or a Microsoft 365 internal relay — to accept every recipient rather than bounce unknown ones. The SMTP conversation therefore proves nothing about whether marco@ actually works there.

Typical reason codes behind a catch-all include catch_all_domain (random probe accepted), catch_all_deliverable (catch-all domain where the specific address also returned 250 OK), gateway_accept_all and m365_internal_relay. Forwarding-alias services (SimpleLogin, Firefox Relay, Duck.com) and some regional consumer domains land here too.

Why yellow and not green? Because the bounce risk is structurally higher: you are sending to an address the verifier could not individually confirm. Why yellow and not red? Because many catch-all addresses are real people at real companies — discarding them all would throw away legitimate prospects, especially in the SMB segment.

Yellow: role-based

One subtlety from the documentation: role addresses inherit the reason code from their underlying SMTP check — there are no dedicated reason codes for this status. A role address that passed SMTP shows reason: smtp_deliverable, exactly like a green address. The role flag (is_role: true) is what distinguishes it.

Not all role addresses carry the same risk. As a rule of thumb from BillionVerify's reference:

Why yellow? The mailbox exists, so red would be wrong — but a cold email to info@ competes with every other inbound message to that company, and some providers restrict role addresses outright. Fine for transactional mail; for cold outreach, use deliberately and expect lower reply rates.

Red: unknown

Unknown is the most misunderstood verdict, because "unknown" sounds neutral while TOM shows red. The red is intentional: an address whose validity cannot be confirmed carries the same sending risk as a bad one until proven otherwise. That is why TOM guides you toward doing cold outreach properly and blocks red addresses instead of letting you gamble a bounce on them.

Common causes split into two groups:

• Temporary and retryable — worth verifying again: smtp_timeout, smtp_rate_limited, smtp_greylisted (including the Mimecast variant), Proofpoint async lookups, Google and Microsoft 365 temporary rejections, DNS timeouts and transient internal errors.
• Structural and not retryable — retrying will not change the result: providers that block SMTP probes by policy (Apple iCloud, Microsoft consumer mail, Proton, Tuta, Japanese carrier domains), servers that blacklisted the probe connection, misaligned DMARC configurations, mailboxes over quota or disabled, and accounts configured to skip SMTP verification.

Practical rule: re-verify once after a delay — greylisting and rate limits often clear, and the address may turn green or yellow and become selectable. While it stays unknown, it remains excluded by default and cannot be added to a cold campaign.

Red: disposable and risky

Disposable (is_disposable: true, reason disposable_domain) covers Mailinator, 10MinuteMail, Guerrilla Mail, TempMail and thousands of smaller generators. These addresses rarely engage, are often used for spam or fraud, and signal near-zero lifetime value — particularly damaging in registration flows.

Risky is the verdict missing from most summaries, so it deserves a full explanation. It means the mailbox most likely accepts mail (is_deliverable: true), but the recipient domain is listed in the Spamhaus Domain Blocklist for spam, phishing, malware distribution or botnet command-and-control. The risk_reasons array tells you which one: spamhaus_dbl_spam, spamhaus_dbl_phish, spamhaus_dbl_malware or spamhaus_dbl_botnet_cc. Sending there can damage your own sending reputation, so the recommended action is identical to disposable: remove from the list. Retrying never changes a risky result.

One reassurance from the documentation: domains flagged by Spamhaus as abused legitimate sites — a normal company website that was compromised — never produce a risky result. A hacked website does not mean that company's mailboxes are bad.

Red: invalid

Invalid is the most confident negative verdict (score around 0.1). Typical reason codes: invalid_syntax (malformed address), no_mx_records (domain has no mail server), spf_reject_all (domain explicitly rejects all inbound mail), mailbox_not_found (server returned 550 / user unknown) and host_not_found (the MX host itself is unreachable).

There is no "maybe" here and no retry logic that helps: an invalid address will bounce every time. In cold outreach it is pure cost — a bounce, a reputation hit, and a prospect who never existed.

Score vs status: which one decides the color?

Both — and they never disagree. Every status carries a fixed score, so the two readings are equivalent:

Think of the score as the machine-readable form of the status, and the color as the human-readable form of the score. TOM evaluates the bands from top to bottom — the first threshold the score meets wins — which is why an address can only ever have one light. The is_deliverable flag follows the same logic: true for valid (and technically for risky), false for invalid, null for unknown and catch-all where deliverability is genuinely undetermined.

What to do with each color in TOM

Verification is only useful if it changes what you send. In TOM it does so by design: red addresses are excluded by default and cannot be selected for a cold campaign — guiding you toward doing cold outreach properly means not letting you send to addresses that would certainly bounce. Green and yellow are selectable; the per-campaign quality threshold then decides how much yellow a send may contain.

In TOM this plays out in three places: the per-address light tells you what each contact is worth, the minimum quality threshold per campaign keeps green share high across the selectable addresses, and the pre-flight check before launch stops a campaign whose list quality would burn the domain. Red addresses never reach that point — they are filtered out before selection. Verification credits never expire, so re-verifying an unknown address next week — or cleaning a list that sat idle for 90 days — costs nothing extra, and an address that turns green or yellow becomes selectable.

When the result surprises you: reason codes

Every verdict ships with a reason field — a stable string identifier that explains why the address got its status. When a light looks wrong, the reason is where you look. The most useful ones to recognize:

• Looks red but you expected green: mailbox_not_found (typo in the address or departed employee), no_mx_records (domain without mail), smtp_blocked or smtp_unverifiable (the provider refuses probes — common with iCloud, Microsoft consumer mail, Proton and Tuta).
• Looks yellow but you expected green: catch_all_domain or gateway_accept_all (the domain accepts everything), or an inherited smtp_deliverable paired with is_role: true (a working but shared inbox).
• Stuck on unknown: check whether the reason is retryable (smtp_timeout, smtp_rate_limited, smtp_greylisted, google_rate_limit, dns_timeout) or structural (smtp_unverifiable, carrier_blocked, mailbox_full). Only the first group improves on retry.
• Score 0.3 with no obvious cause: check risk_reasons. A spamhaus_dbl_* entry means the domain is blocklisted — the address is not "low quality", it is actively dangerous to your reputation.

Two companion flags help with segmentation beyond deliverability: is_free (Gmail, Yahoo, Outlook — useful for B2B vs B2C scoring and fraud detection) and smtp_check (whether the deep SMTP probe actually ran, or the verdict rests on domain-level heuristics).

FAQ

This guide is part of the TOM blog. Verification statuses and scores follow the BillionVerify verification-types documentation and the verification-reasons reference. Related reading: the 12 cold email frameworks, 12 cold email software alternatives compared and warmup as a platform behavior.