Blazalek.com

5.7.17Mailbox owner has changed

The receiving system permanently rejected the attempt because it determined that the mailbox had not remained continuously owned by the intended recipient since the time specified by RRVS. Do not retry the same attempt unchanged.

Category
Security, authentication and policy
Class
Permanent failure
Retry
Do not retry unchanged
Suppression
Check the full context

What this code means

The receiving system permanently rejected the attempt because it determined that the mailbox had not remained continuously owned by the intended recipient since the time specified by RRVS. Do not retry the same attempt unchanged.

Technical meaning

The X.7.17 pattern is returned when a message contains a Require-Recipient-Valid-Since field or RRVS extension and the receiving system can determine that the intended recipient's mailbox has not been under their continuous ownership since the specified date-time. Code 5.7.17 applies this meaning in the permanent-failure class.

Delivery status

The leading digit 5 denotes a permanent failure of the current attempt. The code alone identifies neither the former nor the current mailbox owner, and it does not indicate the exact time of the change or whether the address can be used safely in another context.

Class
Permanent failure
Retry
Do not retry unchanged
Suppression
Check the full context

Retry decision

Operational recommendation: stop automatic and manual retries of the same unchanged attempt. Consider a new, controlled attempt only after reliably confirming the intended recipient's identity and address and making a justified correction to recipient data or RRVS parameters under the applicable policy; check suppression again first.

Suppression decision

Operational recommendation: do not automatically suppress the entire address or domain based on 5.7.17 alone. Inspect the complete response, RRVS timestamp, specific recipient-to-address relationship, and delivery history, then make the suppression decision for the confirmed context under the applicable policy.

Common causes

  • The mailbox changed owners after the date-time specified by RRVS, and the receiving system determined that it had not remained continuously owned by the intended recipient since then.

Diagnostic steps

  1. Inspect the raw SMTP response or delivery report and confirm the exact 5.7.17 code and a basic reply in the 5xx class; retain the complete response text.
  2. Correlate the response with the intended message, attempt time and stage, recipient address, system that returned the code, and the RRVS field or extension and its date-time; do not infer owner details from the code alone.
  3. Use trusted sender data and available recipient or provider logs to verify continuity between the intended recipient and the mailbox since the specified time. Stop unchanged attempts, check suppression, and permit a new attempt only after a confirmed correction.

Actions by owner

Sender

  • Do not resend the same message or remove RRVS protection; confirm the intended recipient's address through a trusted channel and give the administrator the complete response.

Sender administrator

  • Retain the complete response, address, and RRVS timestamp, stop unchanged retries, and verify the recipient, account, and mailbox relationship; correct only confirmed stale data or an RRVS parameter, then check suppression before a controlled attempt.

Recipient administrator

  • If you manage the system that returned the code, inspect its logs and mailbox-ownership state for the specified time; correct a confirmed data error or safely confirm the result without disclosing information about the current owner.

Provider

  • If you operate a service involved in the attempt, inspect RRVS processing and the ownership-continuity determination in managed logs; correct a confirmed service fault or give administrators safe context without automatically triggering suppression from the code alone.

Sources and verification

The standard meaning of X.7.17 and the class-5 application of code 5.7.17 were verified against the IANA registry and RFC 2034, RFC 5248, and RFC 7293 as of July 17, 2026. Retry, suppression, diagnostic, and owner-action guidance is presented separately as operational advice; this record contains no provider-specific practice.

  • Enumerated Status Codes / X.7.17

  • rfc5248T0 source

    Section 2.1: registry fields and non-exclusive Associated Basic Status Code

  • rfc2034T0 source

    Section 4: enhanced status class agrees with SMTP reply class

  • rfc7293T0 source

    IANA registry reference for X.7.17

Last verified:

Wojtek Blazalek

Email deliverability expert

Stuck on this error code? I help teams clear the root cause of rejections and fix authentication and reputation — so email lands in the inbox.

Hands-on deliverability work for teams that send at scale.