SMTP Error 513

Is "SMTP Error 513" a real SMTP code?

Not as a reply code. RFC 5321 §4.2.3 enumerates the valid SMTP reply codes, and 513 is not one of them. The permanent-failure (5xx) replies it lists are 500, 501, 502, 503, and 504, plus 550, 551, 552, 553, and 554 (with 521 and 556 added later by RFC 7504). There is no 513 — and no 5xx code between 504 and 550 in the base SMTP spec.

Where the "513" label comes from is the enhanced status code class X.1.3 defined in RFC 3463 §3.2: "The destination address was syntactically invalid." Some host control panels and legacy error tables (for example KnownHost's table, which lists 513 as "Address type is incorrect (possibly misspelled)") collapse the 5.1.3 triplet into "513." So when you see "513" on one of these platforms, the server may be returning a real reply such as:

• 501 5.1.3 Bad recipient address syntax
• 553 5.1.3 The recipient address is not a valid RFC-5321 address
• 550 5.1.3 The destination address was syntactically invalid

Caveat: because "513" has no basis in any standard, different vendors' legacy error tables assign the number to different underlying causes. KnownHost's table maps it to bad address syntax (the interpretation this page focuses on), but AuthSMTP's error-code table defines 513 as "must authenticate before sending" (an SMTP-AUTH/relay-authorization failure), and SendLayer documents 513 as "Relaying denied" for the same reason — neither related to address syntax. Don't assume address syntax is the cause just because you saw "513"; check your specific mail platform's own error table and, more importantly, read the full bounce text your server actually returned.

All three address-syntax variants mean the same thing: the address you put in the RCPT TO: (or MAIL FROM:) command does not parse as a legal mailbox per RFC 5321 §4.1.2. This is a syntax rejection — the server is not saying the mailbox doesn't exist (that's 5.1.1); it's saying it can't even read the address. If your platform's table instead maps "513" to an authentication/relay failure, the fix is different: verify SMTP-AUTH credentials and confirm your sending IP or account is authorized to relay through that server.

What causes a 5.1.3 / "513" bad-address-syntax rejection?

• Stray whitespace — a leading/trailing space or a space inside the address (john @example.com). A single extra space invalidates the address.
• Hidden or non-ASCII characters — pasting an address from a web page, PDF, or spreadsheet can drag in zero-width spaces, smart quotes, or full-width Unicode characters that look fine but aren't valid.
• Missing or duplicated @, or a missing domain (john@, john, john@@example.com).
• Malformed angle brackets / display names in the envelope — e.g. RCPT TO:john@example.com without <>, or <John Doe john@example.com> where the display name leaked into the address.
• Unquoted special characters in the local part (commas, colons, brackets) that RFC 5321 requires to be quoted.
• An empty/null variable from your application — a common cause is a templating bug that sends RCPT TO:<> or an unresolved placeholder like {{email}}.

How do I fix SMTP Error 513?

1. Read the full reply line, not just "513." The accompanying text (501 5.1.3 Bad recipient address syntax, etc.) and the offending address tell you exactly which address failed — and whether you're even looking at an address-syntax issue versus an auth/relay issue.
2. Inspect the exact bytes of the address. Re-type it by hand rather than pasting. If you must paste, strip it: trim whitespace and remove non-ASCII characters before sending. In code, normalize and validate before the RCPT TO:

// Nodemailer example: trim and sanity-check before sending
const to = rawTo.trim();
if (!/^[^\s@]+@[^\s@]+\.[^\s@]+$/.test(to)) {
  throw new Error(`Recipient failed RFC 5321 syntax check: ${JSON.stringify(rawTo)}`);
}

# Python: catch empty/placeholder values before they reach RCPT TO
to = raw_to.strip()
if not to or "@" not in to:
    raise ValueError(f"Invalid recipient address: {raw_to!r}")

3. Confirm the envelope is well-formed. The address in RCPT TO:<...> must be enclosed in angle brackets with no display name, e.g. RCPT TO:<john@example.com>. Keep display names in the message headers (To:), not the envelope.
4. Guard against null/placeholder values from your app or merge data. An unrendered template variable or a blank database field is a frequent source of this bounce in bulk sends.
5. Validate the list upstream. If you're sending at volume, run addresses through RFC 5321/5322 validation (and ideally verification) before submission so a single bad row doesn't bounce.

Note: 5.1.3 is a permanent failure (5.x.x) — retrying the same address will not help. You must correct the address. If the address is genuinely valid and still rejected, the receiving server may be applying a stricter-than-RFC interpretation; contact the recipient's mail administrator or your sending provider.

Because Courier delivers through downstream email providers (SendGrid, SES, Postmark, etc.), a 5.1.3 rejection surfaces as a bounce/undeliverable on that provider — fix the recipient address in your send payload and resend.