---
title: "Email address with a plus sign: validation and storage | Emvero"
description: "A plus sign is valid in an email address's local part. Learn how to preserve the tag through form validation, encoding, verification and storage."
url: https://emvero.io/blog/email-address-with-plus-sign/
language: en
updated: 2026-10-10
---

Blog

# Is an email address with a plus sign valid?

An email address containing a plus sign can be valid. Preserve the complete local part, verify the address that was submitted and handle account policy separately.

Published 2026-09-18

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](https://www.rfc-editor.org/rfc/rfc5233.html#section-4) 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](https://learn.microsoft.com/en-us/exchange/recipients-in-exchange-online/plus-addressing-in-exchange-online).

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](https://www.rfc-editor.org/rfc/rfc5322.html#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](https://emvero.io/glossary/email-syntax/) 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](https://emvero.io/compare/smtp-vs-syntax-validation/) 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](https://www.rfc-editor.org/rfc/rfc5321.html#section-2.3.11).

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](https://url.spec.whatwg.org/#urlencoded-parsing).

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](https://emvero.io/guides/signup-form-validation/) places verification and confirmation within the wider flow.

The [comparison of address verification and mailbox confirmation](https://emvero.io/blog/email-verification-vs-email-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](https://emvero.io/guides/saas-trial-abuse/) 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.com` survives validation, transmission and storage with its local part intact.
- `Alex+orders@EXAMPLE.COM` can have its domain normalised without rewriting `Alex+orders`.
- `Alex..orders@example.com` is 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](https://emvero.io/email-verification-api/) to check the address after your backend has received it intact.

## Terms used here

### Email address syntax

The format rules for an email address; passing them does not establish that the domain or mailbox exists.

### Disposable email address

An address from a temporary-mail provider that can receive mail while active but may not remain available.

## Situations this applies to

### Validating an address in a signup form

Somebody is waiting on the other side of the request, so latency decides the design and a wrong rejection costs you the customer.

### Stopping trial abuse without blocking customers

The decision here lives in the reason codes rather than in the verdict, because the addresses you want to refuse and the ones you cannot afford to refuse share a verdict.

[All articles](https://emvero.io/blog/)

## Choose what to check next.

Run a check from your account and inspect the evidence in its result.

Start for free