# Email address checker

> Type an email address: the checker tests its format, spots a typo on a common domain and tells you whether the address is disposable, generic or personal. It also tells you, plainly, what it cannot check.

*Canonical: https://derrick-app.com/free-tools/email-address-checker*

The tool is interactive: open the page to use it. It runs in the browser, no signup.

---

## What this email address checker does, and what it does not

This checker answers one precise question: **can the address in front of you work, as it is written?** It tests everything that can be checked without sending anything: the format of the address, a likely typo on a common domain (gmial.com instead of gmail.com), and the type of address (throwaway inbox, generic address such as contact@, free consumer mailbox, business domain).

It does not answer another question: **does the mailbox actually exist today?** That takes a query to the domain's mail server, which a browser cannot do on its own. The result says so every time, in plain words. That is why the tool never returns the word "valid": it returns one of three verdicts.

- **To fix**: the address is malformed (missing @, a space, two dots in a row, no extension) or carries a likely typo on a well-known domain. As it stands, it will receive nothing.
- **Avoid**: the address is written correctly, but its domain belongs to a throwaway inbox service, whose inboxes vanish after a few minutes or days.
- **Plausible, mailbox not verified**: nothing stops the address from working. A good sign, not a proof.

Most online checkers show "valid" or "invalid" without saying what the word covers. Here every check is listed, and the ones that need a server are marked as such. You know exactly what you checked, and what is left to check.

## The 6 checks, from format to mailbox

A complete verifier runs six checks, from the simplest to the most expensive. The first three happen in your browser. The next three need an exchange with servers. Here is what each one checks, and which ones this tool performs.

### 1. Syntax (this tool does it)

An email address follows a fixed shape: a local part, an @ sign, a domain. The local part (before the @) accepts letters, digits and a few signs such as the dot, hyphen, underscore or plus; it cannot start or end with a dot, and two dots cannot follow each other. The domain (after the @) is made of letters, digits and hyphens, separated by dots, and ends with an extension such as .com or .fr. A single format error makes the address unusable: it is the first thing the tool checks.

### 2. The domain and its typos (this tool does part of it)

A well-formed address can point to a domain that does not exist. The most common case is a typo on a well-known mailbox provider: gmial.com, hotmial.com, outlok.com, or a mistyped extension such as .con. The tool compares the domain with the most common providers and suggests the fix when the gap is one letter. It does not confirm that an unknown business domain exists: that needs a DNS query.

### 3. The MX record (needs a server)

To receive mail, a domain must publish an MX record, which says which server accepts its email. A domain without MX receives nothing, even if its website works. This check goes through a DNS query made on a server: the tool marks it "not checked here".

### 4. Catch-all (needs a server)

