SMTP Error 517

Is "SMTP Error 517" a real SMTP code?

No — 517 is not a reply code defined by the SMTP standard. RFC 5321 §4.2.1 lays out the three-digit reply structure, and the second digit carries a specific meaning:

• x0z — Syntax
• x1z — Information
• x2z — Connections
• x3z/x4z — Unspecified
• x5z — Mail system

A leading 5 means a permanent negative completion (the request will not be accepted), but the 1 in the second position means informational. A "permanent informational" reply is a contradiction, which is why the RFC defines no 51z codes at all. The closest standardized code is 521 ("server does not accept mail," RFC 7504). There is no 517 in RFC 5321, RFC 7504, or the major ESP catalogs (SendGrid/Twilio, Amazon SES, Mailgun).

So if you literally see 517 in a bounce or log, treat it as a vendor- or appliance-specific string, not a protocol code. The most honest fix is to read the full text the server returned alongside it.

What actually causes a "517" message?

The "517" label circulates on third-party code lists, but those lists don't agree with each other. One common framing pairs it with the text "Problem with senders mail attribute, check syntax" — pointing at the sender side, and in practice often showing up in Microsoft Exchange / Active Directory environments where a user object's mail attribute (the primary SMTP address) is missing, malformed, or contains invalid characters. The originating server rejects the message before it ever reaches the recipient's MTA.

Other vendor documentation describes "517" differently — for example, as the recipient server blocking or suspending the sender's address for policy reasons (spam, blacklist, or phishing suspicion), or pairing it with different extended status codes (e.g. 517 5.2.2, 517 4.3.1) that point at mailbox or policy issues rather than a syntax problem. Because 517 was never standardized, there is no single authoritative meaning — different mail systems and vendors have attached different explanations to the same three digits.

This also means the neighboring non-standard labels you may see aren't governed by one coherent convention either:

• 513 — commonly described as an address format/syntax problem
• 515 — commonly described as a recipient address that does not exist
• 517 — variously described as the sender's mail attribute being invalid, or the recipient server blocking the sender for policy reasons

None of those three are RFC reply codes. Given the disagreement across sources, the full response text from the specific server that issued it is the only reliable signal for what a "517" actually means in your case.

How do I fix "SMTP Error 517"?

1. Capture the full server response. The three digits alone are not enough — copy the entire line (e.g. "517 Problem with senders mail attribute…") and note which server emitted it. That text tells you whether it's an address attribute, a policy/blacklist rejection, a header issue, or something else.
2. Validate the sender address. Confirm the MAIL FROM / From address is a syntactically valid RFC 5321 address — no spaces, no leading/trailing dots, no invalid characters, and a real domain.
3. In Exchange/Active Directory, check the mail and proxyAddresses attributes. For the affected user(s), ensure the mail attribute is populated with a valid, correctly-cased SMTP address and that proxyAddresses has exactly one primary SMTP: entry. Remove stray whitespace or non-ASCII characters.
4. Inspect message headers. Malformed From, Sender, or Return-Path headers can trigger sender-attribute rejections. Send a test through a tool that shows raw headers.
5. Check whether the recipient server is blocking your sender for policy reasons. If the full response text mentions spam, reputation, or a blacklist rather than syntax, this isn't an attribute problem — it's a sender-reputation issue. Check your sending domain/IP against major blocklists and review recent complaint or bounce rates.
6. Confirm authentication and the envelope sender match policy. If the submitting account's authenticated identity does not match the From/envelope sender, some servers reject with a custom message. Align them (or grant send-as permission).
7. Check SPF/DKIM/DMARC alignment if the rejection is really an authentication policy in disguise — see RFC 7208 (SPF) and RFC 7489 (DMARC).

If you cannot reproduce or locate the source, contact the operator of the rejecting server with the full response text — because 517 is non-standard and vendors define it inconsistently, only that server's own documentation can tell you its exact intent.