SMTP 553: mailbox name not allowed

553 is a 5xx permanent failure meaning the receiving server will not accept mail for the given mailbox name under current policy — a broader category than a simple "address doesn't exist." The base code 553 is paired with different enhanced status codes depending on the specific reason: syntax problems, local policy restrictions, or security-related blocks (see the companion post on 553 5.7.2 for the authentication-alignment variant specifically).

Who is at fault

Depends on the enhanced code attached. A syntax-related 553 (5.1.3, invalid mailbox syntax) is sender-side. A policy-related 553 (5.7.1, access denied by local policy) can be either side depending on whether it's your reputation or a legitimate access restriction the recipient has set.

The exchange

220 mx.example.com ESMTP ready
EHLO mail.yourdomain.com
250 mx.example.com
MAIL FROM:<sender@yourdomain.com>
250 2.1.0 OK
RCPT TO:<invalid..address@example.com>
553 5.1.3 Mailbox name not allowed: invalid syntax

How the big three word it

The specific enhanced code tells you which of these you're facing — always read it alongside the base 553, not in isolation.

Diagnose it

$ echo "invalid..address@example.com" | grep -P '\.\.'

Check the exact literal address for double dots, leading/trailing dots, or other syntax the local-part grammar disallows. If the syntax is clean, the issue is almost certainly the 5.7.1 policy variant rather than 5.1.3.

Fix it, in order

1. Read the full enhanced code, not just "553" — it determines whether this is a syntax fix or a policy issue.
2. For syntax-flagged (5.1.3) rejections: validate and correct the address format in your sending system before resending.
3. For policy-flagged (5.7.1) rejections: check your authentication (SPF/DKIM/DMARC alignment) and sending reputation — this variant behaves like a reputation-driven block even though it uses the 553 base code.
4. Confirm the recipient address with the contact directly if you have an independent channel and the syntax looks plausible but still fails.

A third variant worth knowing: 553 5.3.0 and generic mailbox-name policy

Beyond the syntax (5.1.3) and local-policy (5.7.1) variants already covered, some servers pair 553 with 5.3.0 — "other or undefined mail system status" — when their own address-format rules reject a mailbox name for a reason that doesn't map cleanly to either the syntax or policy categories, commonly addresses that are technically well-formed but violate a receiving system's own naming conventions (certain reserved local parts, excessively long local parts, or characters the receiving system restricts beyond what RFC 5321 itself disallows). Treat this the same way as the 5.1.3 syntax variant: sender-side, fixable by changing how the address is constructed, not a reputation signal.

An additional diagnostic step

$ echo -n "invalid..address" | wc -c

Checking the raw byte length and content of just the local part in isolation, separate from the full address, catches length-limit and hidden-character problems a visual inspection of the full address can miss.

Retry timing for each variant

For the syntax-flagged (5.1.3 or 5.3.0) branch, there's no backoff to wait out — the address will fail identically on every attempt until its format changes, exactly like a 501 5.1.7 sender-syntax rejection. For the policy-flagged (5.7.1) branch, the situation behaves like a 4xx reputation deferral even though it carries a 5xx base code technically marking it permanent for this specific message: the condition causing it (authentication status, sending reputation) can improve over days to weeks of consistent, well-authenticated sending, after which a later message to the same address may succeed even though this exact rejected message is gone for good. Keep a record of which enhanced code accompanied each 553 you've seen from a given domain over time; a shift from 5.7.1 back to successful delivery is one of the few concrete, provider-confirmed signals that a reputation recovery effort is actually working, rather than relying solely on your own internal metrics.

What not to do

• Don't lump every 553 into one bucket. A syntax problem and a policy block require completely different fixes, and treating them the same wastes time.
• Don't retry a syntax-based 553 without changing anything. It will fail identically every time until the address format is corrected.
• Don't assume a policy-based 553 means you're permanently banned. It usually reflects current reputation or authentication status and can improve as those improve, even though the individual rejected message is gone for good.

MailPilot checks address formatting and authentication alignment as part of its deliverability checks, catching the conditions behind both 553 variants before they show up as failed sends.