Every B2B database says its emails are verified. Almost none says when. That omission hides the most important variable in contact data quality: verification is not a property of a record — it's a property of a record at a moment in time. A check that passed eight months ago tells you what was true eight months ago.
People change jobs, companies migrate mail servers, IT teams retire aliases, and domains lapse. Industry estimates for B2B email decay cluster around 2–3% per month, which compounds to roughly a quarter to a third of a list going stale within a year. A vendor that verifies at collection time — when the record first enters the database — is selling you a snapshot that started aging the day it was taken.
Verification is a timestamp, not a badge
Think of a "verified" flag the way you'd think of a passed health inspection. It's meaningful, but only relative to its date. A restaurant inspected in January can still poison you in October. The same is true of an email address: the check itself can be flawless, and the result can still be obsolete.
This is why the right question to ask any data vendor isn't "do you verify?" but "how old is the verification on the record I'm about to export?" If the answer is "whenever the record was added," you're buying the average age of the database, not the current state of the inbox. Argorant's answer is structural: every contact is SMTP-verified at the moment of export, so the verdict reflects the inbox's current state rather than whenever the record was added.
What an SMTP probe actually proves
It's worth being precise about what verification means mechanically, because the lighter layers get marketed as if they were the whole stack. A syntax check proves an address is well-formed. A DNS/MX lookup proves the domain exists and publishes mail servers. Neither proves a mailbox exists.
An SMTP probe goes further: the verifier opens a real connection to the recipient's mail server, walks through the opening of a delivery conversation — HELO, MAIL FROM, RCPT TO — and reads the server's verdict on that specific mailbox. Then it disconnects before any message is sent. A 250 response means the server accepts mail for that address right now. A 550 means it doesn't. No email lands in anyone's inbox; the handshake itself is the test.
Doing this at scale is harder than it sounds, which is part of why most vendors don't do it at export time. Mail servers greylist unfamiliar senders, throttle repeated probes, and answer differently depending on the reputation of the IP asking. A production verifier needs retry logic, pacing, and a pool of well-kept sending infrastructure — fixed costs that only make sense if verification is the product's core, not a checkbox.
The honest caveat is catch-all domains. Some mail servers accept every RCPT TO regardless of whether the mailbox exists, which makes a definitive verdict impossible at the protocol level. The wrong move is to silently count those as valid. Argorant marks them as catch-all and makes them opt-in: you decide whether accept-all results belong in your export, with full knowledge of what they are.
What pay-per-valid changes for buyers
Verification timing isn't just a quality argument — it rewires the vendor's incentives. Under the standard model, you pay per record revealed, valid or not. The vendor's revenue is indifferent to whether the address bounces, so stale records still monetize. Decay is your problem.
Verify-at-export makes a different pricing model possible: charge only for addresses that pass the live probe. On Argorant, an invalid result costs 0 credits. You aren't billed for the vendor's decay, and the vendor now has a direct financial reason to keep verification current — every stale record it serves is revenue it doesn't collect.
For buyers, this collapses two line items into one. You no longer pay separately for a list purchase and a downstream cleaning pass through a verification tool, because the cleaning is the purchase. The price on the page is the price per deliverable contact, which is the only unit that ever mattered.
How to pressure-test any vendor on this
Three questions separate verified-at-export vendors from verified-at-collection ones. First: "If I export the same contact twice, six months apart, is it re-verified the second time?" Second: "Do I pay for records that bounce?" Third: "How do you label catch-all domains, and can I exclude them?" Evasive answers to any of these tell you the verification badge is decorative.
Run the test empirically too: pull a sample export and push it through an independent checker the same day. A verified-at-export vendor should produce single-digit invalid rates on fresh exports; a verified-at-collection vendor will show its database's true age. With 614M contacts across 184 countries, Argorant's bet is that verification at the moment of export — not at the moment of collection — is the only definition of "verified" that survives contact with an actual send.