How to cut your email bounce rate before you send anything

A bounce is usually treated as one wasted email. It is not. Mailbox providers watch what proportion of your mail hits addresses that do not exist, and they use that number to decide where your future mail lands. Push the rate high enough and messages to perfectly good addresses start going to spam.

That makes bounce rate one of the few metrics where prevention is dramatically cheaper than cure.

Where bad addresses come from

Three sources, in roughly this order:

1. Typos at signup. gmial.com, yaho.com, hotmial.com. The user meant to give you a real address and will never know they did not.
2. Disposable addresses. Someone wanted the free tier without the email. These deliver at first and stop existing later.
3. Decay. A list gathered two years ago has people who changed jobs. Roughly a fifth of a B2B list goes stale annually.

Only the third needs an ongoing process. The first two are fixable at the moment of capture, which is the cheapest possible place.

Check at the point of capture

Validate when the form is submitted, not in a batch job later:

curl "https://twotic.dev/v1/email-verify/verify?email=user@gmial.com" \
  -H "Authorization: Bearer $TWOTIC_KEY"

{
  "email": "user@gmial.com",
  "verdict": "risky",
  "score": 35,
  "reasons": ["Domain looks like a typo. Did you mean user@gmail.com?"],
  "didYouMean": "user@gmail.com",
  "mxFound": true,
  "disposable": false,
  "roleAccount": false
}

The didYouMean field is the highest-value part of the response and the one most people skip. Do not block the signup on it — show it as a correction the user can accept:

async function handleSignup(email: string) {
  const check = await verify(email)

  if (check.verdict === "undeliverable") {
    return showError("That address cannot receive mail. Check for a typo?")
  }

  if (check.didYouMean) {
    return suggest(`Did you mean ${check.didYouMean}?`)
  }

  return accept(email)
}

async function handleSignup(email) {
  const check = await verify(email)

  if (check.verdict === "undeliverable") {
    return showError("That address cannot receive mail. Check for a typo?")
  }

  if (check.didYouMean) {
    return suggest(`Did you mean ${check.didYouMean}?`)
  }

  return accept(email)
}

def handle_signup(email: str):
    check = verify(email)

    if check["verdict"] == "undeliverable":
        return show_error("That address cannot receive mail. Check for a typo?")

    if check.get("didYouMean"):
        return suggest(f"Did you mean {check['didYouMean']}?")

    return accept(email)

A recovered typo is a customer you would otherwise have lost silently — they never get the confirmation email, assume signup failed, and leave.

Decide policy per verdict, not per score

The response gives you a verdict and the reasons behind it precisely so you can set your own policy. A reasonable starting point:

Note that risky is not reject. A role account like support@ is a real mailbox and a legitimate customer — it just converts poorly in a campaign. Blocking it at signup loses a real account to protect a metric that does not apply.

Clean an existing list in batches

For a list you already have, use the batch endpoint — up to 100 addresses per call, checked concurrently, and priced at half the per-address rate:

curl -X POST "https://twotic.dev/v1/email-verify/verify/batch"   -H "Authorization: Bearer $TWOTIC_KEY"   -H "Content-Type: application/json"   -d '{"emails": ["a@example.com", "b@example.com"]}'

# Batch in pages of 100 and keep the addresses whose verdict is "deliverable".

async function cleanList(emails: string[]): Promise<string[]> {
  const keep: string[] = []

  for (let i = 0; i < emails.length; i += 100) {
    const res = await fetch("https://twotic.dev/v1/email-verify/verify/batch", {
      method: "POST",
      headers: {
        Authorization: `Bearer ${process.env.TWOTIC_KEY}`,
        "Content-Type": "application/json",
      },
      body: JSON.stringify({ emails: emails.slice(i, i + 100) }),
    })

    const { results } = (await res.json()) as {
      results: { email: string; verdict: string }[]
    }
    keep.push(...results.filter((r) => r.verdict === "deliverable").map((r) => r.email))
  }

  return keep
}