Some domains accept everything sent to them, whatever the local part: they are called catch-all, or accept-all. On those domains an invented address is accepted like a real one. A serious verifier detects this and labels such addresses "risky" rather than "valid". Our guide to [catch-all domains](https://derrick-app.com/email-finder/catch-all) covers this case.

### 5. The mailbox, over SMTP (needs a server)

This is the only check that tells you whether the mailbox exists. The verifier opens a conversation with the domain's mail server, names a recipient, then stops before sending any message. The server answers that it accepts that recipient, or that it does not know it (code 550 is the most common answer for a mailbox that does not exist). No email reaches the recipient.

### 6. Other signals (this tool covers two)

What remains are quality signals. The tool flags **disposable addresses** (a reference list of domains plus the naming pattern of those services) and **generic or role addresses** (contact@, info@, support@), which work but belong to no one in particular. It also tells a free consumer mailbox from a business domain. Spam traps can only be spotted with lists kept on a server. For disposable addresses in detail, see our [disposable email checker](https://derrick-app.com/email-finder/disposable-email-checker).

## The typing errors the test catches most often

Most wrong addresses are not invented: they are copied badly. Here are the mistakes that keep showing up in forms, files and hand-copied signatures, and what the test says about them.

- **A missing or doubled @**: jane.doegmail.com, jane@@company.com. The format is rejected, with the reason.
- **A comma instead of a dot**: jane.doe@company,com. A comma is not allowed in a domain: verdict "to fix".
- **A space**, often invisible, stuck at the start or end of an address after a copy and paste, or slipped into the middle: jane doe@company.com. The test ignores spaces at the edges and flags the ones left inside.
- **A mistyped extension**: .con, .cmo or .ocm instead of .com, .frr instead of .fr. None of these extensions exist: the test suggests the right one.
- **Swapped letters on a well-known provider**: gmial.com, hotmial.com, outlok.com, yahooo.com. This is the costliest mistake, because the address looks normal at first glance.
- **An accented character before the @**: rené.martin@company.com. Internationalized addresses exist, but many servers do not accept them; in a business context an accented address is almost always a typing error.
- **Extra dots**: jane..doe@company.com, or a trailing dot after the extension. Two dots in a row make the address invalid.

Capital letters are not a problem: Jane.Doe@Company.com and jane.doe@company.com land in the same mailbox. The test does not flag them.

## How to tell if an email address is valid

The honest answer fits in one sentence: **only a test of the mail server tells you whether an address is valid**, in the sense that it will receive the mail sent to it. Everything else is a filter, useful but incomplete.

In practice you go step by step. Start with this test: it removes malformed addresses, typos and throwaway inboxes, without sending anything and without an account. If the address passes, it is plausible. To go all the way you need a verifier that queries the server (checks 3, 4 and 5 above). And on a catch-all domain even that cannot settle it: the address stays "risky" until a real message is delivered, or bounces.

One habit to avoid: sending a test email to see whether it comes back. If the address does not exist, the bounce counts against the reputation of your sending domain. On a single address the effect is small. Repeated across a list, it adds up.

## Why check an address before you write

A wrong address costs more than one lost message. It produces a bounce, and mailbox providers keep count of each sender's bounces. Past a certain level, they file your emails as spam more often, including the ones going to good addresses. Checking before you send protects all your messages, not only this one.

There is a quieter cost too: time. A follow-up scheduled to a throwaway inbox, a prospecting sequence running on a mailbox that does not exist, a customer account created with gmial.com that will never get its confirmation email. Each time, the error was visible before sending, if someone looked.

Finally, the type of address changes how you write. A generic address such as contact@ is read by someone who sorts mail, not by the person you want to reach. A personal address on a free provider can be perfectly legitimate (a freelancer, a founder), but it is handled differently from a named business address.

## Disposable, generic or personal: what to do with the result

The type of address does not only say whether it works. It also says what to do with it.

- **A disposable address** is useless after a few minutes. If it came through a signup form, the person wanted access without leaving a real address: no point following up. In a prospect list, it does not belong.
- **A generic address** (contact@, info@, sales@) works, but someone sorts the mail before it reaches the right person. For a first sales contact, the named address of the decision maker is better; for an administrative request, it is often the right door.
- **A free consumer mailbox** (gmail.com, outlook.com, yahoo.com) is a real, personal inbox. It is normal for an individual, a freelancer or a founder who signs up with their usual address; in a B2B file, it points to a contact who is not tied to their company.
- **A business domain** is the expected case in prospecting. The test rates it "plausible": whether this person's mailbox exists still needs the server check.

## Who checks their addresses, and why

- **Sales teams** check prospect addresses before a campaign, to protect the sending domain and to know who they are really reaching.
- **Marketing teams** clean their subscriber lists: typos at signup, throwaway inboxes used to download content without leaving a real address.
- **Recruiters** check the address of a candidate or contact before an important exchange.
- **Support and admin teams** catch a customer's mistyped address before an invoice or a password reset email gets lost.
- **Everyone**, when an address is read out over the phone or scribbled on paper: testing it once avoids finding the error three days later.

## Checking a whole list, or at the point of entry

This tool handles one address at a time. For a list the logic is the same at a different scale: check every address before sending, drop the invalid ones, set aside catch-all and risky addresses, then repeat regularly, because a list ages (people change jobs, mailboxes close). Our [email bounce checker guide](https://derrick-app.com/email-finder/bounce-checker) covers the statuses returned and the cleaning rhythm.

Two other situations have their own page. To check addresses as they are typed into a form, see [real-time email verification](https://derrick-app.com/email-finder/real-time-verification). To plug verification into your own tool or CRM, see the [email verification API](https://derrick-app.com/email-finder/verification-api). And if you first need to find an address rather than check it, the [guide to finding business emails](https://derrick-app.com/email-finder) is the place to start.

In Derrick, a list is verified in the web app: import your addresses, run [Email Verification](https://derrick-app.com/features/email-verification), and every row gets its status. If your addresses already live in a spreadsheet, the same verification runs in Google Sheets from the Derrick sidebar.

## When you need to know the mailbox exists

The mail server test runs in the Derrick web app with Email Verification, on one address or a whole list: complete your list, then verify its addresses. Email Verification is not included in the free plan: it is available from the Mini plan (€9 per month), at 1 credit per verified address.

- Web app (main entry, nothing to install): https://app.derrick-app.com
- Free plan: 100 credits per month, no credit card.

## FAQ

### Is an email sent during the test?

No. This test runs entirely in your browser and sends nothing, neither an email nor a request. Even a complete verifier that queries the mail server stops before sending: it asks the server whether it accepts the recipient, then ends the conversation.

### Does the recipient know their address was checked?

No. This test contacts no one. A server-side SMTP check does not drop a message in the mailbox either: the recipient sees nothing.

### How do you check that an email is valid without sending a message?

In two steps. First a check with no network, like the one on this page: format, typo, disposable or generic address. Then a check of the mail server: the domain's MX record, then a question to the server about the mailbox, stopping before any send. Only the second step tells you whether the mailbox exists.

### Email verification or validation: what is the difference?

In everyday use the two words often mean the same thing. When they are told apart, validation is about the form of the address (is it written correctly?) and verification about its existence (does the mailbox receive mail?). This tool does validation and part of the quality checks, not mailbox verification.

### What do "risky" and "unknown" mean in an email verifier?

"Risky" usually means an address that may exist but cannot be confirmed: catch-all domain, disposable address, generic address. "Unknown" means the server did not give a usable answer (slow server, protection against verification, temporary refusal). Neither one is a yes.

### Are my addresses stored?

No. The address you type stays in your browser: it is not sent to any server and is not recorded anywhere. The test is free and needs no signup.