Nobody can sell you a mailbox that stays verified

The phrase "verification webhook" implies a mailbox reports on itself. It cannot. A web server will answer an SMTP probe whenever you ask, but nothing inside it will call you when the person leaves the company.

The event you actually want

What you care about is a state change, not a status:

• the person left and the address was disabled,
• the domain moved to a different mail provider and the routing changed,
• a personal mailbox became a role mailbox with a queue behind it,
• the catch-all was switched off and unknown rows turned into hard bounces.

Every one of those events is only visible from outside, by probing again. A webhook is therefore not a feature of the mailbox - it is a paid promise that someone keeps probing for you, forever.

Why the decay is not a rounding error

A list that was clean when you bought it is a list with a half-life. That is the whole reason a re-check cadence exists: not because the first check was wrong, but because the answer has an expiry date.

What TAPAC does instead

TAPAC verifies inside the search request. You ask for contacts matching criteria, and each result comes back with the address, the source it was found in, and its SMTP state as of that call. There is no stored copy of the mailbox on our side, so there is nothing to go stale - and, honestly, no notification either. The state you get is a snapshot with a timestamp, and it is your call how often to take another one.

A re-check cadence that costs almost nothing

1. Check at the moment of send. A contact that passed verification minutes ago needs nothing else.
2. Re-check before the second touch. The gap between touch one and touch three is usually where a job change lands.
3. Re-check a segment on a calendar, not on a feeling. 90 days for active sequences, 180 for cold lists - the decay numbers above tell you the direction, your bounce tolerance tells you the length.
4. Keep unknown as its own bucket. Catch-all domains answer for everything, so they are not a yes and they are not a no. Never let them inflate the denominator.
5. Let the result delete rows. An invalid state is the cheapest unsubscribe you will ever get; a bounced send costs you sender reputation, which is not refundable.

Five questions for any vendor promising verification webhooks

1. Is the state in your webhook a fresh SMTP probe, or a cached field? How old is the cache at the moment it fires?
2. What do you charge for a re-check of an address you have already checked once?
3. Which addresses are even eligible for retest - does your coverage include catch-all domains, and what do you return for them?
4. Do you return unknown as a first-class state, or do you silently fold it into valid?
5. If I stop paying, do the checks stop? (They do with everyone. That is the definition of the subscription.)

Doing it yourself

npx -y @tapacapi/mcp        # tools: tapac_find_contacts, tapac_status
# or hosted: https://tapacapi.com/mcp
# or REST:   POST https://tapacapi.com/v1/contacts/search

One call returns the contact, where it was found, and its SMTP state. Schedule the call instead of subscribing to a stream, and the freshness problem becomes a cron line instead of a line item.