async function cleanList(emails) {
  const keep = []

  for (let i = 0; i < emails.length; i += 100) {
    const res = await fetch("https://twotic.dev/v1/email-verify/verify/batch", {
      method: "POST",
      headers: {
        Authorization: `Bearer ${process.env.TWOTIC_KEY}`,
        "Content-Type": "application/json",
      },
      body: JSON.stringify({ emails: emails.slice(i, i + 100) }),
    })

    const { results } = await res.json()
    keep.push(...results.filter((r) => r.verdict === "deliverable").map((r) => r.email))
  }

  return keep
}

import os
import requests

def clean_list(emails: list[str]) -> list[str]:
    keep: list[str] = []

    for i in range(0, len(emails), 100):
        res = requests.post(
            "https://twotic.dev/v1/email-verify/verify/batch",
            headers={"Authorization": f"Bearer {os.environ['TWOTIC_KEY']}"},
            json={"emails": emails[i : i + 100]},
        )
        results = res.json()["results"]
        keep += [r["email"] for r in results if r["verdict"] == "deliverable"]

    return keep

Suppress the rest rather than deleting them. A risky address may be worth a transactional email even when it is not worth a campaign, and deleting the record loses that distinction permanently.

What checking cannot tell you

Worth being clear about the limits, because a verification service that claims certainty is lying.

There is no SMTP probe here — and that is deliberate. Connecting to a mail server to ask whether a mailbox exists is unreliable, because the major providers accept everything and discard later, so the probe proves nothing. It also gets the probing address blocklisted, which degrades results for everyone using that service.

What DNS and heuristics do tell you is whether the domain can receive mail at all, whether it is a known throwaway provider, whether the local part is a role account, and whether it looks like a typo of a common domain. That catches the overwhelming majority of what actually bounces. It cannot tell you that a specific person still works somewhere.

So treat verification as removing the certainly-bad, not certifying the good. The remaining signal comes from engagement: an address that has not opened anything in a year is a better suppression candidate than any pre-send check can identify.

The order that works

1. Verify at signup, suggest corrections, reject only undeliverable.
2. Verify a purchased or imported list in full before its first send.
3. Suppress on hard bounce immediately — never retry a bounced address.
4. Suppress on prolonged disengagement, which no API can detect for you.

The first step alone usually moves the number more than the other three combined, because it stops the problem being created.

What a bounce actually costs

The wasted send is the smallest part of it, and treating bounces as a cost-per-message problem is why the issue gets ignored until it is severe.

Mailbox providers score senders on behaviour, and delivery is decided by that score long before a human sees a subject line. A hard bounce is an unambiguously bad signal: it says you mailed an address that does not exist, which means you did not verify it, which correlates with lists that were bought or scraped. Providers cannot see how you built your list — a bounce rate is one of the few things that tells them.

The consequence is not proportional. Reputation does not degrade smoothly with volume; past a threshold, mail starts landing in spam or being rejected outright — including mail to the valid addresses. That is the real cost. A campaign with a bad bounce rate does not just fail to reach the invalid addresses; it degrades delivery to the customers who were waiting for it, and to your password resets and receipts if they share a sending domain.

Two structural decisions follow:

• Separate transactional from marketing sending. Different subdomains, ideally different providers. A marketing campaign should never be able to take password resets down with it.
• Recovery is slow. Reputation is rebuilt over weeks of consistent, low-bounce sending, not by fixing the list and resuming at full volume. This asymmetry is the whole argument for checking before the send: a few minutes of verification prevents something that takes a month to undo.

What you can build with this

A signup field that fixes typos instead of rejecting them. Check on blur, and when the domain is a near-miss for a common provider, offer the correction inline. This is the highest-value version of everything in this guide: it recovers users who would otherwise have silently disappeared, and it never blocks anyone.

A one-off cleanup script for a list you inherited. Verify in batches, tag rather than delete, and suppress the hard failures. Most teams have a list like this sitting somewhere, and nobody has run this because it sounds bigger than it is.

A pre-send gate in your campaign flow. Refuse to send if the estimated bounce rate for the segment is above your threshold. It turns a reputation problem into a blocked deploy, which is the only form of it anyone reacts to in time.

A signup quality dashboard. Track verdict distribution over time by acquisition source. A channel that suddenly starts delivering undeliverable addresses is telling you something important, and it is invisible without this.

Related reading

• Email Verify — the single and bulk endpoints used above, with the full verdict list.
• How to control LLM API costs — the same principle applied to inference: check before you spend, not after.