SMTP "513", "515" and "517" are not real reply codes

513, 515 and 517 are not SMTP reply codes. The valid 5yz space used by real mail servers runs 500 through 504 and 550 through 555; none of these three numbers falls in it, and no mainstream server - not Postfix, Exim, Sendmail, Exchange, Gmail's or Yahoo's receiving infrastructure - emits any of them. If you have seen a report or a legacy document citing these as distinct "address type and format" errors, that document invented a numbering scheme rather than quoting a real server reply.

What was probably actually received

The descriptions typically attached to these three fake codes - invalid address type, malformed recipient, unsupported address format - map onto a small set of real, standard codes:

• 501 5.1.3 - bad address syntax in RCPT TO or MAIL FROM, caught before the server checks whether the mailbox exists.
• 553 5.1.3 - the same syntax problem, rejected with the 553 base code instead of 501 (server-dependent choice).
• 550 5.1.2 - the domain itself could not be resolved to a valid host.

All three are permanent (5xx) failures, and all three point at the same class of problem: the address string itself, not the mailbox behind it.

Who is at fault

The fault is on the sending side - specifically malformed address data, most often from a bad import, a broken template, or copy-paste artefacts leaving invisible characters in an address field. Copy-paste from PDF documents is a particularly reliable source of invisible-character

corruption, because PDF text extraction sometimes inserts non-breaking spaces, soft hyphens, or

other formatting artefacts at word boundaries that render identically to a normal character on

screen but differ at the byte level. If your address list was built even partly by extracting

contact details from PDFs (business cards, signed documents, printed directories), that is worth

treating as a higher-risk source worth an extra validation pass before any address from it is

used in a live send.

The exchange (the real reply)

MAIL FROM:<sender@yourdomain.com>
250 2.1.0 OK
RCPT TO:<recipient@example,com>
501 5.1.3 Bad recipient address syntax

The comma in place of a dot before the TLD is the kind of malformation these fake code numbers were likely trying to describe.

How Gmail, Microsoft 365 and Yahoo word the real underlying condition

Diagnostic commands

$ grep -B1 -A3 "status=bounced" /var/log/mail.log | grep -A3 "recipient@example,com"
to=<recipient@example,com>, relay=none, delay=0.1, status=bounced
(Recipient address rejected: domain "example,com" not found)

$ python3 -c "
import re
addr = 'recipient@example,com'
print(bool(re.match(r'^[^@]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$', addr)))
"
False

The ordered fix

1. Find the raw SMTP transcript behind any report showing 513, 515 or 517 - these numbers do not correspond to anything you can look up, so the real reply must come from your own mail log.
2. Confirm the real code is a 501 or 553 with a 5.1.x enhanced status.
3. Inspect the exact address string for the specific malformation - a comma instead of a dot, a missing @, stray whitespace, or non-ASCII characters from an encoding mismatch.
4. Run a basic RFC 5321 syntax check on your full list before sending, not just on addresses that have already failed.
5. Fix the import or templating step that introduced the malformed character so it does not recur across future batches.

What not to do

• Do not search for documentation on 513, 515 or 517. None exists because none of these numbers is a real SMTP reply.
• Do not retry malformed addresses unchanged. A syntax error reproduces identically every time; only correcting the string changes the outcome.
• Do not assume the mailbox itself is invalid. The rejection happens before the server even checks mailbox existence - fix the syntax first, then re-evaluate.
• Do not let a reporting tool that invents fake codes keep running unexamined. If it produced three non-existent numbers for one underlying condition, it will keep doing so for others.

A quick way to confirm before escalating

If any report cites 513, 515 or 517 and you cannot immediately reach the raw log, a fast proxy

check is to search your mail system's documentation or source for those exact numbers - for

Postfix, Exim, or any major commercial MTA, a search of the official documentation will turn up

nothing, which itself confirms the number is fabricated without needing the original transcript at

all. This is faster than waiting to reproduce the condition live when you just need to know

whether a historical report is trustworthy.

MailPilot validates recipient address syntax before any send attempt and reports the literal reply code and enhanced status from the wire, so a parsing shortcut elsewhere in your stack cannot hand your team a code that was never actually sent.