The email field accepted it. The message never arrived.

A customer is told to fix their email address because a signup form rejects a character. Another customer passes the form, receives a confirmation screen, and never receives the email. These look like opposite validation bugs. They expose the same mistake: treating a text field as proof of successful communication.

An email address participates in several protocols and organizational decisions. Grammar is only the first layer.

The Internet Message Format in RFC 5322^{[1]Internet Message Format in RFC 5322} specifies how addresses and message headers can be represented. SMTP transport has separate requirements. The local part is interpreted by the receiving domain, and its conventions cannot be inferred from a website's regular expression.

Internationalized mail makes the distinction more visible. RFC 6531^{[2]RFC 6531} adds the SMTPUTF8 extension so compatible servers can carry internationalized addresses and headers. Not every hop necessarily advertises the extension. A string allowed by one layer may still be unsupported by a particular route.

First, the entered address may be syntactically acceptable. Second, the server or intermediary may be able to transport to it. Third, some mailbox or handling rule may accept the message. Fourth, the intended person may actually see and understand it. Delivery receipts are not equivalent to human attention, and a returned success message is not a guarantee of inbox placement.

A domain can accept mail for an alias; mailboxes can forward; addresses can change owners or be reassigned. These are reasons not to treat email as a durable person identifier or an irrevocable verification of control.

A better registration flow preserves the exact entered address, attempts permitted delivery, and records the outcome at each stage: requested, submitted, accepted for transport, bounced, confirmed by the current controller or expired. Rate limits and abuse controls matter too: proving someone currently receives a message should not let an attacker repeatedly send unwanted mail.

If the email doubles as a login, treat it as a changeable contact method associated with a separate account subject. A confirmation link should prove possession at that moment, not that the account's legal identity has been established.

Language support is not a flag attached to a form. It may require Unicode-aware input, safe display, normalization policies, server capabilities, error messages, and human support procedures. The most respectful interface avoids rejecting unusual legitimate forms for cosmetic convenience, while being candid about the routes the service can support.

It is tempting to call this an edge case. For the person whose address cannot be entered, it is the whole product. The point of a reliable protocol boundary is not to accept every possible string. It is to distinguish what the software knows from what it merely hopes will work.