How to verify email addresses before you send

The four checks, in order

Every serious verifier runs some version of this pipeline. Knowing what each step can and cannot tell you is what lets you read the results honestly.

1. Syntax. Is it a well-formed address? Catches typos like a missing @, spaces or a doubled dot. Cheap and certain, but only rules out obvious garbage.
2. Domain and mail servers. Does the domain exist, and does it publish MX records saying which servers accept its mail? A domain with no MX record cannot receive email. Also catches expired company domains.
3. Mailbox check. The verifier connects to the domain's mail server and starts a conversation as if to deliver a message, asking whether it will accept mail for this address, then disconnects without sending. A clear rejection means the mailbox does not exist. A clear acceptance usually means it does.
4. Catch-all detection. The verifier also asks about an address that cannot exist (random characters at the same domain). If the server accepts that too, the domain is a catch-all: it accepts everything at this stage, so step 3 told you nothing.

Good verifiers add more: flagging role addresses like info@ or sales@, disposable-mail domains, and known spam traps. But those four steps are the core.

What the results actually mean

Verifiers return a status per address. The labels vary by vendor; the meanings do not.

The most expensive mistake is treating unknown as valid. Some tools do this by default to make their match rates look better. If your bounce rate is high despite verifying, check how your tool labels unknowns.

The catch-all problem

Many company domains are catch-alls, often larger organisations and those running email security gateways. You cannot verify an individual mailbox at those domains by asking the server.

What you can do:

• Check the pattern. If you have a confirmed address at the same company (a reply, a signature, a website), and it follows first.last@, a catch-all address in the same format is more likely to be real.
• Look for the address in public. A conference speaker page, a press release or a GitHub commit confirms it.
• Send a small batch first. If you must send to catch-alls, send a few, watch bounces for a day, then decide.
• Keep them out of high-volume sends. Mixing many unconfirmed catch-alls into a large campaign is how a good domain earns a bad reputation.

More background in catch-all email.

When to verify

Verification is a snapshot. The address that was valid when you bought it may not be valid when you send.

1. Before an address enters any sequence. Not when it was enriched.
2. Again before a new campaign to an old list.
3. Anything older than about three months, re-verify. This is a rule of thumb, not a published standard: people change jobs, and companies close the old mailbox.
4. After any bounce spike, verify the remaining list before sending another message.

A cost comparison

Say you have 2,000 addresses from an old export and 10% are now dead. Illustrative numbers:

• Send without verifying: about 200 hard bounces. At that rate (10%), mailbox providers see a list that looks bought or abandoned, and you have spent 200 sends of your daily allowance on nothing.
• Verify first: you remove those 200 before sending, plus whatever the catch-all and unknown buckets hold. You lose some reach and keep the domain clean.

Verification is priced per address, and the price is small next to what you paid for the address in the first place. Against the cost of rebuilding a sending domain's reputation, it is cheap. Our piece on cold email bounce rate covers what to do when bounces have already happened.

Doing it yourself

You can run the mailbox check from a script, but there are good reasons not to from your main infrastructure. Mail servers notice repeated probing from one IP and start returning unknown or blocking, and you do not want that IP to be your sending server. Use a dedicated verification service, and compare two if the results matter.

Who pays when verification is wrong?

Policies differ. Apollo refunds a credit when an Apollo-verified email bounces within 30 days, if you sent through Apollo. Many tools offer no refund at all. Sluice verifies every address independently before you see it, bills only verified addresses, and refunds a bounce exactly what it cost, once. Sequences stop on a bounce, so step two never goes to a dead mailbox. The wider question of who bills for lookups that find nothing is worth reading before you choose any data tool, and email verification has the short definition.

Checklist for your next send

1. Verify every address within the last few days before it goes out.
2. Send to valid only. Delete invalid. Retry unknown later.
3. Hold catch-alls unless you have supporting evidence.
4. Replace role addresses with a named person.
5. Remove every hard bounce the moment it happens.