---
title: "AgentsVerify and MillionVerifier"
description: "A plain-language comparison of 608 verification outcomes and their disagreements."
url: https://agentsverify.dev/compare/millionverifier
markdown_url: https://agentsverify.dev/compare/millionverifier.md
---

Independent comparison · 608 addresses

# What the numbers _actually say._

Two verification systems checked the same addresses. The headline is 83.4% agreement; the useful story is how the remaining decisions move.

Saved MillionVerifier referenceAgentsVerify bulk rerun11-09-2026

The short version

**AgentsVerify resolves more of the grey area.**

It returns more valid and catch-all outcomes, while never turning a MillionVerifier-valid row into an AgentsVerify-invalid row in this comparison.

The leaderboard

## The result at a glance

Conclusive agreement

**438 / 525**83.4% of the rows where MillionVerifier had a hard verdict

Conclusive disagreement

**87**16.6% of those same 525 rows

AgentsVerify valid

**82 vs 78**Four more valid outcomes overall

AV invalid / MV valid

**0**No direct hard-negative conflict in this sample

How to read this

## Hard verdicts are the point.

For this comparison, we treat a hard _valid_ or _invalid_ result as a provider decision made only after its checks cross the provider's confidence threshold. _Catch-all_ and _unknown_ stay outside that hard yes/no. This page reports the results from one 608-address comparison.

Same 608 addresses

## A wider answer without pretending certainty

MillionVerifier calls more rows invalid. AgentsVerify turns more rows into a useful outcome instead of stopping at an unresolved answer.

Final result counts

| Outcome | MillionVerifier | AgentsVerify | AV − MV | Plain reading |
| --- | --- | --- | --- | --- |
| Valid | 78 | 82 | +4 | AgentsVerify has the larger valid bucket. |
| Invalid | 384 | 355 | −29 | MillionVerifier uses a hard invalid verdict more often. |
| Catch-all | 63 | 100 | +37 | AgentsVerify keeps more risky domains out of a hard yes/no. |
| Unknown | 83 | 71 | −12 | AgentsVerify resolves more rows in this run. |
| Total | 608 | 608 | — | Same input set |

The extra catch-all outcomes are deliberate: a domain that accepts random recipients should not be presented as a clean, hard-valid mailbox.

The 16.6% disagreement

## Most of it is not valid versus invalid.

There are 87 disagreements among the 525 rows where MillionVerifier returned a conclusive label. The dominant pattern is MV saying **invalid** while AgentsVerify stays at **unknown** or **catch-all**.

Every conclusive-label disagreement

| MillionVerifier | AgentsVerify | Rows | Share | What it means |
| --- | --- | --- | --- | --- |
| invalid | unknown | 51 | 58.6% | AgentsVerify did not force a hard negative. |
| invalid | catch-all | 30 | 34.5% | AgentsVerify treated the domain as risky instead. |
| invalid | valid | 1 | 1.1% | One vendor disagreement; the underlying evidence is retained.Reviewed separately: public evidence and repeated SMTP controls support the AgentsVerify-valid result. |
| valid | catch-all | 3 | 3.4% | AgentsVerify downgraded three vendor-valid rows to risky. |
| valid | unknown | 1 | 1.1% | AgentsVerify kept one row unresolved. |
| catch-all | unknown | 1 | 1.1% | One catch-all comparison remained unresolved. |
| Total | 87 | 16.6% | Of 525 conclusive MV comparisons |

The useful asymmetry

## Seven recovered positives versus three downgrades.

Of the 83 addresses that MillionVerifier left unknown, AgentsVerify returned 7 valid, 53 invalid, 5 catch-all and 18 unknown. On the other side, three MillionVerifier-valid addresses became catch-all with AgentsVerify—not invalid.

Where MillionVerifier said unknown

| AgentsVerify | Rows | Reading |
| --- | --- | --- |
| valid | 7 | The key recovery group: AgentsVerify found a hard positive where MV stayed unknown. |
| invalid | 53 | AgentsVerify found a hard negative where MV stayed unknown. |
| catch-all | 5 | AgentsVerify identified a risky domain. |
| unknown | 18 | Both systems left the result unresolved. |
| Total | 83 | MV unknown bucket |

Why the bulk path can go further

**3 of the 7 recovered valids used a delayed retry.**

Those three addresses first hit a temporary connection drop. The bulk workflow waited roughly 15 minutes, tried the target again, and then completed the separate control check. MillionVerifier typically returns a decision within a few seconds, so its normal fast-response path cannot wait 10–15 minutes for this delayed recovery before responding. AgentsVerify can reserve that extra time for bulk jobs while keeping real-time checks fast.

The honest conclusion

## More recovery, still conservative.

01

### We do not call MV-valid rows invalid.

That direct hard-negative conflict was zero in this 608-address comparison.

02

### We find more than we miss on the valid side.

Seven MV-unknown rows became AgentsVerify-valid; three MV-valid rows became catch-all.

03

### A little more time, more recovered valids.

A delayed retry, like AgentsVerify uses for bulk jobs, can recover valid addresses that MillionVerifier leaves unknown.

MillionVerifier appears more aggressive at rejecting addresses. Agents Verify appears safer and better at preserving potentially deliverable contacts while avoiding direct false-invalid classifications. In this comparison, AgentsVerify recovered seven addresses that MillionVerifier left unknown, and public evidence strongly supports at least four of those results. We also had no case where MillionVerifier said valid and AgentsVerify said invalid. The remaining uncertainty is concentrated in provider-policy and catch-all cases, not obvious false-valid decisions.

Run the workflow yourself

## Start with 500 free credits.

[See pricing](https://agentsverify.dev/pricing.md)