Validate an email address without inventing certainty

Separate three questions, and accept the limit that remains

A signup system may ask whether an address has an acceptable shape, whether the service can handle it and whether the person controls the destination. Those are separate questions, and each one needs its own evidence. A string passing a format check does not demonstrate that a mailbox exists or that a message will reach an inbox.

The HTML email input has a defined syntax check, and a form can also require a value. These browser checks help catch mistakes; they do not replace the server’s acceptance decision. Ask what each check establishes and what it leaves open.

• Shape: the text looks like an address in a form the check recognises. It does not show that the service supports it, that a mailbox exists or that the person typing it controls it.
• Service handling: the chosen service or parser accepts the value under its documented capabilities. It does not show that a mailbox exists or that a message will reach an inbox.
• Address control: a confirmation step was completed, which offers evidence of access to that destination at that time. It does not promise future delivery or verify the other details on the form.
• Delivery and inbox placement: no step described in this guide establishes this. Treat it as a separate subject, covered in the email deliverability guide, and do not promise it in a message.

Validate at the boundary you control

OWASP recommends server-side validation and distinguishes the structure of input from its meaning in the application. Structure asks whether the value is formed acceptably; meaning asks whether the application should accept it for this particular purpose. For a publication, define the address formats supported by the chosen service, use a maintained parser or service interface, and handle an unsupported value with a clear explanation.

Do not treat one improvised regular expression as a complete description of every address the internet might support. Internationalised addresses and domain handling can depend on the chosen service. Document the formats your system supports and test those capabilities, so editors and support staff can explain its limits.

Confirmation shows access, not a lasting promise

Imagine a reader enters an address missing a required part. The interface can identify the address field and explain the correction needed. Once a syntactically acceptable value is submitted, the next message should describe the actual resulting state, such as a confirmation request being prepared or received by the service.

If the publication uses email confirmation, completing that step offers evidence of access to that destination at that time. It still does not promise future delivery or establish that every detail supplied on a form is accurate. See signup confirmation for the wording of those transitions; Mailchimp’s double opt-in documentation shows one service’s version of the step.

Keep contact headers and recipient authority apart from visitor content

A contact form that creates email should use a trusted sender and recipient configuration. Treat an address used for replies as a single parsed value and reject header-control characters. Do not build a From or extra recipient list by concatenating arbitrary form text into a raw message.

Visitor content includes a name, topic and enquiry body; bound it and handle it as text. Headers control the sender, recipient and reply destination. Those fields need separate checks: the publication fixes its sender and recipient, while the visitor’s reply address is parsed as one value.

Message-building libraries provide structured header operations; for example, Python documents EmailMessage as an interface for creating and handling messages. The implementation still needs validation and a review of its intended recipient. A syntactically valid address should not be allowed to choose an unapproved destination for an automated form.

A small test set without real subscriber data

Keep this validation exercise separate from live sending. “reader@example.invalid” is a synthetic specimen, not a delivery destination. Nothing should be sent to it, and the exercise does not need a real person’s address.

• Empty required field: the request is stopped with an explanation at the field.
• Missing part of an address, such as “reader@”: the interface explains the invalid format.
• A syntactically supported specimen such as “reader@example.invalid”: a format test can pass without implying a real mailbox or authorising a send.
• A value containing a line break and an attempted extra header: the server rejects it as an address value.
• A supported address submitted twice after a slow response: the operation follows its duplicate-handling rule rather than assuming a new request.

Test correction, repetition and failure

A useful test set includes an empty required field, a mistaken address, a legitimate supported address and a value outside the service’s documented support. Check that an error does not erase the rest of a carefully written enquiry or incorrectly announce that something was sent.

Also test what happens when a person submits again after a slow connection. The form-review guide covers repeated attempts, and the abuse-controls guide explains why validation alone does not control automated traffic. Validation is one control among several, and the honest message it can give is “this value is acceptable to our system”, never “this person is reachable”.

Walk synthetic specimens through the boundaries

These hypothetical messages show how to report different validation outcomes. No request or send is described as real. For each specimen, identify the check that produced the result and state only what that check established.

• Missing value. Boundary: the required-field check, which the browser can announce and the server should also enforce. Specimen message at the field: “Please enter an email address. Nothing has been submitted yet.” The message says nothing about a mailbox because none was examined.
• Incomplete address, “reader@”. Boundary: shape. Specimen message: “This address looks incomplete. Please check what follows the @ sign; the rest of your answers have been kept.” It names a correction and preserves the entered text.
• Unsupported value. Boundary: service handling. Suppose a value looks well formed to a person but falls outside what the chosen service documents as supported. Specimen message: “This form cannot handle that kind of address. Please try another address, or use the contact page to reach the publisher.” The wording states the system’s limit instead of blaming the reader.
• Header-control attempt. Boundary: trusted headers and recipient authority. A value containing a line break and an extra header line is rejected as an address value. Specimen message: “Please enter a single email address.” The message need not explain the technique, and nothing is composed or sent from the value.
• Repeated request for “reader@example.invalid”. Boundary: the duplicate-handling rule. Suppose the first response was slow, but the system has confirmed that the request is recorded. Specimen message: “We already have this request and are preparing the next step. We cannot say when a message will arrive.” Use that wording only for a known recorded state; a slow response alone does not establish it.
• Uncertain result. Boundary: the operation itself, because the system does not know what happened. Avoid “Sent!”. Specimen message: “We could not confirm that your request was received. Please wait a moment before trying again.” The design question for the team is who owns this state and what the next attempt does.

A hypothetical support question: “I never received the confirmation”

This is another suggested workflow with an invented case. Suppose a reader writes to say that no confirmation arrived. The format check tells the team almost nothing here: it passed, but it never claimed delivery. A more useful sequence asks four questions in order. Was the address accepted under the service’s documented support? What state did the operation record: prepared, received by the service, or uncertain? Was the confirmation step completed, since only that offers evidence of access at that time? And is the next step a delivery investigation rather than another validation rule?

Answering in that order stops a team from adding ever stricter format rules to solve a problem the format check never covered, and it keeps the reply to the reader honest. The email deliverability guide is the place to continue when the earlier questions show the request was handled normally.

A form-review checklist

Use these questions to review the form’s checks, messages and failure states.

• Does each message say which of the three questions was answered, and does it avoid claiming that a mailbox exists or an inbox will receive anything?
• Are the address formats supported by the chosen service written down, and does testing use those capabilities rather than one improvised pattern?
• Does the server make its own decision even when the browser has already shown a hint?
• Are sender and recipient taken from trusted configuration, with the reply address parsed as one value and header-control characters rejected?
• Does a rejected or unsupported value keep the rest of the person’s text and point to the field that needs correcting?
• Is there a defined outcome for a repeated or slow request, and distinct wording for an uncertain result?
• Are all test values synthetic, with live sending kept out of the exercise?
• Is confirmation described as evidence of access at that time rather than as a promise of future delivery?