TL;DR
Permanent RRVS signal: the recipient domain changed owners since the RRVS timestamp. Confirm recipient and domain context before retrying. An ownership-change alert, not a simple hard bounce. Do not retry unchanged.
What this code means
When domain ownership shifted after the RRVS timestamp, code 5.7.18 records that disclosure under registry pattern X.7.18 for messages that include Require-Recipient-Valid-Since or RRVS data. Class 5 assigns a permanent-failure classification even though the signal is an RRVS policy disclosure rather than a mailbox-existence verdict. This status separates domain-level ownership drift from mailbox-level RRVS outcomes such as 5.7.17. The code alone does not identify previous or current domain owners or explain why ownership shifted.
Technical meaning
Domain-owner change since the specified time, disclosed when a message carries Require-Recipient-Valid-Since or an RRVS extension, is X.7.18. Receivers use that pattern to report domain-level ownership drift; code 5.7.18 places the result in the permanent class through its leading digit.
Delivery status
The leading digit 5 denotes a permanent failure of the current attempt. The code alone identifies neither the previous nor current domain owner and does not state why the ownership changed.
- Class
- Permanent failure
- Retry
- Do not retry unchanged
- Suppression
- Check the full context
Retry decision
Operational guidance: stop automatic and manual retries of the same unchanged attempt. Consider a new, controlled attempt only after verifying the recipient, domain, and RRVS context and confirming a material correction; check suppression again first.
Suppression decision
Operational guidance: do not automatically add the address or domain to a suppression list based on 5.7.18 alone. Inspect the complete response, RRVS context, domain-ownership change, and other delivery events, then make the suppression decision according to the confirmed cause and applicable policy.
Common causes
- The message contained a Require-Recipient-Valid-Since field or RRVS extension, and the receiving system determined that the owner of the recipient's domain had changed since the specified time.
Diagnostic steps
- Inspect the raw SMTP response or nondelivery report and confirm the exact 5.7.18 code and a basic reply in the 5xx class; retain the complete response text.
- Correlate the event with the intended message, attempt time and stage, recipient domain, and time supplied in the Require-Recipient-Valid-Since field or RRVS extension; do not infer the owners' identities from the code alone.
- Ask the receiving-system administrator or provider to inspect available logs and confirm the domain-ownership-change condition. Stop unchanged attempts and check suppression before any new, controlled send after a confirmed correction.
Actions by owner
Sender
- Do not resend the same unchanged message; confirm the intended recipient and domain, then give the sender administrator the complete response.
Sender administrator
- Retain the complete response and attempt context, verify the recipient domain and RRVS time used, stop unchanged retries, and coordinate a confirmed correction with the recipient administrator or provider.
Recipient administrator
- If you manage the system that returned the code, inspect its logs for the specified domain and RRVS time, confirm the domain-ownership-change condition, and give the sender safe context needed for the next decision.
Provider
- If you operate a system involved in the attempt, inspect managed-service logs and RRVS context, confirm the basis of the result, and do not trigger suppression based on 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:
