The pattern /.+@.+\..+/ accepts admin@mailinator.com, test@defunct-domain.io, and notreal@typo.vom. Here's what actually needs to happen before you trust an email address.

Every sign-up form validates email addresses. Most do it with a regex. The regex catches obvious typos — missing @, no domain — but it lets through a much larger class of addresses that will never receive a message. Those addresses quietly inflate your list, skew your open rates, and cost you money on every send.

The four problems a regex can't catch

1. The domain doesn't exist. A user types alice@gmial.com. The regex passes. The domain has no mail server. Your welcome email bounces. Your sender reputation drops. The domain gmial.com used to be a common typo trap — attackers registered it to harvest credentials from misdirected password resets.

2. The domain is real but the inbox is disposable. Services like Mailinator, Guerrilla Mail, and a hundred others give anyone a working inbox with no sign-up. The email is valid — it will actually receive your message — but the address belongs to no one in particular. Anyone who knows the address can read it. Users create throwaway accounts to claim trial offers, avoid marketing, or test your app without commitment.

3. The address is role-based. info@company.com is a real inbox shared by a team. noreply@company.com likely discards everything. admin@company.com probably goes to an ops rotation. These aren't personal addresses — they're organizational ones. Sending transactional or marketing email to role inboxes leads to low engagement and higher unsubscribe rates because nobody "owns" the address.

4. The domain exists but the mailbox doesn't. SMTP probing — actually connecting to port 25 and issuing a RCPT TO command — can answer this question. But most mail servers are configured to accept any address at the gateway and bounce later (a technique called catch-all), specifically to defeat probing. And most cloud providers block outbound port 25 entirely, so your probe never even reaches the server.

What you can actually do

Given those constraints, a practical validation pipeline looks like this:

1. Parse the syntax — not just a regex, but a proper RFC 5322 parse. This catches malformed addresses and normalizes the format.
2. Look up MX records — a DNS query confirms the domain has at least one mail exchanger. This is fast (<100ms), cheap, and reliable. It rejects typos like gmial.com and abandoned domains.
3. Check against a disposable domain list — a maintained list of throwaway services. Mailinator, Guerrilla Mail, Trashmail, and several hundred others. This is a blocklist problem, not a detection one.
4. Flag role-based prefixes — a simple match against known generic prefixes: admin, info, noreply, support, billing, etc. Flag rather than block — some legitimate users do sign up with a shared inbox. Steps 1–3 give you a reliable answer. Step 4 gives you a signal. Together, they catch the vast majority of addresses that will cause you problems.

The code

The Tickstem verify SDK runs all four checks with one call:

import "github.com/tickstem/verify"

client := verify.New(os.Getenv("TICKSTEM_API_KEY"))

result, err := client.Verify(ctx, email)
if err != nil {
    // handle quota or network error
}

if !result.Valid {
    // result.Reason explains why: "invalid syntax", "no MX records found for domain",
    // or "disposable email domain"
    return fmt.Errorf("email not accepted: %s", result.Reason)
}

if result.RoleBased {
    // your call — warn the user, or log and proceed
}

The result is stored in your account history so you can audit it later. The API never probes the mail server — no port 25 calls, no contact with the recipient's infrastructure.

When to validate

At sign-up — block disposable and invalid addresses before they enter your system. A user who can't sign up with a throwaway address either provides a real one or leaves. Both outcomes are better than a list full of ghost accounts.

Before a bulk send — scrub your list against the API if it was collected through a form that didn't validate at the time. Sending to a high percentage of invalid addresses is the fastest way to get flagged by Gmail and Outlook's filtering algorithms.

At re-engagement — if an address hasn't opened anything in 90 days, re-verify before sending. MX records disappear. Domains get abandoned. What was valid a year ago may not be now.

On SMTP probing: Some services advertise mailbox-level verification via SMTP. In practice, catch-all servers make the result unreliable, port 25 is blocked on most cloud providers, and the latency (300ms–3s per check) makes it unsuitable for sign-up flows. MX + disposable + role-based covers most of what matters in production.

Try it

The verify API is available on all Tickstem plans. The Free tier includes 500 verifications per month.

Go: go get github.com/tickstem/verify.
Node.js: npm install @tickstem/verify.
Python: pip install tickstem.