3-digit reply code Permanent

SMTP error 513

Non-standard label: bad address syntax, or a relay/auth failure.

Updated Jul 1, 2026

The short answer

SMTP 513 is not a real reply code. Different vendors map the label to different causes: some treat it as bad recipient-address syntax (enhanced code 5.1.3, seen as 501 5.1.3 or 553 5.1.3); others define it as an SMTP-AUTH or relay-authorization failure. Check your platform's error table and the full bounce text, then fix the matching cause.

Quick fix

Read the full bounce text, then fix the malformed address or the authentication.

5 - Permanent. The server will not try again. Fix the cause before you resend.

What it means

RFC 5321 lists the valid reply codes and 513 is not one of them. In the permanent-failure range it defines 500-504 and 550-554. The "513" label comes from the enhanced status class X.1.3 ("the destination address was syntactically invalid"): some control panels collapse 5.1.3 into "513". But because the number has no basis in any standard, vendors disagree. KnownHost maps it to bad address syntax, while AuthSMTP and SendLayer define 513 as a relay or authentication failure. So read the full bounce text rather than assuming one meaning.

Common causes

Bad address syntax (the 5.1.3 reading)

The address in RCPT TO or MAIL FROM does not parse as a legal mailbox: stray whitespace, hidden non-ASCII characters, a missing or duplicated @, or a malformed envelope with a leaked display name.

A null or placeholder value

A templating bug that sends "RCPT TO:<>" or an unresolved placeholder like {{email}} is a common source.

Authentication or relay denial (the other reading)

On AuthSMTP and SendLayer, 513 means you must authenticate before sending, or the sending IP is not authorized to relay.

How to fix it

  1. Read the full reply line, not just "513"

    The accompanying text ("501 5.1.3 Bad recipient address syntax", or a relay/auth message) tells you which cause you have.

  2. If it is address syntax, inspect the exact bytes

    Re-type the address by hand. If you must paste, trim whitespace and strip non-ASCII characters before sending, and validate before RCPT TO.

    const to = rawTo.trim();
    if (!/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(to)) {
      throw new Error(`Invalid recipient: ${JSON.stringify(rawTo)}`);
    }
  3. Confirm the envelope is well-formed

    The address in RCPT TO must be in angle brackets with no display name. Keep display names in the message headers, not the envelope.

  4. Guard against null or placeholder values

    An unrendered template variable or a blank field is a frequent source of this bounce in bulk sends.

  5. If it is auth or relay, fix authentication

    Verify your SMTP credentials and confirm your IP or account is authorized to relay through that server.

Paired code

A real bounce often shows both a 3-digit code and an enhanced code together. This one commonly pairs with:

Common questions

Is 513 a real RFC reply code?

No. RFC 5321 lists every valid code and 513 is not among them. It is a non-standard vendor label that different platforms map to different things: bad address syntax (5.1.3) on some, an auth or relay failure on others.

What is the difference between 5.1.3 and 5.1.1?

5.1.3 means the address is syntactically invalid (the server cannot even read it). 5.1.1 means the address is readable but the mailbox does not exist.

Why does a correct-looking address get rejected as bad syntax?

It may carry hidden characters (zero-width spaces, smart quotes, full-width Unicode) from being pasted, or stray whitespace. Re-type it by hand to confirm.

Related codes

Ready when you are

Most rejections come back to sender reputation.

Blocklists, auth failures, and policy blocks are what warmup prevents. Warm up your domain so your mail is trusted before you hit send.

7-day free trialNo credit cardCancel anytime