Yes. An email address with an apostrophe can be valid when the character appears before the @. In o'neil@example.com, the name before the @ is the local part; its ordinary ASCII apostrophe is permitted by RFC 5322’s character rules.
If a form rejects this address, find which validation or storage step refuses it. Deleting the character changes the address. Permitted syntax does not establish that a provider offers the mailbox or that it can receive a message.
Check the character and its position
The straight apostrophe ' is U+0027. The curved character ’ is U+2019. They may look similar in a field, but they are different input. The second is outside the ASCII character set used by the ordinary local-part grammar.
| Example | What it tells you |
|---|---|
o'neil@example.com |
The straight apostrophe is allowed in this local-part structure |
o’neil@example.com |
A different Unicode character was entered; check internationalised-address support separately |
o'neil@exam'ple.com |
The domain contains a character that ordinary mail domain labels do not permit |
o'neil..sales@example.com |
Consecutive dots make this unquoted local part invalid |
The SMTP address grammar defines the domain and dot-separated local-part rules. These examples use a reserved documentation domain and do not represent working mailboxes.
Ask the person to confirm their intended spelling if the field contains a curved character. Do not silently replace it or remove punctuation. For other format constraints, see the email syntax reference.
Find where the form rejects the value
Start with the browser field. An HTML <input type="email"> allows the straight apostrophe in the local part. A custom pattern, JavaScript validator or form library can add a narrower rule. The HTML email-input specification defines the browser grammar, which differs from SMTP syntax.
Run this in a browser console to isolate the native format check. It creates a detached input and sends no request:
const field = document.createElement("input");
field.type = "email";
field.required = true;
console.table([
"o'neil@example.com",
"o’neil@example.com",
"o'neil@exam'ple.com",
"o'neil..sales@example.com"
].map(value => {
field.value = value;
return { value, formatAccepted: field.checkValidity() };
}));
The results are true, false, false, true, in that order. The last result shows why the distinction matters: this browser check accepts consecutive dots before the @, although the unquoted SMTP grammar does not. Passing the field check cannot replace server validation.
If the first example passes here but fails in your form, inspect the extra validation rules. If the form accepts it, compare the submitted value with what the server receives. Then check the server’s parser and its error response. The JavaScript form example shows how to give feedback while keeping an independent check on the server.
Keep the address intact through storage and reuse
Once the server accepts the format, check that writing and reading the value preserves the local part. o'neil@example.com and oneil@example.com are different submitted addresses; your application has no basis to treat deletion as a correction.
For SQL storage, bind the address as a parameter through your database driver. Do not concatenate it into a query string. OWASP recommends parameterised queries to separate input data from SQL code. Deleting apostrophes is not a substitute for that separation.
Test each place that reads the saved contact value. Registration can succeed while a later login, profile edit, export or password-reset path applies a different validator. For a reproducible report, record the synthetic input, the step that fails, the error and the value returned after a save and reload. Keep real customer addresses out of the test report.
If a connected service cannot accept the address, explain that limitation and let the person supply an alternative. Do not manufacture an alternative by rewriting their mailbox name.
Verify the address once the input is preserved
Send the preserved address to the email verification API from your server to collect domain and, where available, recipient evidence. Keep API credentials on the server. Emvero preserves the local part rather than removing its punctuation.
An unknown result means the available evidence is inconclusive; pending means the check is unfinished. Neither establishes a permanent reason to reject the address. When your flow needs evidence that the person controls the mailbox, require them to act on a confirmation link or code. The distinction between verification and email confirmation explains why a permitted character and an accepted recipient still leave that question open.