You finally ran a validation pass over your HubSpot list, and now you're looking at a column of statuses you only half recognise. Some say invalid, which is clear enough. But then there's catch-all, role-based, disposable, accept-all, unknown. HubSpot didn't put those labels there and it can't tell you what to do with them.
The uncomfortable part is that a few of these addresses look completely fine. They'll pass every format check HubSpot runs, and they'll still quietly damage your sender reputation the moment you email them. Knowing which status means "delete this," which means "look closer," and which means "keep, but not in a campaign" is the difference between a list you can trust and one that's working against you.
This post is about reading the results, not producing them. If you haven't validated yet, the complete guide to email validation in HubSpot covers how to do it on entry and in bulk. Assume you've done that, and let's go through the statuses one by one.
An invalid address is one where the mailbox doesn't exist or the domain is dead. These are your hard bounces before they've happened: the typo (gmial.com), the person who left the company two years ago, the address that was never real to begin with.
There's no judgement call here. Emailing an invalid address is the single most direct hit you can take to your sender reputation, because every bounce tells Gmail and Outlook you don't manage your list, and they respond by routing more of your mail to spam, including the mail to your good contacts. It's also money: an invalid address is still a Marketing Contact you're paying to store.
What to do: suppress them from your sends, and set them non-marketing or remove them so you stop renewing addresses that can never open anything. This is the same upstream half of the fix as lowering your HubSpot bounce rate, catching them before the send rather than letting HubSpot learn the hard way.
A catch-all domain is configured to accept mail sent to any address at that domain. anything@theircompany.com gets a "yes" from the server, whether or not a real mailbox sits behind it. That makes catch-alls genuinely unverifiable. No tool can confirm the specific mailbox exists, because the domain will confirm every address you throw at it. Anyone selling you "100% accurate" validation is quietly guessing on exactly these.
Catch-alls are common on smaller company domains and some enterprise setups, so a chunk of your legitimate B2B contacts will land here. Treating every catch-all as invalid throws away real people; treating every one as safe invites bounces.
What to do: don't auto-suppress and don't blindly send. Route them to a review view and lean on other signals. Has this contact ever opened or replied? Where did they come from? A catch-all address on a contact who engaged last month is very different from a catch-all on a two-year-old enrichment import. Being honest about this uncertainty is more useful than a clean-looking status that lies to you.
A role-based address points at a function, not a person: info@, sales@, support@, admin@, hello@. It's usually a real, deliverable inbox, which is why it won't show as invalid. The risk is who's behind it.
Role-based inboxes are shared, monitored by whoever's on rota, and far more likely to generate a spam complaint than a personal address. A complaint is the heaviest negative signal there is. They also barely engage, which drags the engagement rate that decides your inbox placement. Some mailbox providers weight complaints from these addresses heavily for exactly this reason.
What to do: keep them where a shared inbox genuinely makes sense (a support thread, a one-to-one reply), but keep them out of marketing nurture and big campaign sends. Filtering them out of a broad send usually lifts your numbers rather than hurting reach.
Disposable addresses come from services like Mailinator, 10minutemail, or guerrillamail: inboxes designed to expire within hours. Someone grabbed your gated PDF without handing over a real address. The mailbox is dead within days, so it's a future bounce with zero pipeline value attached.
What to do: suppress on sight, and better still, block them at the form so they never enter HubSpot in the first place. As the validation guide puts it, the check should happen at the door. A disposable address caught on entry is one you never have to clean up later.
A spam trap is an address that exists for one purpose: to catch senders with poor list hygiene. There are two kinds. Pristine traps never belonged to a person; they're seeded across the web to catch anyone scraping or buying lists. Recycled traps are real addresses a provider abandoned, then reactivated as traps once the original owner was long gone.
You can't spot them by looking at your list. That's the entire point of them. And hitting one does outsized damage: it tells a mailbox provider you're emailing people who never opted in, and it can land your domain on a blocklist that takes weeks to climb off. Traps get into a HubSpot portal the same way most bad data does: bought lists, ancient imports carried over from an old CRM, and scraped or guessed addresses from enrichment passes.
What to do: this status is the strongest argument there is for validating on entry and never emailing a purchased list. Being straight about the limit, though: no tool catches every trap, because a well-designed pristine trap is indistinguishable from a real new address. Validation reduces the risk by catching known traps and the dead, decayed addresses that tend to cluster around them. It doesn't eliminate it. Anyone promising otherwise is overselling.
An unknown or greylisted result isn't a judgement. It's a "couldn't get a definitive answer right now." The receiving server timed out, greylisted the check, or temporarily blocked it. The address might be perfectly fine.
What to do: re-check it rather than acting on it. Don't file it with the invalids, and don't assume it's safe either. If it stays unknown across repeated checks, treat it like a catch-all and decide by engagement.
Reading the labels is only half the job. The point is doing something with them, and doing it once rather than every campaign. Because a good validator writes the status and the reason onto the contact as a native HubSpot property, you can filter on it like any other field.
Build one active suppression list (invalid, disposable, and known spam traps) and exclude it from every send, so those addresses can't reach a campaign again. Set the same contacts non-marketing to stop paying for them. Send your catch-all and unknown results to a review view instead of a bin. And keep role-based addresses out of nurture while leaving them reachable one-to-one.
Do that once, leave the validation running on entry, and new addresses get classified as they arrive through your forms, imports, and enrichment tools, with no manual re-run before each send. That's the "set it and forget it" half: the triage happens in the background, and your campaigns only ever go to addresses that earned their place. It's how teams running validation this way have brought sends down to a 0.4% bounce rate across 4,000+ emails, comfortably inside the range mailbox providers reward rather than penalise.
The quick version of what's safe to automate versus what needs a person: suppress invalid, disposable, and known spam traps automatically; review catch-all, unknown, and role-based by hand, because each of those depends on context a rule can't see.
Your validation results aren't noise to skim past. Each status is a decision waiting to be made. Get them right and a validation pass stops being a one-off scrub you'll repeat next quarter and becomes an ongoing filter that keeps the whole list send-ready. Get them wrong and you'll either bin real contacts or keep emailing the ones quietly taxing every campaign you send.
Curious what your own list looks like broken down this way? Run a validation pass over your HubSpot and see how many catch-alls, disposables, and dead addresses are hiding in a list that looked clean from the dashboard.
A catch-all (or accept-all) domain accepts mail sent to any address at that domain, so the server confirms every address whether or not a real mailbox exists behind it. That makes catch-alls impossible to verify with certainty, because no tool can see the individual mailbox. Don't treat them all as invalid, because plenty of legitimate B2B contacts sit on catch-all domains, but don't blindly send either. Decide by other signals: whether the contact has ever engaged, and where they came from.
They're usually deliverable, which is why they won't flag as invalid, but they carry a higher complaint and unsubscribe risk than personal addresses because they're shared inboxes monitored by whoever's on rota. They also engage poorly, which drags the engagement signal that decides inbox placement. Keep them for one-to-one and transactional messages where relevant, and keep them out of marketing nurture and broad campaign sends.
A spam trap is an address that exists purely to catch senders with poor list hygiene. Pristine traps never belonged to a person and are seeded to catch scraped or bought lists; recycled traps are abandoned real addresses reactivated as traps. They get into a portal through purchased lists, old CRM imports, and guessed addresses from enrichment tools. Hitting one does serious reputation damage and can trigger a blocklisting, which is why validating on entry and never emailing bought lists matters more than any cleanup after the fact.
It means the check couldn't reach a definitive answer at that moment, usually a server timeout, greylisting, or a temporary block, not that the address is bad. Re-check it rather than acting on it. If it stays unknown across repeated checks, treat it like a catch-all and decide based on the contact's engagement history rather than filing it with the confirmed invalids.