To check if an email address is valid, start with its format, then confirm the domain exists and has an inbound mail route. Add disposable, role, catch-all, and available SMTP recipient evidence before choosing a result. No single pre-send check can guarantee that a message will be delivered.
A valid result means the available evidence supports using the address. It does not prove who owns the address, whether the person consented, or whether every future message will reach the inbox.
What can be checked without sending an email?
- Syntax: Confirm that the local part, at sign, and domain form a plausible address. This catches missing domains, spaces, and malformed input.
- Domain and MX: Resolve the domain and its mail exchange records. A domain with no usable inbound mail route cannot normally receive email.
- Domain risk: Identify disposable providers and other known domain signals. A disposable address can work now and disappear later.
- Address type: Flag role addresses such as
sales@andsupport@. They may be legitimate, but often represent a team rather than one person. - Catch-all behavior: Test whether the server appears to accept any recipient. That behavior prevents a checker from proving the target mailbox.
- SMTP evidence: When permitted and available, ask the receiving server whether it will accept the recipient. A clear permanent rejection is useful evidence. An acceptance can still be ambiguous.
Why syntax alone is not email validation
person@example.com has a valid shape, but the domain or mailbox may not exist. A browser form can use syntax validation to improve data entry, but a full email verification workflow needs domain and mail routing evidence too.
Use the MX lookup tool when you want to inspect the domain route directly. An MX result describes the domain, not the existence of a specific recipient.
Can SMTP prove that a mailbox exists?
Sometimes a server clearly rejects an unknown recipient, but many providers conceal mailbox information, defer requests, rate limit probes, or accept recipients at a gateway and decide later. A 250 response therefore does not always prove that the target mailbox exists.
A catch-all domain is the clearest example. It accepts a random control address as well as the target address, so the target cannot be distinguished at that point. Read the catch-all email guide for handling options and SMTP response codes explained for the difference between temporary and permanent responses.
How to read Mailthentic results
| Status | What it means | Practical action |
|---|---|---|
| Valid | The available checks support the address and did not expose a disqualifying signal. | Keep it if you also have a lawful purpose and valid consent. |
| Invalid | Syntax, the domain, mail routing, disposable-domain data, or clear recipient evidence failed. | Correct an obvious typo or suppress the address. |
| Risky | A role, catch-all, or other risk signal needs a policy decision. | Segment it and use source, consent, and engagement evidence. |
| Unknown | The server deferred, timed out, hid the answer, or could not be reached. | Retry later. Do not convert a temporary result into invalid. |
Should you send a test email?
Do not send an unsolicited test message merely to see whether it bounces. A message is appropriate when the recipient asked for it, such as a double opt-in confirmation, password reset, or transactional notice. Double opt-in can prove control of an address, but it is a consent workflow rather than a silent verification technique.
Check one address, a list, or an application event
Use the free email checker for a DNS-level view of one address. It checks syntax, domain, MX, provider, authentication, and disposable-domain signals without claiming mailbox certainty.
For a permission-based CSV or XLSX file, use the bulk email verifier. Developers can create asynchronous jobs through the email verification API. In every workflow, keep risky and unknown separate from clearly invalid records.
Verification, validation, and ownership
Email validation and email verification often name overlapping checks. A useful working distinction is that validation checks whether input and domain evidence are plausible, while verification adds risk and available recipient evidence. This is not a universal industry definition. Neither process proves who controls an address. Use a confirmation message when account ownership or consent must be established.
Choose the workflow that matches the input
| Input | Workflow | Important limitation |
|---|---|---|
| One address | Run the free checker for syntax and domain signals. | The public check is DNS-only and cannot confirm a mailbox. |
| CSV or XLSX list | Create an asynchronous bulk job and export separated results. | Only permission-based records should enter a sending workflow. |
| Signup or CRM event | Create an API job, poll it, and apply your policy. | The API is asynchronous, so the product must handle pending and unknown states. |
What verification cannot guarantee
- That the person submitting the address owns it or consented to marketing.
- That an accepted recipient response proves a mailbox behind every provider or security gateway.
- That the mailbox will remain active after the check.
- That the sender, authentication, content, reputation, and traffic pattern will satisfy the receiver.
- That a future message will be delivered or placed in the inbox.
Read how no-send verification works, then use the status decision table instead of collapsing uncertainty into a yes or no answer.
Ethical and privacy considerations
Verification should support data that your organization has a lawful reason to process. Do not use it to justify scraped or purchased lists. Store only the evidence needed for the decision, protect API keys, disclose lead storage where applicable, and give recipients a clear consent and unsubscribe path.
Check the evidence behind an address
Check one email address, then choose bulk or API verification when the input changes.
Ready to verify your email list?
Start free with 50 verification credits. No credit card required.