SMTP error 553 5.1.3: bad syntax in the recipient address

SMTP error 553 5.1.3 means the recipient address in your RCPT TO command has invalid

syntax. The enhanced code 5.1.3, "bad destination mailbox address syntax," is applied here in

its most literal, RFC-faithful sense - unlike the sender-side convention covered in the dedicated

501 5.1.3 piece, this one genuinely concerns the destination mailbox address string itself,

rejected before the server ever checks whether that mailbox exists.

Fault: sender, purely a formatting issue in how the recipient address was constructed or

supplied, most often from user input that was never validated.

Why it happens

• A recipient address typed or pasted with invisible or invalid characters - a trailing

space, a smart quote substituted for a straight one, a non-breaking space from a copy-paste out

of a document or webpage.

• Missing or duplicated `@` symbols, frequently from form input that concatenates a username

and domain incorrectly, or from a user typing an address with a typo.

• An address missing a domain entirely, such as a bare username submitted where a full

address was expected, often from a form field that failed to validate before submission.

• Overly long local parts or domain labels exceeding RFC 5321's length limits, occasionally

seen with auto-generated or system-constructed addresses that concatenate several fields

together.

• An address copied from a PDF, a scanned document, or a poorly rendered web page, where

ligatures, hyphenation artifacts, or OCR errors introduce characters that look correct visually

but are not the characters the address actually contains.

The transcript

$ swaks --to " test@mailpilots.in" --server mx.example.net
-> RCPT TO:< test@mailpilots.in>
<- 553 5.1.3 <  test@mailpilots.in>: Recipient address rejected: Bad address
    syntax

The leading space inside the angle brackets is the entire problem here - a single invisible

character from unsanitised user input, and the server correctly refuses to guess at what was

intended.

How the big three word it

Diagnose it

$ echo -n " test@mailpilots.in" | od -c | head -1
0000000    t   e   s   t   @   m   a   i   l   p   i   l   o   t   s

od -c reveals invisible characters that a plain text view will not show - a leading space,

tab, or non-breaking space is immediately visible in this output when it is invisible everywhere

else.

$ python3 -c "
import re
addr = ' test@mailpilots.in'.strip()
print(bool(re.match(r'^[^@\s]+@[^@\s]+\.[^@\s]+$', addr)))
"
True

Stripping whitespace before validation, as shown here, resolves the majority of real-world cases

of this exact error.

The fix, in order

1. Strip leading/trailing whitespace and normalise the character set on any user-submitted

recipient address before attempting to send.

1. Validate the recipient address against RFC 5321 syntax using a library function rather

than a hand-rolled regular expression, to correctly handle edge cases like quoted local parts.

1. Check for invisible characters specifically when a copy-pasted address fails validation

for no visually apparent reason - od -c or an equivalent hex/character dump finds these

immediately.

1. Add a syntax-validation step at the point of user input, not only immediately before

sending, so the person entering the address gets immediate feedback rather than a failure deep

in a send pipeline.

1. Log the exact rejected string, not a sanitised version of it, when building error

reporting for this condition - the exact bytes are what explain the failure.

What not to do

• Do not assume the domain is wrong. The syntax check applies to the entire address string,

and local-part issues (stray characters, missing @) are at least as common as domain issues.

• Do not retry the identical malformed address. It is a permanent 5xx for this exact

string; nothing changes between attempts without fixing the string itself.

• Do not confuse this with `553 5.1.2` (bad destination system, covered separately) - that

one concerns whether the domain resolves at all; 5.1.3 concerns whether the address string

itself is well-formed, independent of whether the domain is real.

• **Do not suppress the underlying contact record without checking for a simple data-entry fix

first.** Many 5.1.3 failures are a one-character correction away from a valid, deliverable

address.

MailPilot validates recipient address syntax, including checks for invisible and malformed

characters, before attempting a send - catching exactly this class of data-entry error before it

produces a wasted connection and a permanent rejection.