A Valid Email Address Can Still Bounce. Here Are the Three Layers of Validation and What Each One Catches.
A syntactically valid email address can still bounce. This is the fact that most email validation systems are not built to acknowledge, because it complicates the clean story of pass-or-fail validation. Understanding why it happens requires knowing what email address validation actually checks, and what it cannot.
Email address format is governed by RFC 5321, the specification for the Simple Mail Transfer Protocol published in 2008. Under RFC 5321, a valid email address consists of a local part before the at sign and a domain part after it. The local part can be up to 64 characters. The domain can be up to 255 characters. The total address cannot exceed 254 characters.
To understand why validation has these specific limits and rules, it helps to know where email addresses came from.
Ray Tomlinson and the At Sign
Electronic mail in some form existed before Ray Tomlinson's work in 1971. Users on time-sharing computers could leave messages for other users on the same machine, using programs like SNDMSG on the TENEX operating system. What did not exist was a way to send messages to users on a different computer connected to the same network.
Tomlinson was a computer programmer at Bolt Beranek and Newman, the company that developed the ARPANET, the precursor to the internet. In 1971, he adapted the SNDMSG program and combined it with source code from CPYNET, a file transfer program, to enable sending messages to users on different machines over the network. To specify which machine a user was on, Tomlinson needed a separator between the username and the machine name.
He chose the @ sign. He picked it because it was rarely used in ordinary text and already meant "at" in commercial accounting contexts (indicating price per unit, as in "10 items @ $2 each"). The symbol was present on the keyboard of the Model 33 Teletype he was using. Tomlinson's choice of @ was not the result of a committee decision or a formal specification. He later described it as seeming obvious. The first email he sent was a test message to himself, sent between two terminals sitting next to each other but connected through the ARPANET.
SMTP and the Specifications That Govern Email
The Simple Mail Transfer Protocol, which defines how email is transmitted between servers, was formally specified in RFC 821, published in August 1982. Jonathan Postel authored the specification. RFC 821 introduced the core SMTP commands that remain in use today: HELO (the server greeting), MAIL FROM (the envelope sender), RCPT TO (the recipient), DATA (the message content), and QUIT.
RFC 822, published the same year by David Crocker, specified the format of the email message itself, including the header fields: From, To, Subject, Date, and others that appear at the top of every email.
The Three Layers of Email Validation
Email validation operates at three levels, each of which catches a different category of error.
Syntax validation checks whether the address conforms to RFC 5321's format rules. An address that fails syntax validation will be rejected by mail transfer agents universally. This check catches obvious errors: missing at signs, illegal characters in the local part, domain names without a top-level domain, addresses that are too long, and empty local or domain parts.
RFC 5321 allows more characters in the local part than most people realize. A single-character local part is valid. Plus signs and hyphens are allowed. Periods are allowed but cannot be at the start or end and cannot appear consecutively. Quoted strings allow spaces and other characters that would otherwise be illegal. The technical specification is more permissive than most validation implementations: some valid email addresses (user+tag@example.com, "user name"@example.com) are rejected by validators that apply overly strict rules.
Domain validation checks whether the domain portion of the address exists and has valid DNS records. An email addressed to user@nonexistentdomain.example will pass syntax checks but fail domain validation because the domain does not resolve. A complete domain validator also checks for MX (mail exchange) records, the DNS entries that specify which mail servers accept messages for that domain. A domain with valid A records but no MX records will typically not accept email.
Mailbox validation checks whether the specific mailbox exists on the mail server. This requires connecting to the mail server via SMTP and issuing RCPT TO commands without actually sending a message, a technique called SMTP probing. Many mail providers have disabled this mechanism because it was used for address harvesting: spammers connected to mail servers and issued RCPT TO for thousands of addresses, keeping only those that returned a success response.
Gmail, Outlook, Yahoo, and most major email providers respond with success to all RCPT TO queries regardless of whether the specific address exists. This means that for addresses at major providers, which constitute the majority of email addresses worldwide, mailbox-level validation is unreliable. The only way to confirm that a specific address at Gmail actually receives mail is to send a message and wait to see if it bounces.
Common Patterns That Validation Misses
Role addresses like info@, support@, sales@, and contact@ are valid addresses that often route to shared inboxes monitored by multiple people or automated systems. For transactional email that needs to reach a specific individual, role addresses provide no guarantee that any particular person will see or respond to the message. Some mailing list best practices exclude role addresses from marketing sends because engagement rates are low and abuse reports are high.
Disposable email addresses from services like Mailinator, Guerrilla Mail, and hundreds of similar providers are syntactically valid and often have functioning MX records. They accept messages and provide temporary access to the inbox. Users who register with disposable email addresses are typically not engaged customers, and lists with high rates of disposable addresses see poor long-term deliverability.
Subaddressing, also called plus addressing or tag addressing, allows users to create unique variants of their email address by adding a plus sign and arbitrary text after the local part: user+newsletter@example.com delivers to the same mailbox as user@example.com. Many email validators used to incorrectly reject plus signs in the local part, which caused valid addresses to fail registration on websites. RFC 5321 explicitly permits plus signs.
Why Email Bounce Rates Exist Even After Validation
Email lists degrade over time regardless of initial validation quality. Studies of email list decay suggest that approximately 22 to 25 percent of email addresses become invalid each year, primarily because people change jobs, switch email providers, or abandon accounts. A list validated at signup and never re-validated will have substantial invalid addresses within two to three years.
Hard bounces occur when an email cannot be delivered at all: the address does not exist, the domain does not exist, or the server permanently rejected the message. ISPs and email service providers track hard bounce rates. Accounts that generate consistently high hard bounce rates may be suspended, because high bounce rates signal either poor list quality or spamming behavior.
Soft bounces occur when delivery fails temporarily: the recipient's mailbox is full, the server is temporarily unavailable, or the message was too large. Most email service providers retry soft bounces for a period before converting them to hard bounces.
Conclusion
Ray Tomlinson's 1971 decision to use @ to separate username from machine name created the format that Postel's 1982 SMTP specification formalized and that RFC 5321 governs today. The format rules are specific, the validation layers are real, and the gap between "technically valid" and "will actually deliver" reflects the complexity of a system that has grown from ARPANET to billions of daily messages over fifty years.
Email validation confirms format and, in most cases, domain existence. Whether a specific address receives mail can only be confirmed by sending a message. ToolHQ's email validator checks syntax and domain DNS records, identifying the most common categories of invalid addresses before they enter your system.
Frequently Asked Questions
Why can a valid-looking email address still bounce?
Syntax validation only checks format rules. An address can pass format checks but still bounce if the domain has no mail server, the mailbox is full, or the account was deleted after the address was collected.
What are MX records in email validation?
MX records are DNS entries that specify which mail servers accept messages for a domain. If a domain has no MX records, email sent to that domain cannot be delivered, even if the format is correct.
Can email validators confirm if a specific mailbox exists?
Not reliably. Major providers like Gmail and Outlook block SMTP verification queries that check mailbox existence, returning success for all queries to prevent address scraping.