SMTP 553 5.3.0: requested action not taken, mailbox name invalid

553 5.3.0 is a permanent failure meaning the server rejected the mailbox name as invalid at a more fundamental level than a simple syntax typo. Where 501 5.1.3 typically catches a malformed address string (missing @, stray characters), a 553 5.3.0 more often appears when the mailbox name itself violates a structural or policy rule the receiving domain enforces - disallowed characters in the local part, a local part that is too long, or a domain-specific naming convention your address does not follow.

Who is at fault

This is a sending-side address-data fault. The recipient address you are attempting to use does not conform to a structural rule the receiving mail system enforces for all mailbox names on that domain. That rejection happens purely on the string's shape, independent of whether that specific mailbox otherwise exists or not - the server never reaches its directory lookup at all.

The exchange

220 mx.example.com ESMTP
EHLO mail.yourdomain.com
250-mx.example.com
250 SIZE 26214400
MAIL FROM:<sender@yourdomain.com>
250 2.1.0 OK
RCPT TO:<john..smith@example.com>
553 5.3.0 <john..smith@example.com>... Mailbox name invalid

Consecutive dots in the local part (john..smith) are disallowed under RFC 5321's own address-local-part rules, and many servers enforce this strictly at the mailbox-name level rather than at basic syntax parsing.

How Gmail, Microsoft 365 and Yahoo word the same condition

Microsoft 365's tendency to fold this into a generic 550 5.1.1 rather than a distinct 553 means the same underlying address-format problem can look like a completely different, more final-sounding error depending on which provider you are sending to.

Diagnostic commands

$ swaks --to "john..smith@example.com" --from sender@yourdomain.com --server mx.example.com
<~  553 5.3.0 <john..smith@example.com>... Mailbox name invalid

$ python3 -c "
import re
addr = 'john..smith@example.com'
local = addr.split('@')[0]
print('consecutive dots:', '..' in local)
"
consecutive dots: True

The ordered fix

1. Isolate the exact mailbox name triggering the rejection from the raw SMTP reply.
2. Check for consecutive dots, leading/trailing dots, or disallowed special characters in the local part - these are the most common structural violations.
3. Run a stricter address-validation pass on your list before sending, checking not just basic syntax (one @, a domain with a dot) but also these structural rules.
4. Correct or remove the offending address rather than attempting variations - if the name itself is genuinely malformed, guessing at corrections risks sending to the wrong person.
5. Re-test the corrected address with swaks before resuming the batch.

What not to do

• Do not assume this is the same as a basic syntax error (501) and apply the same fix pattern uncritically. The specific structural rule being violated may differ, and a validator tuned only for basic syntax (one @, a domain) will miss it.
• Do not retry the exact same address. A structural violation reproduces identically every time.
• Do not strip the malformed address of its distinguishing characters blindly (e.g. deleting all dots) without confirming the corrected form is actually the real address - that risks misdirecting mail.
• Do not treat this as a reputation issue. The rejection happens purely on the mailbox name's format, independent of your sending history or authentication.

Where malformed local parts usually originate

Consecutive or trailing dots in an address local part are rarely typed by hand - they are far more

often introduced by a broken string-concatenation step in an import pipeline, such as combining a

first and last name with a separator that leaves an extra dot when one of the fields is empty.

Tracing the specific address back through your import logic, rather than just correcting the one

address you found, usually reveals a systematic bug that has silently malformed other addresses in

the same batch the same way.

Other structural rules worth validating alongside dots

Consecutive and trailing dots are the most common structural violation, but not the only one -

some mail systems also reject local parts exceeding 64 characters (an RFC 5321 limit that is

technically a hard maximum, not just a convention), local parts starting with a dot, or local

parts containing unescaped special characters like unquoted spaces or certain punctuation. A

validation pass that only checks for consecutive dots will catch the single most common case but

miss these less frequent ones - worth building a single validator that checks the full RFC 5321

local-part grammar rather than patching in checks one discovered violation at a time.

MailPilot validates recipient address structure, including local-part formatting rules like consecutive or leading/trailing dots, before any send attempt - catching this class of rejection before it ever reaches a live SMTP session.