What Is an Invalid Email Address?
An invalid email address is one confirmed undeliverable before you ever send to it — malformed syntax, a domain with no mail servers, or a specific mailbox that doesn't exist.
- Category
- Undeliverable address
- Deliverability risk
- Critical
- Recommended action
- Remove before sending
- How a verifier classifies it
- invalid
On this page
Invalid addresses are the cheapest deliverability problem to fix and the most expensive one to ignore. Every invalid address left on a list becomes a hard bounce the moment you send, and hard bounces are what mailbox providers use to judge whether your list was built with permission. This page covers the three layers at which an address can be invalid, why syntax checking catches almost none of it, and how to keep invalid addresses off your list.
What this page covers
- The three layers of invalidity: syntax, domain and mailbox
- Why a regex or format check catches only a fraction of bad addresses
- How verification confirms a mailbox without sending anything
- The difference between invalid, bounced, catch-all and disposable
- Four ways invalid addresses get onto a list, and how to stop each
What is an invalid email address?
An invalid address is one that cannot receive mail. That sounds obvious, but the reason it cannot receive mail matters, because each cause is detected differently and prevented differently. An address can fail at the level of its own format, at the level of its domain, or at the level of the individual mailbox.
Finding them is what email validation is for. When you verify email addresses before a send — rather than discovering the problem afterwards — every address in this category comes off the list at no cost to your sender reputation.
Crucially, invalid is a pre-send classification. The same address that verifies as invalid today would have produced a hard bounce had you mailed it instead — the difference is entirely whether you checked first.
The three layers of invalidity
1. Syntax failures
The string itself could never be a valid address: a missing @, spaces in the middle, an unterminated domain, illegal characters, or two dots in a row. These are caught by a format check and are the easiest to detect — and the rarest in practice, because most signup forms already block them.
2. Domain failures
The syntax is fine but the domain cannot receive mail. It may not resolve in DNS at all, or it may resolve without any MX records, meaning no server is designated to handle its mail. Expired company domains are the most common source, which makes this failure disproportionately common in older B2B lists.
3. Mailbox failures
The syntax is valid, the domain is live and accepting mail, but that specific mailbox does not exist. Only an SMTP-level check finds this, by asking the receiving server directly whether it will accept mail for that recipient. This is where most real undeliverability lives.
| Layer | What is checked | Example | Caught by a format check? |
|---|---|---|---|
| Syntax | The shape of the string | jane@@example..com | Yes |
| Domain | DNS resolution and MX records | [email protected] | No |
| Mailbox | SMTP recipient acceptance | [email protected] — no such mailbox | No |
How verification confirms a mailbox without sending
Verification imitates the opening of a real delivery and stops before anything is actually sent. No message reaches the recipient, and nothing appears in their inbox.
- 1
Check the syntax
Reject anything malformed immediately — this is fast, free, and filters the obvious cases before any network request.
- 2
Resolve the domain and look up MX records
Confirm the domain exists and designates mail servers. No MX records means nowhere to deliver, so the address is invalid regardless of the local part.
- 3
Open an SMTP conversation with the mail server
Connect to the highest-priority MX host exactly as a sending server would, and begin the standard handshake.
- 4
Ask whether the recipient is accepted
The server answers with an accept or reject code for that specific mailbox — the same answer it would give during a real delivery.
- 5
Close the connection before sending data
The conversation ends before any message body is transmitted, so the check is invisible to the recipient.
- 6
Classify the result
Valid, invalid, catch-all, disposable or role-based — with catch-all reported separately because an accept-all server accepts every recipient.
Where invalid addresses come from
Typos at signup
gmial.com, hotmial.com, a missing letter in a surname. Someone genuinely wanted to subscribe and the address they gave does not exist.
People leaving jobs
Work mailboxes are deleted when someone moves on. The largest cause of decay in B2B lists, and completely invisible until you send.
Expired domains
A company folds, the domain lapses, MX records disappear. Every contact you held at that domain is now invalid at once.
Deliberate junk entries
Fake addresses typed to get past a required field on a gated form — often syntactically valid, never real.
3
Layers to check
Syntax, domain and mailbox. Skipping the last two is what leaves bounces on the table.
2%
Bounce rate ceiling
The guideline invalid addresses push you past faster than any other list problem.
0
Messages delivered
Verification completes its SMTP check without transmitting a message body, so nothing reaches the recipient.
Invalid, bounced, catch-all or disposable?
| Term | Can it receive mail? | When you find out | Action |
|---|---|---|---|
| Invalid | No | Before sending | Remove now |
| Bounced | No | After sending | Suppress permanently |
| Catch-all | Unknown — the domain accepts everything | Before sending, inconclusively | Segment and test |
| Disposable | Yes, briefly | Before sending | Remove — it expires within hours |
Find every invalid address before your next send
Pingovo checks syntax, DNS and MX records, and the mailbox itself over SMTP — one pass, and the addresses that would have hard bounced come off the list first.
Verify your list freeHow to keep invalid addresses off your list
Verify at the point of capture
Checking the address while the person is still on your signup form is the only moment you can ask them to correct a typo. Once they have left, a mistyped address is permanently lost data.
Re-verify before major sends
Verification results have a shelf life because lists decay continuously. Any segment you have not mailed in several months should be re-checked before it goes into a campaign.
Never import an unverified list on top of a clean one
A bulk import of old contacts is the most common way invalid addresses re-enter an otherwise healthy list — and it frequently reintroduces addresses that were already suppressed for hard bouncing.
Prefer double opt-in for new subscribers
Requiring confirmation from the mailbox itself proves the address exists and is monitored, which no amount of format checking can establish. It also protects against typo spam traps.
Do this
- Validate addresses in real time on your signup form
- Re-verify ageing segments before each major campaign
- Keep and honour a permanent suppression list
- Use double opt-in where the volume justifies it
Not this
- Rely on a regex or format check as your only validation
- Import old spreadsheets without verifying them first
- Guess at corrections for addresses beyond an obvious typo
- Treat a verification result from last year as current
In Pingovo
Pingovo's two-step check — a DNS/MX lookup followed by a live SMTP mailbox check — exists specifically to move this discovery from after the send to before it.
Frequently asked questions
Any one of three things: the syntax is malformed so it could never be a real address, the domain has no mail servers so there is nowhere to deliver to, or the receiving server confirms that specific mailbox does not exist.
They are usually the same address at different points in time. Invalid means you caught it before sending, through verification. Bounced means you discovered the same failure after sending, with the reputation cost already incurred.
Run a DNS and MX lookup to confirm the domain accepts mail, then open an SMTP conversation with the receiving server and ask whether it will accept mail for that recipient — without ever delivering a message. That is what an email verifier does.
Yes, and this is the common case. Correct syntax proves nothing about whether the mailbox exists — [email protected] is perfectly formed and may still have no mailbox behind it.
No. A regular expression only checks the shape of the string. It cannot tell you whether the domain resolves, whether it has mail servers, or whether the mailbox exists — which is where the overwhelming majority of real undeliverability lives.
People leave jobs and their work mailbox is deleted, personal accounts get abandoned and closed by the provider, and companies fold and let their domains lapse. Lists decay continuously, which is why a verification result has a shelf life.
Yes, directly. Invalid addresses are what produce hard bounces, and bounce rate is one of the clearest signals mailbox providers use when deciding whether to deliver your mail to the inbox or the spam folder.
An invalid address cannot receive mail at all. A disposable address can receive mail right now, but comes from a temporary-mail service and will stop existing within hours. Both should come off your list, for different reasons.
Sometimes, if the cause is an obvious typo — gmial.com for gmail.com, or a missing character. Anything beyond an obvious correction is guesswork, and guessing at addresses is how senders end up hitting spam traps.