What does 501 5.1.8 bad sender address mean?

The mirror image of this page. 5.1.3 is bad syntax in the destination address; 5.1.8 is bad syntax in the sender address, which usually means your envelope sender is malformed or your sending domain does not resolve. Both are permanent, but only one of them is about the recipient.

How do I verify that strings are in a valid email format?

Use a library that implements the RFC 5322 grammar rather than a regular expression of your own. Syntax validation only tells you the string is well-formed, though — whether a mailbox exists behind it is a question only the receiving mail server can answer.

Is regex enough for email validation?

No. A typical pattern rejects user+tag@example.com, which is valid and widely used, and the full RFC 5322 grammar is not practically expressible as one readable expression. Worse, a regex cannot answer the question you actually have: whether the mailbox exists. Only the receiving server knows that.

SMTP reply code

553 5.1.3 — bad destination mailbox address syntax

A 553 5.1.3 reply means the receiving server could not parse the recipient address at all — it is malformed rather than missing. It is a permanent failure. Fix the address or remove it; the same string will always be rejected.

The facts

Reference facts for SMTP 553 5.1.3
Field	Value
Reply code	`553`
Enhanced status code	`5.1.3`
Class	5 — permanent failure
Subject	1 — addressing status
Detail	3 — bad destination mailbox address syntax
Bounce type	Hard
Should the sender retry?	No
Representative wording	`553 5.1.3 <[email protected]>: Recipient address rejected: Bad recipient address syntax`

The representative wording is one real form of this reply. The exact string is set by the receiving server and varies between mail platforms — read the one in your own logs rather than matching on a string.

What VerifyInbox returns

What VerifyInbox returns for SMTP 553 5.1.3
Field	Value
`emailStatus`	`undeliverable`
`reason`	`syntax_error` when our own normaliser rejects the address before any probe runs; `mailbox_not_found` when a server answers `553` to a probe we did send
`format`	`invalid` in the first case, `valid` in the second
`retryable`	`false`
Charged	Yes. A permanent rejection is a definitive answer.

Malformed, not missing

5.1.3 is the address-syntax code, and it is a genuinely different fact from 5.1.1. A 5.1.1 says the server understood the address and has no such mailbox. A 5.1.3 says the server could not make sense of the string it was given.

The three-digit reply code comes from RFC 5321: a 2yz is a success, a 4yz is a transient failure the sender should retry, and a 5yz is a permanent failure the sender should not repeat in the same form. The dotted code beside it comes from RFC 3463 and has three parts — class.subject.detail — where the class repeats 2, 4 or 5, the subject says which part of the system had the problem, and the detail says what it was. The full list is an IANA registry established by RFC 5248, which is the authoritative source and the one nothing else ranking for these queries cites.

Most commonly it is a data problem rather than a mail problem: a display name that was never stripped, a trailing comma from a CSV, a double dot in the local part, unencoded whitespace, a smart quote that survived a copy and paste out of a document.

Worth knowing: the address grammar in RFC 5322 is considerably more permissive than most validation code assumes. "[email protected]"@example.com is a legal address; [email protected] certainly is, and a great deal of homegrown validation rejects it. A server answering 553 is applying its own rules, which may be stricter than the grammar.

What to do

If you sent the message

Look at the exact string in the bounce, not at what you think you sent — the problem is almost always something invisible in a spreadsheet cell.
Check for a display name, stray punctuation, whitespace, or a character that was pasted from a word processor.
If the address is genuinely malformed in your database, correct it at the source rather than for this one send.

If you own the receiving domain

This is your server rejecting a string it cannot parse, so it is usually the sender’s problem to fix.
If legitimate senders are hitting it, check whether a filter or rewriting rule is corrupting the recipient address in transit.

If you are a developer

Validate and normalise at the point of capture, not at the point of send — by the time a 553 arrives, the bad data has been in your database for months.
Do not write your own address grammar. Use a library, and do not reject user+tag@ — it is valid and widely used.
Treat it as permanent and suppress, but flag it separately from 5.1.1: a syntax failure is a data-quality signal, not a list-decay signal.

To find out whether an address will return this before you send to it, run it through the free email verifier

Related codes

Related terms

Sources

Primary sources checked 11 September 2026. If something here is out of date, tell us and we will correct it.