An address can follow every syntax rule and still never receive a single message. The format says nothing about whether the mailbox exists. An email address is valid when it passes three checks in order: a format that matches RFC 5322, a domain with an MX record that accepts mail, and a mailbox that actually exists at the provider. The last two protect you from a hard bounce, and only the last one catches a deleted mailbox on a working domain. No test guarantees the result at 100%.
This guide lists the format rules and compares five ways to verify an address. It then shows how to read a verification tool’s verdict, and where that verdict stops being reliable. If you want to know why the validity of email addresses matters on the sender side, a separate article covers the stakes.
Three levels of checking for three kinds of error
- Format: john.smith@@example.com or john smith@example.com fail here. This is the classic typing mistake.
- Domain: john@example-closed.com has a flawless format, but the domain no longer exists or no longer receives mail.
- Mailbox: mary.jones@company.com passes the first two checks even though she left the company and her account was deleted.
Neither a regular expression nor a DNS query can see the third level. Only the receiving server knows whether the mailbox exists, which is why every serious check relies on the SMTP dialogue (RFC 5321).
RFC 5322 format rules
RFC 5322 (October 2008) describes the structure of an address, including the “dot-atom” form in section 3.2.3. RFC 5321 (October 2008) sets the maximum lengths in section 4.5.3.1: 64 octets for the local part (before the @), 255 for the domain and 256 for the full path between angle brackets, which leaves 254 characters for the address itself, according to the SMTP specification published by the RFC Editor. Here are the rules to apply by hand or in a form.
- One @ only, separating the local part from the domain. john@@example.com has two and fails.
- Local part: letters, digits and the symbols ! # $ % & ‘ * + – / = ? ^ _ ` { | } ~. A dot is allowed as long as it does not start the local part, does not end it and is never doubled.
- The + sign is valid: john+newsletter@example.com really exists. A form that rejects it turns away compliant addresses.
- A subdomain is valid: john@mail.example.com.
- A plain address cannot contain spaces or parentheses.
The syntax and structure of an address under the RFC are covered separately. A syntactically correct address is still a hypothesis, since it proves nothing about the server.
Five checking methods compared
The table shows what each method detects and what it misses.
| Method | Level checked | What it detects | What it misses |
|---|---|---|---|
| Syntax (RFC 5322) | Format | Missing @, space, forbidden character, dot at the end of the local part | Nonexistent domain, missing mailbox, plausible typo (gmial.com) |
| DNS query on MX records | Domain | Unregistered domain, domain with no receiving server | Deleted mailbox, spam trap, catch-all |
| SMTP dialogue (EHLO, MAIL FROM, RCPT TO) without sending | Mailbox | Mailbox refused by the server (code 550 5.1.1), unreachable server | Catch-all, servers that answer 250 and reject later, spam trap |
| Confirmation email (double opt-in) | Mailbox and consent | Address that receives mail and is read by its owner | Disposable address still active, a third party who clicks the link |
| Verification tool | All three, with a verdict | Combines syntax, MX, SMTP and signals such as disposable domains | Whatever the server hides: the result stays a probability |
Manual check, step by step
A one-off check can be done from a terminal, with a test message as a last resort.
- Check the format against the rules above.
- Query the MX records: nslookup -type=mx example.com on Windows 10 or 11 and dig MX example.com on macOS or Linux. For gmail.com, the answer contains gmail-smtp-in.l.google.com with priority 5: a list of servers ranked by priority means the domain receives mail. With no MX record, section 5.1 of RFC 5321 falls back to the domain’s A record, so an empty result does not always condemn the domain.
- Talk to the server: open an SMTP session on the first MX, send EHLO, then MAIL FROM, then RCPT TO with the address under test. Read the return code, then quit without writing a message. 4xx codes are temporary refusals, 5xx codes are permanent ones. A 250 (code 2.1.5 in RFC 3463, published in January 2003: destination address accepted) means the mailbox is accepted. A 550 5.1.1 (the RFC 3463 enhanced status code for a nonexistent destination address) means mailbox not found: Gmail then answers “550-5.1.1 The email account that you tried to reach does not exist”. Outbound port 25 is often closed by internet providers, which blocks the exercise from a home computer. The SMTP protocol and its reply codes are detailed in another article.
- Send a test message if you have a legitimate reason to contact the person. A bounce (NDR) comes back within minutes when the mailbox does not exist.
This routine does not scale. Beyond a handful of addresses, online validation services automate the three checks. They also flag disposable addresses.
Reading a verification tool’s verdict
Most tools return one of three verdicts.
- Valid: the server accepted the address during the SMTP dialogue. Sending carries no particular hard bounce risk.
- Invalid: wrong format, domain with neither MX nor A record, or mailbox refused with a 5.1.1 code. Sending would produce a hard bounce, so remove the address from the list.
- Risky: the test cannot settle it. Typical cases are a catch-all domain, a server that stalls with a 4xx code (deferral), a full mailbox or a disposable address.
A “risky” verdict calls for a decision on your side. An address from a recent signup form deserves a double opt-in. An address from a purchased file, or one two years old, deserves no send at all.
Where tests fall short: catch-all and spam traps
A catch-all domain answers 250 to any address, including qwertyuiop@example.com. The SMTP dialogue then tells you nothing about the mailbox. Tools file these addresses under risky.
A spam trap behaves like a normal mailbox. It accepts mail and passes every test. Traps are either old abandoned mailboxes that a provider recycled, or addresses created to catch senders who collect contacts without consent. Neither a DNS check nor an SMTP dialogue can tell them from a real address. Only clean collection habits avoid them: a double opt-in and the removal of inactive contacts. Sending to a trap exposes you to a blacklist.
Some servers answer 250 during the dialogue and send back an NDR a few minutes later.
Spotting a fraudulent address
An address can be valid and malicious. Read the domain after the @ up to the last dot: service@bank-example.com.ru belongs to the .ru domain, whatever bank name comes before it. A single swapped letter in the domain (paypa1.com) gives away a phishing attempt.
In your mail client, open the full headers of the message and compare the displayed address with the Return-Path header. A mismatch is a sign of spoofing, which the SPF, DKIM and DMARC results in the same headers will confirm.
Block bad addresses at signup
Blocking an address at the door costs less than removing it later. Validation in real time on the form fixes obvious typos. A double opt-in confirms that the mailbox exists and that its owner asked to subscribe, which cuts invalid addresses and fake signups. A captcha limits automated registrations. Regular list cleaning then removes the addresses that have gone dead since.
For an existing database, run a sample through an email list verification tool before the next campaign and compare the hard bounce rate with your previous send. Dead addresses hurt deliverability: Gmail asks senders to stay under a 0.3% spam complaint rate, and Yahoo applies the same ceiling to bulk senders (Google guidelines, in force since February 2024).
Frequently asked questions
Can you verify an address without sending it an email?
Yes. The DNS query on MX records checks the domain. The SMTP dialogue queries the mailbox without transmitting a message. Catch-all domains and servers that accept everything limit the reliability of the second step.
Is a valid address necessarily active?
No. Valid means the server accepts the address. Its owner may not have opened that mailbox for months, which hurts engagement without causing a bounce.
How do you verify a whole list?
Manual checking covers a few addresses. Beyond that, a tool automates the checks and assigns a status to each row. Test five addresses first whose real status you know, and compare them with the verdict displayed.
