# 553 5.1.3 Bounce: Invalid Recipient Address Syntax

URL: https://email-validation.org/bounce-codes/553-5-1-3/
Updated: 2026-11-06

> Documentation index: https://email-validation.org/llms.txt

**At a glance**

- **Type:** permanent failure (class 5, RFC 3463 §2). The sending server does not retry; sending the same message again fails the same way until the cause is fixed.
- **Basic code 553:** “Requested action not taken: mailbox name not allowed (e.g., mailbox syntax incorrect)” (RFC 5321 §4.2.3).
- **Enhanced code 5.1.3:** “Bad destination mailbox address syntax” in the IANA registry (RFC 3463), in the group addressing status (RFC 3463 §3.2).

The recipient address is not a valid email address as far as SMTP is concerned. The server did not look for the mailbox; it rejected the address because of how it is written.

## What it means
[RFC 3463 §3.2](https://www.rfc-editor.org/rfc/rfc3463) defines X.1.3 as bad destination mailbox address syntax. It can apply to any part of the address and is only meant for permanent failures. The basic code 553 says the mailbox name is not allowed, for example because its syntax is wrong ([RFC 5321 §4.2.3](https://www.rfc-editor.org/rfc/rfc5321)).

The rules come from [RFC 5321 §4.1.2](https://www.rfc-editor.org/rfc/rfc5321). Among them:
- Domain labels may contain only letters, digits and hyphens. An underscore is not allowed.
- Control characters must not appear in MAIL or RCPT commands, and plain SMTP does not allow non-ASCII characters in mailbox names.
- Spaces and most special characters in the local part are only allowed inside a quoted string.

[RFC 5321 §4.5.3.1](https://www.rfc-editor.org/rfc/rfc5321) also sets size limits: 64 octets for the local part, 255 for the domain and 256 for the whole path.

## Common causes
- A space inside the address, often from copying it out of a document.
- Two @ signs, or none.
- A comma or semicolon where a dot belongs: `john,smith@example.com`.
- Two addresses pasted into one field.
- A leading dot, a trailing dot, or two dots in a row.
- Invisible characters, such as a non-breaking space, carried over from a spreadsheet or web page.

## How providers use it
**Gmail** returns 553 5.1.3 when the recipient is not a valid RFC 5321 address ([Google's SMTP error reference](https://support.google.com/a/answer/3726730)). **Yahoo** lists forbidden characters in an address among its 550 policy rejections ([Yahoo SMTP error codes](https://senders.yahooinc.com/smtp-error-codes/)).

## How to fix it
1. Copy the address from the bounce into a plain text editor and look for spaces, commas and doubled characters.
2. Retype the address by hand instead of pasting it.
3. If the address came from a form or an import, fix that step: trim spaces and reject addresses that fail basic syntax before they reach your list.
4. If your own software builds the address, check that it does not join two values or add quotes or brackets.

## What to do with the address
If the intended address is obvious, such as an extra space, correct it and send again. If you cannot tell what the person meant, remove the address and ask for it again. Unlike most bounces, a syntax error can be caught before anything is sent, so add a check at the point where addresses enter your system.

## Related codes

- [553 5.1.7](https://email-validation.org/bounce-codes/553-5-1-7/): The sender's address is not valid syntax
- [550 5.1.1](https://email-validation.org/bounce-codes/550-5-1-1/): The recipient mailbox does not exist
- [553 5.1.2](https://email-validation.org/bounce-codes/553-5-1-2/): The recipient domain does not exist or takes no mail
- [501 5.5.4](https://email-validation.org/bounce-codes/501-5-5-4/): Invalid HELO/EHLO or command arguments

See [every bounce code](https://email-validation.org/bounce-codes/) in the dictionary.

Many bounces from addresses that do not exist can be avoided: check an address with our [free email checker](https://email-validation.org/email-checker/), or [clean a whole list](https://email-validation.org/bulk-email-verification/) before you send.