TL;DR
Permanent RRVS failure: the mailbox has not stayed continuously owned by the intended recipient since the stamped time. Verify recipient identity and RRVS data before retrying. A security signal about address ownership, not routine list hygiene. Do not retry unchanged.
What this code means
Mailbox continuity that broke after the stamped date-time is the RRVS finding behind code 5.7.17, from registry pattern X.7.17, for messages that carry Require-Recipient-Valid-Since or RRVS. Class 5 records that ownership finding as permanent in the enhanced status register, separate from generic undeliverable-address results. The detail is a mailbox-level security disclosure, not proof the address never existed. It does not reveal prior or current owners, the precise handoff moment, or whether the address remains appropriate for other mail.
Technical meaning
Require-Recipient-Valid-Since or an RRVS extension on a message, plus a determination that the intended recipient's mailbox has not been under continuous ownership since the specified date-time, yields X.7.17. Code 5.7.17 applies this meaning in the permanent-failure class for that ownership break.
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
- 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.
- 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.
- 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
These sources define what this enhanced status code means, mainly through the IANA registry and related RFCs. When provider examples appear on the page, they come from that provider's published documentation. Follow the links to read the original wording in context.
- SMTP Enhanced Status Codes — IANA registry of enhanced mail system status codes.
- RFC 5248 — A Registry for SMTP Enhanced Mail System Status Codes — Creates and governs the IANA enhanced status code registry.
- RFC 2034 — SMTP Service Extension for Returning Enhanced Error Codes — Defines how SMTP returns enhanced status codes to clients.
- RFC 7293 — Require-Recipient-Valid-Since Header Field and SMTP Extension — Protects against address recycling with a recipient-validity extension.
Last verified:
