SMTP error 501 5.1.3: bad syntax in the sender address

SMTP error 501 5.1.3 means the envelope sender address in your MAIL FROM command has

invalid syntax. The enhanced code 5.1.3 is RFC 3463's "bad destination mailbox address syntax" -

applied here, by convention on many servers, to the sender address rather than the recipient, even

though the RFC's own wording nominally describes a destination mailbox. In practice, when 5.1.3

pairs with a 501 reply at MAIL FROM, it is reporting a malformed sender string, caught before

the server evaluates anything about whether that sender is even allowed to send.

Fault: sender, purely a formatting issue in how the envelope-from address was constructed.

Why it happens

• A missing or duplicated `@` in the envelope-from string, often from string concatenation

bugs when an application builds the sender address programmatically from separate variables.

• Unescaped special characters in the local part of the address - spaces, unescaped quotes,

or characters outside what RFC 5321 permits without quoting.

• A malformed or incomplete domain part - a trailing dot, a domain with invalid characters, or

a domain string accidentally truncated by application logic.

• Angle brackets handled incorrectly. The envelope sender must be wrapped in < and >

exactly once; doubled or missing brackets produce a syntax failure at this exact point.

• A quoted local part handled incorrectly by a hand-rolled parser. RFC 5321 permits quoted

local parts containing characters that would otherwise be invalid, and a parser that does not

correctly implement quoting can either reject a technically valid address or construct an

invalid one while attempting to simplify it.

The transcript

$ swaks --to test@mailpilots.in --server mx.example.net --from "sender@@yourdomain.com"
-> MAIL FROM:<sender@@yourdomain.com>
<- 501 5.1.3 Bad sender address syntax

The doubled @ is exactly the kind of string-construction bug that produces this error - the

server never evaluates whether sender@yourdomain.com is a legitimate sending address, because

the string it received was not a valid address at all.

How the big three word it

Diagnose it

$ swaks --to test@mailpilots.in --server mx.example.net --from "sender@@yourdomain.com" --dry-run
=== Would send:
MAIL FROM:<sender@@yourdomain.com>

--dry-run shows the exact literal string your client is about to send, which is the fastest way

to spot a malformed address before it ever reaches a live server - inspect the printed `MAIL

FROM:` line character by character.

$ python3 -c "
import re
addr = 'sender@@yourdomain.com'
print(bool(re.match(r'^[^@\s]+@[^@\s]+\.[^@\s]+$', addr)))
"
False

A quick regex sanity check on the constructed address before it is ever sent catches most of

these bugs at build time rather than at send time.

The fix, in order

1. Inspect the literal `MAIL FROM` string your application constructs, character by

character, rather than assuming the variable that feeds it is correct.

1. Validate the envelope-from address against RFC 5321 syntax rules before attempting to

send, using a library function rather than hand-rolled string concatenation.

1. Check for string-building bugs specifically - concatenating a local part and domain with a

hard-coded @ when the local part variable may already contain one is a very common root

cause.

1. Confirm angle-bracket handling in your SMTP client code - exactly one pair around the

address, no more, no fewer.

1. Add a syntax-validation step immediately before every send, catching malformed addresses

in your own code before they ever reach a server and waste a connection attempt.

What not to do

• Do not investigate DNS, authentication, or reputation. None of those are evaluated at this

stage; the string itself was rejected before any of them would be checked.

• Do not assume the domain is the problem. The entire address string, including the local

part, needs checking - many real-world cases trace back to the local part, not the domain.

• Do not retry the identical malformed string. It will produce the identical 501 5.1.3

every time; nothing about waiting changes a syntax error.

• Do not confuse this with `553 5.1.3`. That variant (covered separately) applies the

identical syntax check to the *recipient* address in RCPT TO, not the sender in MAIL FROM -

different command, same kind of underlying mistake.

MailPilot validates envelope sender and recipient syntax before attempting a send, catching

address-construction bugs in application code before they reach a real mail server and produce

this exact rejection.