Yes. An email address with a plus sign in its local part can be valid. Don’t reject it or remove the tag just because it contains +. Check the complete address: valid syntax alone does not establish that the receiving server accepts it.
For a form or API integration, the practical rule is to keep the address the person gave you. A rewrite from Alex+orders@example.com to Alex@example.com changes the recipient you check and the contact address you store.
What the plus sign means
In plus addressing, a tag is added before the @. With Alex+orders@example.com, the local part is Alex+orders and the domain is example.com. A supporting mail system can route this tagged address to the same mailbox as Alex@example.com.
That behaviour depends on the receiving system. RFC 5233 describes subaddress encoding as specific to the site or implementation. A visible + does not tell your application how an arbitrary domain interprets the address.
Exchange Online enables plus addressing by default, and an organisation can disable it. Check the receiving provider’s configuration when support matters. See Microsoft’s plus-addressing documentation.
All addresses in the examples here are synthetic and use reserved example domains. They illustrate handling, not working mailboxes.
Allow the character, then validate the whole address
The unquoted local-part grammar permits +. It still has other constraints; allowing this character does not make every string valid. RFC 5322, section 3.2.3.
For example, the current Emvero parser accepts the structure of Alex+orders@example.com but rejects Alex..orders@example.com. The error in the second address is the consecutive dots. The email syntax rules cover those wider constraints.
If your form rejects the first address, inspect the frontend validator and the backend parser. A whitelist that permits only letters, digits, dots, underscores and hyphens in the local part excludes + before verification can even begin.
Keep format validation separate from the evidence collected later. The comparison of syntax validation and SMTP verification explains what each method can establish.
Preserve the local part when you normalise the domain
The destination defines the local part’s meaning, and SMTP clients must preserve its case. Domain names are case insensitive. RFC 5321, sections 2.3.11 and 2.4.
For a general-purpose integration, preserve the local part’s case, dots and plus suffix. Don’t borrow one provider’s alias rules and apply them to every address.
Emvero’s current parser allows ordinary plus-tag syntax, retains the local part and normalises the domain. The expected handling of this synthetic input is:
| Input or component | Value |
|---|---|
| Submitted address | Alex+orders@EXAMPLE.COM |
| Preserved local part | Alex+orders |
| Normalised domain | example.com |
| Address used for the check | Alex+orders@example.com |
Checking the untagged version would answer a different question. Even if both addresses reach one inbox, your application would lose the person’s chosen contact address and tag.
Check whether form encoding changed + into a space
In application/x-www-form-urlencoded data, parsing converts a literal + into a space. Proper serialisation encodes the plus as %2B. WHATWG URL Standard.
Use a serializer to construct the value rather than concatenating a query string:
const email = "Alex+orders@example.com";
const body = new URLSearchParams({ email });
console.log(body.toString());
console.log(new URLSearchParams(body.toString()).get("email"));
The output is:
email=Alex%2Borders%40example.com
Alex+orders@example.com
Compare the field value with the value your backend receives. If the latter is Alex orders@example.com, inspect the encoding step before blaming the validator. Fix the serializer; replacing every space with + after decoding would conceal malformed input.
For an Emvero request, send JSON to POST /v1/verifications from your backend. The request body can retain the complete address:
{
"email": "Alex+orders@EXAMPLE.COM"
}
Keep API credentials on the server.
Verify the tagged address and confirm mailbox control
A plus sign alone does not establish mailbox existence, a disposable provider or a duplicate account. Verify the full submitted address and read the returned action and reason_codes. The recommendation can be allow, allow_with_email_confirmation or reject, depending on the evidence.
If the result is unknown, the available evidence did not settle the address. If it is pending, the work is still incomplete. Neither justifies a permanent refusal merely because the address contains a plus sign.
When account access depends on mailbox control, send your own confirmation message to the complete address. Emvero verification does not send that message or prove who controls the mailbox. The signup-form validation guide places verification and confirmation within the wider flow.
The comparison of address verification and mailbox confirmation shows why their results should be stored separately.
Keep duplicate-account policy separate from contact data
Removing a tag is a poor universal identity rule. You may merge addresses that a receiving system treats differently, and aliases alone cannot establish whether two signups belong to one person.
If your product needs to group confirmed addresses under a policy for a known provider, keep that grouping separate from the address used for contact, confirmation and recovery. Don’t overwrite the contact value or automatically merge accounts. The trial-abuse guide explains what email evidence can contribute to that decision.
Before changing the validator, add regression cases for the complete path through your application:
Alex+orders@example.comsurvives validation, transmission and storage with its local part intact.Alex+orders@EXAMPLE.COMcan have its domain normalised without rewritingAlex+orders.Alex..orders@example.comis still rejected for malformed syntax.- A form-encoded round trip preserves
+, and no account is merged merely because a tag was removed from a comparison value.
Connect the email verification API to check the address after your backend has received it intact.