Email verification explained: what a check can and cannot tell

What verification is for

Before a company emails a list of contacts, it often wants to know which addresses will work. Every address that does not exist produces a bounce, and many bounces damage the sender's reputation. Email verification means checking addresses before sending.

A check can rule a lot out. What it cannot do is promise that an email will arrive, that the right person reads it, or that sending is allowed. This guide walks through the checks one by one, from the easy and certain to the hard and uncertain.

The checks, from simple to hard

1. Syntax

Is the address written in a valid form? One @, a part before it (the local part) and a domain after it, no spaces, no forbidden characters.

• anna.berger@northwind.example is fine.

• anna.berger@@northwind.example and anna berger@northwind.example are not.

The rules (RFC 5322) allow more than most people expect, for example a plus sign (anna.berger+news@northwind.example). A good checker is strict about real errors and relaxed about unusual but valid forms.

2. Does the domain exist?

The checker asks DNS, the internet's directory, whether the domain exists at all. A domain that does not exist can never receive mail. This also catches many typo domains: jonas.klein@nortwind.example, with a missing "h", will bounce if nobody owns that domain. If someone does own it, the email goes to a stranger, which is worse.

3. MX records: is anyone receiving mail?

An MX record names the servers that accept email for a domain. You can look them up with the Mailbox Provider Checker. No MX record usually means no mail, with two details: by the SMTP rules (RFC 5321) a sender then tries the domain's normal address record instead, and a special "null MX" record (RFC 7505) says outright that the domain accepts no email.

4. The SMTP mailbox check

Now the checker asks the receiving server about the mailbox itself. It starts a normal SMTP conversation, names the recipient, reads the answer and hangs up before sending any message. The lines from the client (C) and server (S) look like this:

S: 220 mx1.northwind.example ESMTP ready
C: EHLO checker.example
S: 250 mx1.northwind.example
C: MAIL FROM:<probe@checker.example>
S: 250 2.1.0 OK
C: RCPT TO:<anna.berger@northwind.example>
S: 250 2.1.5 OK
C: QUIT
S: 221 2.0.0 Bye

A 250 answer to RCPT TO suggests the mailbox exists; "550 5.1.1 User unknown" says it does not. (The bounce exercise explains these codes.) This sounds precise. In practice it is the least reliable step:

• Catch-all domains (also called accept-all) accept every address at this stage, real or invented, and sort the mail out later. The check cannot tell anything.

• Greylisting answers unknown senders with a temporary "try again later" (4xx). The result is simply unknown.

• Filters in front of the mailbox. Many companies run a security gateway that accepts the address first and only later finds out the mailbox does not exist. A bounce can still follow.

• Protection against address harvesting. Some providers give the same answer for every address, or block and slow down connections that ask about many addresses, because spammers use exactly this method to guess valid addresses.

• Risk for the checker. A server that probes thousands of addresses can end up on a blocklist itself.

• It is a snapshot. An address that exists today may be closed next month when the person leaves.

The old SMTP command VRFY, meant to ask "does this user exist?", is switched off on most servers for the same reasons.

5. Role addresses

Addresses such as info@, sales@, office@ or support@ belong to a function, not a person. They usually work, but a team shares them, they are read irregularly and nobody in particular feels addressed. For a general enquiry they are fine; for a personal message, look for the right person. Note: a role address is often not personal data under the GDPR, but the email marketing rules of the country still apply.

6. Disposable addresses

Some services hand out temporary inboxes that disappear after minutes or days. They matter mostly for sign-up forms, where people use them to avoid giving a real address. Checkers compare domains against lists of known disposable services, and those lists need constant updating.

Result categories

Most verifiers sort addresses into four groups. Names differ from tool to tool; the meaning is similar.

Worked examples

All four addresses are invented.

1. anna.berger@northwind.example. Syntax fine, domain exists, MX records found, the server answers 250 to RCPT TO. Valid. It only means the mailbox accepts mail today.

2. jonas.klein@nortwind.example. The domain does not exist. Invalid. It is probably a typo for northwind.example, but the right address must be confirmed, not guessed.

3. k.weber@contoso.example. MX records found, the server answers 250. The checker then tests an invented address, x7q2-nobody@contoso.example, and it is accepted too. Catch-all. The 250 for k.weber means nothing.

4. sales@fabrikam.example. Valid, and a role address. Good for "Who is the right contact for warehouse equipment?", not for a personal pitch.

Verification is not consent

A valid address tells you that mail can be delivered. It tells you nothing about whether you may send it.

• It is not consent and not a lawful basis under the GDPR.

• It does not change the email marketing rules: in Germany, for example, advertising emails generally need prior consent, also between businesses.

• It does not make a bought list legal or wanted.

• It says nothing about whether the person still has the role you think they have.

The lesson on cold email and the law covers the rules.

Common mistakes

• Treating "valid" as valid forever. People leave jobs; see the worksheet on contact data decay. Re-check old lists before using them.

• Counting catch-all as valid. A catch-all result is "we cannot know", not "yes".

• Guessing addresses and "verifying" them. Trying firstname.lastname@ patterns until one is accepted fails on catch-all domains, and it does not create any right to send.

• Probing from your own mail server. It can put your own sending reputation at risk.

• Deleting every role address. Sometimes info@ is the only and the right way into a small company.

• Using verification to rescue a bad list. It removes some bounces; it does not remove spam traps reliably, complaints or legal problems.