TL;DR
Permanent RRVS failure: the receiver could not finish the check because the required timestamp was not stored. The sender must decide whether to resend without RRVS protection. Review deliverability and security risk before bypassing that protection. Do not retry unchanged.
What this code means
Missing stored timestamps leave RRVS incomplete: pattern X.7.19 yields code 5.7.19 because the receiving system cannot finish the check. Class 5 classifies that incomplete evaluation as a permanent failure of this attempt, without implying the recipient address is wrong. The registry leaves the resend decision to the message originator, specifically whether to issue traffic without RRVS protection under applicable policy. The status does not explain why the timestamp was missing or whether storage can be restored before a later attempt.
Technical meaning
When a message contains a Require-Recipient-Valid-Since field or RRVS extension and the receiving system cannot complete the requested evaluation because the required timestamp was not recorded, X.7.19 applies. The message originator must decide whether to reissue the message without RRVS protection. Code 5.7.19 carries this meaning in the permanent-failure class.
Delivery status
The leading digit 5 denotes a permanent failure of the current attempt. The code alone does not explain why the timestamp was not recorded and does not establish that the recipient address is invalid.
- 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 send only after assessing the risk and making an informed decision about whether policy permits sending without RRVS protection; first confirm the recipient and check suppression again.
Suppression decision
Operational recommendation: do not automatically add the address or domain to a suppression list based on 5.7.19 alone. Inspect the complete response, RRVS context, 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, but the receiving system had not recorded the timestamp required to perform the requested evaluation.
Diagnostic steps
- Inspect the raw SMTP response or nondelivery report and confirm the exact 5.7.19 code and a basic reply in the 5xx class; retain the complete response text.
- Correlate the event with the intended message, recipient, attempt time and stage, and the Require-Recipient-Valid-Since field or RRVS extension; do not infer from the code alone that the address is invalid.
- Ask the receiving-system administrator or provider to inspect available logs and confirm that the required timestamp was not recorded. Stop unchanged attempts and check suppression before the originator decides whether to send without RRVS protection.
Actions by owner
Sender
- Do not resend the same unchanged message; confirm the recipient and determine whether RRVS protection is required, then give the sender administrator the complete response.
Sender administrator
- Retain the complete response and RRVS context, stop unchanged retries, check suppression, and coordinate with the recipient administrator or provider on an informed decision about whether policy permits a new send without RRVS protection.
Recipient administrator
- If you manage the system that returned the code, inspect its logs and data used for the RRVS evaluation, confirm that the required timestamp was not recorded, and correct a confirmed recording problem or safely give the sender the result of the analysis.
Provider
- If you operate a system involved in the attempt, inspect RRVS processing and timestamp recording in the managed service, correct a confirmed problem or give administrators the needed context, 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:
