Email verification vs email classification

Email verification tells you whether an address can receive mail. Email classification tells you what kind of address it is: a work address on a company domain, a personal mailbox at a shared provider, a disposable inbox or a privacy relay. They answer different questions, so a deliverable address can still be the wrong kind for your product, and a work address can still bounce. Most teams need a little of each, at different points.

Two questions, two answers

Verification is about reachability: will a message to this exact address be accepted? Classification is about identity: what is behind this domain, and does it tell you anything about a company?

The difference is easiest to see where the answers disagree:

Address	Verification says	Classification says
`jane@gmail.com`	Deliverable	Personal (shared provider)
`x7k2@<temp-mail service>`	Deliverable, for now	Disposable
`k3x9p2@privaterelay.appleid.com`	Deliverable (forwards to a hidden inbox)	Relay
`jnae@acme.io` (name mistyped)	Mailbox not found	Business
`info@acme.io`	Deliverable, flagged as a role address	Business, role account

Neither column is wrong. A Gmail address really is deliverable, and acme.io really is a company domain, even if nobody called Jnae works there. They are simply answers to different questions.

How email verification works

Verification tools run a series of checks, from cheap to expensive. Most stop at the first one that fails.

1. Syntax

Is the address well formed? One @, a local part of at most 64 characters, a valid domain, no more than 254 characters in total, no illegal characters. This catches jane@acme and jane.acme.io, but says nothing about whether the address exists.

2. Domain and MX records

Does the domain exist in DNS, and does it publish MX records naming the servers that accept its mail? A domain without MX records can technically receive mail through its address record (the “implicit MX” in RFC 5321), but few real organizations run mail that way. A null MX (MX 0 ., defined in RFC 7505) means the domain accepts no mail at all. You can see any domain’s mail servers with the MX lookup tool.

3. SMTP mailbox probe

This is the step that makes it verification rather than validation. The tool connects to the domain’s mail server on port 25 and starts a normal SMTP conversation, then hangs up before sending anything:

S: 220 mx.acme.io ESMTP
C: EHLO verify.example.com
S: 250 mx.acme.io
C: MAIL FROM:<probe@example.com>
S: 250 2.1.0 OK
C: RCPT TO:<jane@acme.io>
S: 250 2.1.5 OK                  (accepted)
   or: 550 5.1.1 User unknown    (no such mailbox)
C: QUIT

A 250 reply to RCPT TO means the server will take mail for that address. A 550 usually means the mailbox doesn’t exist. A 4xx reply means “try again later”. The older VRFY command was designed for exactly this question, but most servers disable it, so probes use RCPT TO instead.

4. Catch-all detection

Some domains accept mail for any address, whether or not a mailbox exists. To spot them, tools also probe a random address such as x8q2v7k1@acme.io. If that is accepted too, the domain is catch-all (or “accept-all”), and the 250 for jane@ proves nothing.

The result is usually one of a handful of statuses: valid, invalid, accept-all, unknown, and sometimes “risky”. Many services also flag role addresses, known disposable domains and free providers, which is where verification starts to borrow from classification.

Verification runs from cheap checks to a live SMTP probe

Where mailbox probing falls short

SMTP probing is useful for cleaning a list before a campaign, but it is less certain than the word “valid” suggests.

Catch-all domains. A probe can’t tell real mailboxes from made-up ones on a domain that accepts everything.
Accept now, bounce later. Some servers accept every recipient during the conversation and only send a bounce once the message has been processed.
Greylisting. Servers that temporarily refuse unfamiliar senders with a 4xx reply (described in RFC 6647) turn a quick probe into “unknown”.
Blocked probes. Mail servers rate-limit or block IPs that open many connections without sending mail, and many cloud hosts block outbound port 25 by default.
Privacy. Asking a server whether a particular person has a mailbox is a form of user enumeration. Some providers treat it as abuse, and it tells a third party that the person signed up somewhere.
It’s a snapshot. People change jobs. A mailbox that exists today may be gone in six months.

The definitive verification is the oldest one: send an email with a confirmation link. If the person clicks it, the address works and they control it. For sign-ups, that beats any probe.

What email classification answers

Classification doesn’t ask whether jane@ exists. It asks what the domain is, using lists of known providers and the domain’s public DNS: MX hosts, SPF, DMARC, verification TXT records and Microsoft tenant discovery. Because the answer is about the domain, it is fast and cacheable, and it never touches anyone’s mailbox.

These are the categories isBusinessEmail returns in category:

Category	Means	Example
`business`	The organization’s own custom domain	`jane@acme.io`
`personal`	A shared-domain provider: one domain, many unrelated people	`jane@gmail.com`, `jane@outlook.com`
`disposable`	A throwaway inbox, often valid for minutes	temporary-mail services
`relay`	A privacy relay forwarding to a hidden inbox	`…@privaterelay.appleid.com`
`education`	Schools and universities	`.edu`, `.ac.uk`
`government`	Public sector	`.gov`, `.gouv.fr`
`invalid`	Can’t receive mail: bad syntax, no such domain, no MX or a null MX	`jane@acme`
`unknown`	A custom domain with too little evidence to call	a 3-day-old domain with no website

Classification also answers questions verification never asks: whether the company runs Google Workspace or Microsoft 365 (workspace.google_workspace.detected, workspace.microsoft_365.detected), whether the domain is a typo of a big provider (did_you_mean), and whether it imitates one with lookalike characters (is_lookalike). The full mapping is in categories and policies, and how to tell if an email is a business email shows how to do the same checks by hand.

To be clear about our own product: isBusinessEmail is a classification API. It checks syntax and whether the domain can receive mail at all, which is where invalid comes from. It does not connect to mail servers or send RCPT TO probes, so jane@acme.io and jnae@acme.io get the same category. Privacy and data handling explains why. If you need mailbox-level checks, pair it with a confirmation email or a dedicated verification service.

The two overlap only on the first checks

Role accounts: real mailboxes, not people

info@, sales@, support@, admin@, hello@, noreply@: these are role accounts. They usually exist and verify as deliverable. The question is what they mean for you.

For email marketing, several people read the inbox and none of them signed up personally. Many senders leave role addresses out of campaigns for that reason.
For sign-ups, a role account tells you the company, but not who signed up. The account ends up owned by whoever reads the shared inbox that week.
noreply@ is unreachable by design.

isBusinessEmail flags these with is_role_account: true and the reason role_account, without changing the category: info@acme.io is still business. The policy decides what happens next: review under the default b2b policy, block under strict, allow under lenient. A +tag is ignored, so info+news@acme.io is a role account too.

Relay and masked addresses

Privacy relays give people a separate forwarding address for each site. Mail sent to the relay address lands in the person’s real inbox, which you never see. They are popular with privacy-minded people and built into some sign-in flows.

Service	Addresses look like	Notes
Apple Hide My Email (Sign in with Apple)	`…@privaterelay.appleid.com`	Created when a user picks “Hide My Email” while signing in with Apple
Firefox Relay	`…@mozmail.com`	Older aliases use `relay.firefox.com`; premium users can have a subdomain such as `…@name.mozmail.com`
DuckDuckGo Email Protection	`…@duck.com`	Both the personal Duck address and generated private addresses
SimpleLogin	`…@simplelogin.com`, `…@aleeas.com`, `…@slmail.me`	Also works with the user’s own domain
addy.io (formerly AnonAddy)	`…@addy.io`, `…@anonaddy.com`, `…@anonaddy.me`	Also works with the user’s own domain

How each approach sees a relay

Verification usually says deliverable. The relay accepts mail and forwards it for as long as the alias is active.
Classification says relay (is_relay: true, reason relay_service). When someone uses SimpleLogin or addy.io with their own domain, the domain’s MX records point at the relay’s servers, and isBusinessEmail classifies that as relay as well.

One gap to know about: Hide My Email addresses that iCloud+ subscribers create for websites outside Sign in with Apple end in @icloud.com. They look like any other iCloud address, so they classify as personal.

A relay address works, but hides the real inbox

Relay is not disposable

Disposable inboxes are throwaway and anonymous. Relays are persistent and belong to a real person who would rather not share their main address. Treat them as their own category:

Consumer and product-led products usually allow them. A relay user is reachable.
B2B products that need a company identity learn nothing about the employer from a relay, so they ask for a work email instead. That’s why the b2b and strict policies block relays and lenient allows them, while disposable addresses are blocked under every policy.
If you offer Sign in with Apple, some users will arrive with relay addresses by design. Decide up front whether that is acceptable. To email them at all, register your sending domains with Apple; its relay only forwards mail from sources registered in your Apple Developer account.

The disposable email checker reports relays separately from throwaway inboxes, and the disposable email problem explains why lists alone never catch everything.

Why you usually need both

Situation	Verification	Classification
B2B sign-up form	A confirmation email after sign-up	At submit: personal, disposable, relay, typos
Free trial with real costs	Confirmation before the trial starts	Disposable, relay, `+tag` duplicates
Lead scoring and sales routing	Rarely needed	Business vs personal, Workspace or Microsoft 365
Cleaning a list before a campaign	Yes, to cut bounces	Optional, to segment business and personal
CRM clean-up	For contacts you haven’t emailed in a while	A category for every contact and domain

Classify first. It is cheap, instant and doesn’t contact anyone’s mail server, and it tells you which addresses are worth verifying at all. There is little point verifying a disposable inbox you are about to reject. Then verify the addresses you keep, ideally with a confirmation email rather than a probe.

The playbooks for free trial abuse and CRM hygiene show both in practice, and lead scoring by email domain covers the routing side.

Putting it together

At sign-up, classify the address when the form is submitted and act on the recommendation. How to require a work email at sign-up covers the policy and the copy.
Confirm the address with a link before anything expensive happens. That is your mailbox verification.
For existing lists, classify in bulk with the bulk email checker or the batch endpoint, then verify the addresses you plan to email.
Store the category with each contact, so you can segment and measure later.
Try it on a few addresses with the free email checker, or make your first API call with the quickstart.

If you found the address yourself, how to find someone’s business email address covers checking it before you write.

Frequently asked questions

What is the difference between email verification and email validation?

The terms are often used interchangeably. Validation usually means checking the format and the domain, while verification goes further and checks whether the specific mailbox exists, with an SMTP probe or a confirmation email.

Can you verify an email address without sending an email?

Partly. You can check the syntax, the domain and its MX records, and many tools also ask the mail server whether the mailbox exists without sending a message. Catch-all domains and servers that accept every recipient make that answer uncertain, so a confirmation link is the only definitive test.

What is a catch-all email domain?

A catch-all, or accept-all, domain accepts mail for any address at that domain, whether or not a mailbox exists. Verification tools can't confirm individual mailboxes there and usually report them as accept-all or unknown.

Are role-based email addresses like info@ bad?

Not necessarily. Addresses such as info@ or sales@ are real shared mailboxes, but they don't identify a person, so many teams review them at sign-up and many senders leave them out of marketing email.

Are Apple Hide My Email addresses disposable?

No. They forward to the person's real inbox and keep working until the user turns them off. They are better treated as relay addresses, a category of their own, than as throwaway inboxes.

Does isBusinessEmail verify that a mailbox exists?

No. It checks syntax and whether the domain can receive mail, then classifies the address, but it never connects to the mail server or probes for a specific mailbox. Pair it with a confirmation email if you need mailbox-level certainty.