blazalek/open-smtp-error-dataset

1record_id,enhanced_status_code,registry_pattern,catalog_slug,catalog_url,category_id,outcome_class,retry_decision,suppression_decision,responsible_parties,title,short_description,tldr,explanation,technical_meaning,status_explanation,retry_guidance,suppression_guidance,common_causes,diagnostic_steps,actions_by_owner,related_codes,classification_rule_key,classification_failure_persistence,classification_cause_family,classification_recipient_validity,classification_retry_disposition,classification_suppression_disposition,classification_confidence,classification_needs_review2"email-error-2-0-0","2.0.0","X.0.0","2-0-0","https://blazalek.com/en/email-errors/2-0-0","other-undefined","success","do_not_retry","check_context","[""sender_admin"",""provider""]","Other undefined success status","Code 2.0.0 is a general success status: only class 2 is known, with no more specific status. It is not a message rejection.","Generic success status when only class 2 is known. Treat it as acceptance, not rejection: misclassifying it as a bounce breaks deliverability reporting. This is not a failure; do not retry, and list hygiene is unaffected unless your system wrongly routes it to bounce handling.","status-code list pattern X.0.0 lands in success class 2 when the reporting system knew the outcome class but could not attach a more specific subject detail. The first digit 2 places the status in the success family of the enhanced status register, so it marks acceptance rather than temporary or permanent delivery failure. The undefined middle and detail positions (.0.0) deliberately carry no finer mailbox, system, or protocol cause. The code alone does not establish final inbox placement, routing path, or that no later event will follow for the same message.","X.0.0 is the sole undefined status pattern and applies when only the result class is known. In the 2.0.0 variant, that result class is success.","This is a success status, not a temporary or permanent error. If a system shows it as a bounce or rejection, inspect the event classification.","Do not retry based on code 2.0.0 alone because it belongs to the success class. Retrying could create a duplicate.","Do not add the address to a suppression list based on code 2.0.0 alone. Make that decision only after checking the context and other independent delivery or rejection events.","[""The receiving server returned a general success status without a more specific enhanced code."",""The response-processing system retained only the success class or incorrectly routed it into a rejection-handling flow.""]","[""Inspect the raw SMTP transaction response and confirm that it contains the exact enhanced code 2.0.0."",""Trace response mapping in logs and webhooks to determine whether status detail was lost or a successful result was classified as a bounce.""]","{""sender_admin"":[""Treat 2.0.0 as a successful result, remove it from retry queues, and do not create a suppression solely from this code.""],""provider"":[""Review normalization rules when the general 2.0.0 code replaces an available, more specific success status.""]}","[""4.0.0"",""5.0.0""]","esc-2-0-0","indeterminate","unknown","unverified","do_not_retry","no_recommendation","low","true"3"email-error-2-1-5","2.1.5","X.1.5","2-1-5","https://blazalek.com/en/email-errors/2-1-5","addressing","success","do_not_retry","check_context","[""sender"",""sender_admin""]","2.1.5 — Destination address is valid","The specified recipient mailbox address was found to be valid. This is a success confirmation, not a message rejection.","Confirms the recipient mailbox address is valid in a positive delivery report. Important for correlating message events; this is success, not rejection. Do not retry or suppress on this code alone: deliverability and list hygiene are unaffected.","When the reporting system treats the destination mailbox address given in the transaction as valid, it reports that reading under addressing pattern X.1.5 in success class 2. Subject family 1 covers mailbox and routing addresses, and the leading digit 2 signals success rather than the temporary or permanent address failures of 4.1.x and 5.1.x. The code usually appears in a positive delivery status report, not as an SMTP rejection reply. It confirms address validity at reporting time, yet the code does not establish final delivery, inbox placement, or that a later rejection will not occur.","X.1.5 reports that the destination mailbox address was valid. The standard reserves this code for positive delivery status reports.","The leading digit 2 denotes success. Code 2.1.5 does not describe an error or rejection; it confirms address validity in a positive delivery report.","Do not retry because of code 2.1.5 alone, since it does not indicate a failure that needs another attempt. If the expected outcome is not visible, inspect the remaining events for this message.","Do not decide to add the address to a suppression list based on code 2.1.5 alone. Evaluate the full message context and any later events before changing the recipient's state.","[""The reporting system confirmed that the specified destination mailbox address is valid."",""A positive delivery report was generated for the message with this addressing status code.""]","[""Confirm that the parsed enhanced code is exactly 2.1.5 and that it comes from the report for the intended message."",""Check the message identifier and timestamps to correlate the report with the specific send attempt."",""Review later message events if you need to establish its final state beyond the address-validity confirmation itself.""]","{""sender"":[""Treat this code as a successful address check and do not resend solely because it appeared."",""Retain the report with the message history so that subsequent events can be interpreted correctly.""],""sender_admin"":[""Ensure the event classifier recognizes class 2 as success rather than rejection."",""Do not trigger automatic suppression for 2.1.5 without evaluating other events and recipient rules.""]}","[""4.1.1"",""4.1.8"",""5.1.1"",""5.1.3""]","esc-2-1-5","indeterminate","unknown","valid","do_not_retry","no_recommendation","high","false"4"email-error-2-3-0","2.3.0","X.3.0","2-3-0","https://blazalek.com/en/email-errors/2-3-0","mail-system","success","do_not_retry","check_context","[""sender_admin"",""recipient_admin"",""provider""]","2.3.0 — Other or undefined mail system status","The destination system exists and normally accepts mail, but its condition caused a general DSN to be generated. Because the code begins with 2, it describes success, not a message rejection.","General mail-system status in success class 2: not a delivery failure. Operationally informational; if your tools label it a bounce, fix event mapping. Accepted result: do not retry. Deliverability and reputation are usually unaffected.","Under success class 2, the X.3.0 mail-system status-code list pattern means the destination mail system exists and ordinarily accepts mail, yet the reporting path returned only this general status instead of a more specific 2.3.x detail. Subject family 3 addresses mail-system conditions, and the leading digit 2 keeps the report in the success register even when a DSN accompanies the event. Something on the destination system prompted status reporting without identifying a particular queue, capacity, or configuration cause. The status does not establish an outage, a rejection, or delivery completion beyond the acceptance implied by class 2.","The X.3.0 pattern means another or undefined mail-system status: the destination system exists and ordinarily accepts mail, yet something about that system caused the DSN to be generated. In the 2.3.0 variant, the result class is success.","The leading digit 2 denotes success. Code 2.3.0 does not indicate a temporary or permanent error and is not itself a bounce or rejection signal, even when it appears in a DSN.","Do not retry based on code 2.3.0 alone because it is a success status. Retrying could create a duplicate; if the expected outcome is not visible, inspect the full event context first.","Do not add the recipient to a suppression list based solely on code 2.3.0. Before changing the recipient's state, inspect the report context and independent events that confirm any rejection.","[""The reporting system used the general X.3.0 status in a success DSN without a more specific mail system status."",""The processing layer retained the general 2.3.0 code but did not expose more detailed report context.""]","[""Correlate the report with the intended message and send attempt, then review the surrounding context and later events to establish the final outcome."",""If the system displays 2.3.0 as a bounce or rejection, trace the parser, normalization rules, and event mapping.""]","{""sender_admin"":[""Classify 2.3.0 as success; do not trigger a retry or automatic suppression solely because of this code."",""Retain the raw report and correct event mapping if the code was routed into rejection handling.""],""recipient_admin"":[""If independent signs of a problem exist, inspect destination-system logs for the correlated transaction; do not infer a rejection or outage from code 2.3.0 alone."",""When the receiving system generated the report, retain the code with enough context to distinguish success from an error.""],""provider"":[""Do not present 2.3.0 as a rejection; if a more specific mail system status is available, retain it alongside the general code.""]}","[""4.3.0"",""5.3.0"",""2.3.6"",""4.3.1""]","esc-2-3-0","indeterminate","unknown","unverified","do_not_retry","no_recommendation","low","true"5"email-error-2-3-6","2.3.6","X.3.6","2-3-6","https://blazalek.com/en/email-errors/2-3-6","mail-system","success","do_not_retry","check_context","[""sender_admin"",""recipient_admin"",""provider""]","2.3.6 — Requested priority was changed","The message was accepted for relay or delivery, but the requested priority—including a possible implied default—was not retained. The system reported a new priority instead. This is a success status, not a rejection.","The message was accepted, but the requested priority was changed: success, not rejection. Note the new priority operationally. Do not retry. Deliverability and list hygiene are unaffected; this status is informational.","A priority adjustment at acceptance is what X.3.6 reports under success class 2: the message was accepted for relay or delivery, yet the requested priority was not retained, including an implied default treated as requested. Subject family 3 covers mail-system handling, and the leading digit 2 marks acceptance rather than the temporary or permanent system failures seen in 4.3.x. The human-readable text after the status code carries the replacement priority value per the status-code list format. The code reports that adjustment but does not establish rejection, invalid recipient status, or that the new priority will affect downstream delivery timing.","Code X.3.6 means that a message was accepted for relay or delivery even though the requested priority was not honored. The human-readable text after the status code contains the new priority, then SP (a space), then explanatory text.","The leading digit 2 denotes success. Code 2.3.6 reports a priority change when the message is accepted; it does not describe a temporary error, a permanent error, or a rejection.","Do not retry based on code 2.3.6 alone because the message was accepted. If the workflow depends on priority, inspect the reported new priority and the full event context before making a manual decision instead of resending automatically.","Do not add the address or domain to a suppression list based on code 2.3.6 alone. The code does not by itself report an invalid recipient; make a suppression decision only after checking other independent events for the message and recipient.","[""The system accepting the message applied a different priority from the one explicitly requested."",""An implied default treated as the requested priority was not retained, and the system reported a replacement value.""]","[""Read the text after the status code: identify the new priority, the following space, and the explanatory text."",""Compare the reported new priority with the requested or implied default priority, and correlate the response with the correct transaction in the logs.""]","{""sender_admin"":[""Treat 2.3.6 as success and do not trigger automatic retry or suppression solely because of this code.""],""recipient_admin"":[""If the priority change is unexpected, inspect the receiving system configuration responsible for priority handling."",""Compare the reported new priority with the expected behavior for this transaction and share the findings with the sender administrator.""],""provider"":[""Classify 2.3.6 as success and do not route it into automatic rejection handling."",""Retain the code, new priority, and explanatory text in the raw event so the change can be confirm.""]}","[""2.3.0"",""4.3.0"",""4.3.1"",""4.3.2""]","esc-2-3-6","indeterminate","unknown","unverified","do_not_retry","no_recommendation","high","true"6"email-error-2-5-0","2.5.0","X.5.0","2-5-0","https://blazalek.com/en/email-errors/2-5-0","delivery-protocol","success","do_not_retry","check_context","[""sender_admin"",""provider""]","2.5.0 — Other or undefined protocol status","Code 2.5.0 is a general status concerning the protocol needed to pass the message to the next system. It provides no more specific detail, but the leading digit 2 means success, not rejection.","General protocol-related success status without finer detail. Treat as acceptance, not failure: wrong bounce handling harms deliverability metrics. Success class: do not retry. Reputation and list hygiene are unaffected.","On the delivery-protocol path to the next hop, no finer available detail code fit, so the report uses status-code list pattern X.5.0 in success class 2 as code 2.5.0. Subject family 5 covers SMTP and related delivery-protocol details, and the leading digit 2 classifies the reported outcome as success despite the broad protocol subject. The .0 detail position marks an undefined or catch-all protocol status rather than a named command, syntax, or session fault. The code alone does not establish a protocol error at rejection severity, final hop completion, or that no separate failure event exists elsewhere in the message history.","Pattern X.5.0 means that something was wrong with the protocol needed to deliver the message to the next hop and that this condition cannot be adequately expressed by another available detail code. In the 2.5.0 variant, the enhanced status class indicates success.","The leading digit 2 denotes success. Code 2.5.0 is not a temporary or permanent error and does not by itself confirm a bounce or rejection, even though its detail part describes a general protocol problem.","Do not retry based on code 2.5.0 alone because it belongs to the success class. An automatic retry could create a duplicate; if another independent event indicates failure, evaluate that event separately under the applicable retry policy.","Do not add the recipient to a suppression list based solely on code 2.5.0. Inspect the full transaction context and other independent delivery or rejection events before making a suppression decision.","[""The reporting system returned the general X.5.0 status because the protocol condition could not be described by a more specific available code."",""The processing layer retained the broad 2.5.0 code but did not expose the surrounding command, response, or report context.""]","[""Correlate the event with the intended message and transaction stage, then review the command, response text, and later events to establish the available protocol context."",""If the system displays 2.5.0 as a bounce or rejection, trace the parser, normalization rules, and event mapping.""]","{""sender_admin"":[""Classify 2.5.0 as success and do not trigger automatic retry or suppression solely because of this code.""],""provider"":[""If a more specific protocol status is available, expose it alongside the general code instead of presenting 2.5.0 as a rejection.""]}","[""4.5.0"",""5.5.0"",""4.5.1"",""4.5.3""]","esc-2-5-0","indeterminate","unknown","unverified","do_not_retry","no_recommendation","low","true"7"email-error-2-6-4","2.6.4","X.6.4","2-6-4","https://blazalek.com/en/email-errors/2-6-4","message-content-format","success","do_not_retry","check_context","[""sender"",""sender_admin"",""provider""]","2.6.4 — Conversion with data loss performed","The message was delivered, but delivery required a conversion in which some data was lost. This is a successful-result warning, not a rejection.","Delivery succeeded after a conversion that lost some data: a success warning, not rejection. Operationally important for content integrity. Do not retry the send. Deliverability stands; reputation is unaffected, but confirm whether partial data loss matters to recipients.","Successful delivery can still warn about content change: pattern X.6.4 in class 2 signals that the receiving path completed a required conversion but could not keep every original element intact. Treat this as a success-class advisory. The message reached the recipient system, yet parts of the content may no longer match what was sent. The code alone does not name the lost fields or say whether the sender forbade lossy conversion; those answers come from the response text and the sending requirements.","X.6.4 means conversion with data loss. Under code 2.6.4, class 2 confirms delivery succeeded while warning that the required conversion did not preserve every original data element. The same underlying condition can count as a permanent failure when the sender forbade conversion with loss, but code 2.6.4 itself stays a success status.","The leading digit 2 denotes success. Code 2.6.4 reports delivery after a conversion that lost data; it does not describe a temporary error, a permanent error, or a rejection of this attempt.","Do not retry automatically based on code 2.6.4 alone because the message was delivered. If the lost data matters, establish the scope of the conversion and only then consider deliberately sending a corrected version in an appropriate format; retrying the same message may produce the same result or create a duplicate.","Do not add the address or domain to a suppression list based on code 2.6.4 alone. The code does not indicate an invalid or unreachable recipient; make a suppression decision only from other independent events and the full context.","[""Delivery required the message to be converted, and the conversion could not preserve all of the data.""]","[""Correlate the warning with the intended message and recipient, then retain the complete response text to determine whether the report gives additional context about the conversion."",""Compare the sent message with the delivered result, if available, and inspect the sending requirements to determine whether lossy conversion was prohibited or whether a corrected version is needed.""]","{""sender"":[""Treat 2.6.4 as successful delivery with a warning, and do not resend the same message solely because the code appeared."",""If preserving all content matters, inspect the result and prepare a corrected version only after determining what was lost during conversion.""],""sender_admin"":[""Classify 2.6.4 as success while retaining the data-loss warning separately; do not route it automatically into rejection handling."",""Retain the raw report and conversion requirements, and if the loss is unacceptable, help select a format or delivery path that does not require the same conversion.""],""provider"":[""Preserve code 2.6.4 and the full warning text in the success event so that conversion information is not lost during normalization."",""Do not present 2.6.4 as a bounce or as a basis for automatic retry or suppression.""]}","[""2.6.8"",""5.6.3"",""5.6.6"",""5.6.7""]","esc-2-6-4","indeterminate","unknown","unverified","do_not_retry","no_recommendation","high","true"8"email-error-2-6-8","2.6.8","X.6.8","2-6-8","https://blazalek.com/en/email-errors/2-6-8","message-content-format","success","do_not_retry","check_context","[""sender"",""sender_admin"",""provider""]","2.6.8 — Required UTF-8 reply not permitted by the SMTP client","A reply needed to show the mailbox name would have to contain a UTF-8 string, but the SMTP client does not permit that form of reply. Code 2.6.8 reports this as a success status, not a rejection.","Operationally relevant for mailbox-name display limits. Do not retry. Deliverability and list hygiene are unaffected.","Displaying a mailbox name would require a UTF-8 string in the reply, but the SMTP client's restrictions block that form; pattern X.6.8 under class 2 records that presentation constraint in an otherwise successful SMTP exchange rather than a delivery failure. The code does not assert that the mailbox is invalid or unreachable. Whether UTF-8 display is required, and which client setting blocked it, must be read from the full response and client configuration, not from the enhanced code alone. The success class still applies even though the reply cannot show the name in UTF-8.","The X.6.8 pattern means that displaying the mailbox name requires a reply that contains a UTF-8 string, but the SMTP client does not allow such a reply. In the concrete code 2.6.8, class 2 qualifies this condition as success.","The leading digit 2 denotes success. Code 2.6.8 does not describe a temporary error, a permanent error, or a rejection; it reports a limitation on the form of the reply within a success-class result.","Do not retry the SMTP operation automatically based on code 2.6.8 alone because it is a success status. If displaying the mailbox name in UTF-8 is necessary, first establish the client restriction and the full response context, and only then consider a deliberate new attempt; without a change in conditions, it may produce the same result.","Do not add the address or domain to a suppression list based on code 2.6.8 alone. The code does not state that the mailbox is invalid or unavailable; make a suppression decision only from other independent events and the full context.","[""The server needs to use a UTF-8 string to show the mailbox name in its reply, but the SMTP client's restrictions do not allow that reply to be returned.""]","[""Correlate the code with the relevant SMTP operation and retain the complete response text to confirm that it concerns a mailbox name requiring a UTF-8 string."",""Inspect the SMTP client configuration and recorded behavior together with available server logs to determine why the client did not permit a reply containing UTF-8.""]","{""sender"":[""Treat 2.6.8 as a success status and do not repeat the same operation solely because this code appeared."",""If you need the UTF-8 mailbox name, give the administrator the complete response and context; do not infer from this code alone that the recipient address is invalid.""],""sender_admin"":[""If the mailbox name must be shown, correct the client-side configuration or handling and confirm the result with a controlled new attempt without triggering automatic suppression.""],""provider"":[""Preserve code 2.6.8 and the complete response text as a success-class event; do not present it as a bounce or rejection."",""Expose the available mailbox-name context and UTF-8 reply restriction so that an administrator can diagnose the client behavior without guessing.""]}","[""5.6.8"",""2.6.4"",""5.6.3"",""5.6.6""]","esc-2-6-8","indeterminate","unknown","unverified","do_not_retry","no_recommendation","medium","true"9"email-error-2-7-0","2.7.0","X.7.0","2-7-0","https://blazalek.com/en/email-errors/2-7-0","security-authentication-policy","success","do_not_retry","check_context","[""sender"",""sender_admin"",""recipient_admin"",""provider""]","2.7.0 — Other or undefined security status (success)","The mail system reported a general security-related status that could not be described by a more specific code. The leading digit 2 denotes success, not message rejection.","General security-related success status without a more specific code. Not a failure or rejection: avoid treating it as a bounce. Do not retry. Deliverability is usually unaffected; reputation impact depends on context, not this code alone.","Even with security as the subject, class 2 still applies: pattern X.7.0 under class 2 lands the reported condition in the success category. The reporting system could not assign the security-related event to a more specific detail code, or an active security policy blocked a finer description. As a general success status, 2.7.0 confirms that the transaction outcome belongs to class 2 without naming a particular authentication or policy mechanism. The code alone does not identify which security control applied, and it does not justify treating the event as a bounce or a permanent refusal.","The X.7.0 pattern denotes another or undefined security status: a security-related condition cannot be expressed adequately by any of the other detail codes, or an active security policy prevents a more detailed description. In the concrete code 2.7.0, the enhanced status class indicates success.","The leading digit 2 denotes success. Code 2.7.0 does not describe a temporary or permanent error and does not by itself confirm a bounce or rejection, even though its detail part concerns security.","Do not retry based on code 2.7.0 alone because it is a success status. An automatic retry could create a duplicate; if the expected outcome is not visible, inspect the full event context first.","Do not add the recipient to a suppression list based solely on code 2.7.0. Make a suppression decision only after checking the context and other independent delivery or rejection events.","[""The reporting system used the general X.7.0 pattern because the security-related condition could not be expressed by a more specific available code."",""An active security policy prevented the system from disclosing a more detailed description of the condition.""]","[""Review the complete response text, transaction stage, and later events; do not infer a specific authentication or policy cause from the general X.7.0 code."",""If the system displays 2.7.0 as a bounce or rejection, trace the parser, normalization rules, and event mapping.""]","{""sender"":[""Treat 2.7.0 as a successful result and do not resend the same message solely because this code appeared."",""If the expected outcome is not visible, give the sender administrator the complete event context instead of assuming a specific security cause.""],""sender_admin"":[""Classify 2.7.0 as success; do not trigger an automatic retry or suppression solely because of this code.""],""recipient_admin"":[""When the event needs explanation, inspect receiving-system logs for the correlated transaction without inferring rejection from code 2.7.0 alone."",""Provide additional context only to the extent permitted by the active security policy.""],""provider"":[""Preserve the success class, exact code, and complete available response text when normalizing the event."",""Do not present 2.7.0 as a bounce; when policy permits and a more specific status is available, retain it together with the event context.""]}","[""4.7.0"",""5.7.0"",""4.7.1"",""4.7.12""]","esc-2-7-0","indeterminate","unknown","unverified","do_not_retry","no_recommendation","low","true"10"email-error-4-0-0","4.0.0","X.0.0","4-0-0","https://blazalek.com/en/email-errors/4-0-0","other-undefined","temporary_failure","retry","check_context","[""sender_admin"",""provider""]","Other undefined temporary status","Code 4.0.0 is a general temporary failure: only class 4 is known, with no more specific status. The message may be retried in a controlled way.","Generic temporary failure when only class 4 is known: no finer cause in the response. Operationally prefer controlled retry over list removal. Transient: retry in a controlled way. Unbounded retries add queue noise; reputation harm is unlikely if retry is bounded.","Only the temporary-failure class is known when systems emit the concrete form of status-code list pattern X.0.0 as 4.0.0. The enhanced status carries no subject-family detail beyond the leading digit 4, so the reply signals a transient condition without naming its cause. Class 4 means the current attempt failed to complete successfully, yet the outcome may still change on a later try. The code does not establish an invalid recipient, a content fault, or a policy block; telling those apart requires richer status detail or a record of repeated attempts.","The X.0.0 pattern is the only undefined status code; systems use it when only the result class is known. In the 4.0.0 form, that result class is temporary failure.","This is a temporary status, not a permanent rejection. The code alone neither identifies the cause nor establishes that the recipient address is invalid.","Retry with exponential backoff and jitter, preserving idempotency and enforcing an attempt limit. Stop retrying after success or a more specific permanent status; route repeated 4.0.0 results for investigation.","Do not add the address to a suppression list based on code 4.0.0 alone. Inspect the full response, attempt history, and other events; suppress only when an independent permanent signal or the applicable policy justifies it.","[""The receiving server reported a temporary failure without providing a more specific enhanced code."",""The response-processing system retained only class 4 or replaced a more specific status with the general 4.0.0 code.""]","[""Inspect the raw SMTP transaction response and confirm that it contains the exact enhanced code 4.0.0."",""Trace response mapping in logs and webhooks to determine whether a more specific status was lost or normalized to 4.0.0."",""Compare the result of the next controlled attempt and stop automated retries if it succeeds or returns a permanent rejection.""]","{""sender_admin"":[""Route the message to a bounded retry queue with idempotency, exponential backoff, and jitter; do not retry indefinitely.""],""provider"":[""Review normalization rules and the available information of the temporary failure when available detail is replaced by the general 4.0.0 code.""]}","[""2.0.0"",""5.0.0""]","esc-4-0-0","transient","unknown","unverified","retry_with_backoff","no_recommendation","low","false"11"email-error-4-1-1","4.1.1","X.1.1","4-1-1","https://blazalek.com/en/email-errors/4-1-1","addressing","temporary_failure","retry","check_context","[""sender"",""sender_admin""]","4.1.1 — Temporary destination mailbox address problem","The receiving system did not find the specified mailbox during this attempt. Because the code begins with 4, this is a temporary failure: delivery may be retried in a controlled way, but the code alone does not yet establish that the address is permanently invalid.","The receiving system did not find the mailbox this attempt: a temporary addressing failure, not yet a hard bounce. Retry in a controlled way after checking the address. Do not remove from lists yet; premature suppression hurts deliverability if the mailbox reappears.","Pairing detail X.1.1 with class 4 yields an unusual reading: the recipient host reported that no such mailbox existed on this delivery attempt. Pattern X.1.1 normally names a nonexistent local part, yet the leading digit marks a transient failure class rather than a permanent one. The status flags a pass-through addressing fault for this try; it does not establish a typo, account removal, or that the mailbox will never exist.","Under pattern X.1.1, the mailbox named in the address does not exist; for an Internet mail address, the local part to the left of the ""@"" sign is invalid. The standards text notes that this addressing detail is useful only for permanent failures, whereas the concrete code 4.1.1 attaches it to temporary class 4 and therefore needs careful reading in the full response context.","The leading digit 4 denotes a persistent transient failure: the current attempt failed, but the condition may clear.","Check the recipient address first and, if there is no confirmed error, schedule another attempt with backoff and an attempt limit. Stop automatic retries when the limit is reached or a permanent result arrives; do not assume that further attempts will repair an incorrect address.","Do not add the address to a suppression list based on 4.1.1 alone.","[""The mailbox identifier to the left of the “@” sign is incorrect or does not correspond to a mailbox known to the receiving system."",""The receiving system did not find the mailbox during the current attempt but returned temporary class 4 instead of a permanent addressing code.""]","[""Compare the recipient address with a trusted available information value, paying particular attention to the mailbox identifier before the “@” sign; do not guess the correct address."",""Review the attempt history for the same message and address to determine whether the problem cleared, repeated, or was later reported as a permanent addressing failure.""]","{""sender"":[""confirm the address against a value supplied or confirmed by the recipient, and change it only when you have a reliable correction."",""Do not resend manually without a limit; if the address appears correct, leave the next attempt to the controlled retry mechanism.""],""sender_admin"":[""After the attempt limit is exhausted or a permanent result appears, stop retrying and evaluate suppression from the full history rather than from code 4.1.1 alone.""]}","[""5.1.1"",""4.1.8"",""2.1.5"",""5.1.3""]","esc-4-1-1","transient","recipient_invalid","unverified","retry_with_backoff","no_recommendation","medium","true"12"email-error-4-1-8","4.1.8","X.1.8","4-1-8","https://blazalek.com/en/email-errors/4-1-8","addressing","temporary_failure","retry","check_context","[""sender"",""sender_admin""]","4.1.8 — Temporary sender system address problem","This attempt reported a problem with the system identified by the sender address. Because the code begins with 4, it is a temporary failure: delivery may be retried in a controlled way, but the sender address and system configuration should be checked first.","Problem with the sender system identified by the From address: a temporary failure. Check sender configuration and DNS before retrying. Transient: controlled retry is appropriate. Repeated failures can affect sender reputation; fix the sender side.","On the sender side of the address, temporary failure 4.1.8 applies status-code list pattern X.1.8: during this attempt the sender system named in the From address could not be validated, or could not be reached for return-path purposes. Class 4 places the outcome in the transient failure category of the enhanced status register. The detail concerns the domain or system after the @, not the recipient mailbox. The code does not establish a bad recipient address, a permanent sender-domain misconfiguration, or that unlimited retries are safe without checking sender-side DNS and return-mail acceptance.","The X.1.8 status-code list pattern states that the sender system specified in the address does not exist or cannot accept return mail. For a domain name, the part of the address to the right of the ""@"" is invalid for mail handling.","The leading digit 4 denotes a temporary failure: the current attempt failed, but the condition may clear. The code does not authorize unlimited retries or establish a permanent problem with the recipient address.","After checking the sender address, schedule bounded retries with backoff and an attempt limit. Stop after success, a permanent result, or exhaustion of the limit; route repeated 4.1.8 results for configuration repair instead of retrying indefinitely.","Do not automatically add an address to a suppression list based on 4.1.8 alone. Evaluate the sender address, the sender system's ability to accept return mail, the full response, and the results of bounded retries; in particular, this code alone does not justify suppressing the recipient.","[""The domain part of the sender address is incorrect or does not identify a system configured to handle mail."",""The sender system identified by the address cannot accept return mail during the current attempt.""]","[""Read the sender address identified in the failed attempt and compare the part after the “@” sign with trusted configuration; confirm that the domain is intended to handle mail."",""Check the sender system configuration and logs for its ability to accept return mail, then compare the next controlled attempt with the earlier history.""]","{""sender"":[""confirm the sender address used for the message and change it only when you have a reliable replacement value."",""If the address is correct, do not resend manually without a limit; escalate a recurring problem to the sender system administrator.""],""sender_admin"":[""Review sender-address construction and the domain and system configuration so that the identified system exists and can accept return mail."",""Handle 4.1.8 as temporary with bounded retries and backoff, retain the raw responses, and pause the affected flow for diagnosis after the limit instead of automatically suppressing the recipient.""]}","[""5.1.8"",""4.1.1"",""2.1.5"",""5.1.1""]","esc-4-1-8","transient","infrastructure","unverified","retry_after_correction","no_recommendation","high","false"13"email-error-4-2-0","4.2.0","X.2.0","4-2-0","https://blazalek.com/en/email-errors/4-2-0","mailbox","temporary_failure","retry","check_context","[""sender"",""recipient"",""recipient_admin""]","4.2.0 — Recipient mailbox temporarily unavailable (other/undefined mailbox status)","The receiving system reports that the mailbox exists but is temporarily unable to accept the message for an unspecified reason. The code belongs to the temporary class: delivery may succeed on a later attempt.","The recipient mailbox is temporarily unavailable for an unspecified reason: transient, not permanent. Retry with an attempt limit and spacing; do not suppress the address on a single 4.2.0.","status-code list pattern X.2.0 (""Other or undefined mailbox status"") is a deliberately generic catch-all; code 4.2.0 merely assigns it a transient class. SMTP specification defines that pattern only as ""the mailbox exists, but something about the destination mailbox has caused the sending of this DSN,"" without naming the specific condition. This catalog's mechanical enhanced status-code confirmation leaves X.2.0 fully unresolved: neither class 4 nor class 5 carries a confirmed class. What the status names is an unspecified mailbox-side hold at this attempt; it does not establish an over-quota, disabled-account, or rate-limit condition, each of which has its own, more specific code.","As the mailbox-status subject's explicit fallback, the X.2.0 pattern applies when a destination mailbox has some kind of problem accepting the message, but the more specific X.2.1-X.2.4 details do not apply or were not distinguished by the sending system. SMTP specification describes it generically and does not settle the class for any concrete use; in this catalog, the enhanced status-code status-code list does not mechanically confirm any class for X.2.0.","The leading digit 4 denotes a persistent transient failure: at the moment of this attempt something about the recipient mailbox prevented delivery, but the condition is expected to clear without any change on the sender's side. Do not read 4.2.0 as more specific than it is: it does not confirm an over-quota mailbox (4.2.2), a rate limit (4.2.1), or a disabled account (5.2.1) — the sending system used the generic detail because it either could not or chose not to report a more precise one.","Retry with backoff, jitter, idempotency, and an attempt or time limit. Stop retrying after success, after a permanent code appears (e.g. 5.2.2, 5.1.1), or once the limit is exhausted; do not treat a single 4.2.0 as grounds to stop retrying immediately, and do not reclassify it as a more specific condition (over quota, rate limit) unless the response text says so.","Do not add the address to a suppression list based on code 4.2.0 alone — it is the status-code list's generic catch-all and carries less diagnostic information than a specific code. Inspect the full response and the history of bounded retries within the relevant window; suppress only after an independent permanent signal (an actual 5.x code) or when the applicable list policy justifies it.","[""The receiving system applies a temporary, unspecified hold to the destination mailbox — for example, a brief provider-side check or a greylisting-style delay — without mapping it to one of the more specific mailbox codes (over quota, rate limit, disabled).""]","[""Because 4.2.0 is generic, do not guess at the specific cause; if the condition persists past a reasonable retry window, ask the recipient (or, in a business setting, their administrator) whether the mailbox has a known issue — quota, suspension, or a provider-side hold."",""Compare the results of bounded retries over time and stop them after success, after a permanent code appears, or once the configured attempt limit is reached.""]","{""sender"":[""Retry with backoff and an attempt limit; do not suppress the address based on a single 4.2.0, and do not assume a more specific cause (quota, rate limit) than the response states."",""If the code persists past a reasonable retry window, reach the recipient through another channel and share the code, attempt time, and message context.""],""recipient"":[""If you notice repeated 4.2.0 deferrals reported by a sender, check your mailbox for any provider-side notice (quota, suspension, temporary hold) even though the code itself does not name one."",""If a domain administrator manages your account, ask them to check for any temporary restriction on the mailbox.""],""recipient_admin"":[""Check the account for quota, suspension, or policy holds that might produce this generic response, and confirm with the mailbox provider if nothing is visible on your side."",""If the condition recurs without an identifiable administrative cause, treat it as a provider-side transient hold and advise senders to keep retrying within a bounded window.""]}","[""4.2.4"",""5.2.2"",""5.2.3""]","esc-4-2-0","transient","mailbox_state","unverified","retry_with_backoff","no_recommendation","low","false"14"email-error-4-2-1","4.2.1","X.2.1","4-2-1","https://blazalek.com/en/email-errors/4-2-1","mailbox","temporary_failure","retry","check_context","[""sender"",""recipient"",""recipient_admin""]","4.2.1 — Recipient mailbox temporarily not accepting messages (receiving-rate limit)","The receiving system reports that the mailbox exists but is not currently accepting messages, most often because the recipient is receiving mail faster than the system allows. The code belongs to the temporary class: the condition is expected to clear, so delivery may be retried in a controlled way.","The recipient mailbox is temporarily not accepting messages, typically because of a receiving-rate limit rather than a truly disabled account: transient, not permanent. Retry with an attempt limit and spacing; do not suppress the address on a single 4.2.1. If the code persists well past a reasonable window, or a permanent code from the same mailbox family appears (see Related codes), treat that as the durable signal instead.","On status-code list pattern X.2.1 (""Mailbox disabled, not accepting messages""), code 4.2.1 carries a transient class: the recipient mailbox exists, but on this attempt it is not accepting new messages. identified behavior is narrower than the status-code list's generic wording: production systems chiefly return this code to report a temporary receiving-rate limit on one recipient, not a mailbox that has been switched off.","SMTP specification frames X.2.1 as covering a destination mailbox that exists yet will not accept messages at this attempt, whether because it has been switched off or because some other condition blocks delivery. The same detail may describe either a permanent condition (the mailbox will never be re-enabled) or a persistent transient condition (the mailbox is only temporarily disabled), without settling the class itself. In this catalog's enhanced status-code mirror, the status-code list lists no Associated Basic Status Code for X.2.1 at all, so no class is mechanically confirmed here, unlike X.2.2, where the status-code list confirms class 5.","The leading digit 4 denotes a persistent transient failure: at the moment of this attempt the mailbox is not accepting messages, but the condition is expected to clear once the receiving rate or other transient condition subsides. Do not conflate this with a permanent mailbox-status failure, where the same general X.2.x family of detail codes describes a condition unlikely to resolve on retry.","Retry with backoff, jitter, idempotency, and an attempt or time limit. Stop retrying after success, after a permanent code appears, or once the limit is exhausted; do not treat a single 4.2.1 as grounds to stop retrying immediately.","Do not add the address to a suppression list based on code 4.2.1 alone. Inspect the full response and the history of bounded retries within the relevant window; suppress only after an independent permanent signal in the same mailbox-status family (see Related codes) or when the applicable list policy justifies it.","[""The sending pattern itself looks like a spike (a bulk resend, a list explosion, a retried batch) and the receiving system is using this code as an anti-abuse throttle rather than a statement about the mailbox's long-term status.""]","[""Correlate the response with the specific message, attempt time, and recipient address; retain the full response text, including any provider link such as a receiving-rate support article."",""Check whether the same recipient keeps returning 4.2.1 across many messages and senders (suggesting an account-wide throttle or hold) or only for this one burst (suggesting an ordinary transient rate limit)."",""Compare the results of bounded retries over time and stop them after success, after a permanent code appears, or once the configured attempt limit is reached.""]","{""sender"":[""Retry with backoff and an attempt limit, spacing out repeated sends to the same recipient; do not suppress the address based on a single 4.2.1."",""If the code persists past a reasonable retry window, reach the recipient through another channel and share the code, attempt time, and message context.""],""recipient"":[""If you are not expecting a burst of mail, check for automated forwarding loops, mailing-list subscriptions, or account compromise that might be generating the volume triggering the limit."",""If a domain administrator has placed a hold on the mailbox, ask them about its status and expected duration.""],""recipient_admin"":[""Check whether an organizational throttle, migration, or protective hold on this mailbox is producing the 4.2.1 response, and confirm its expected end."",""If the condition recurs for legitimate senders, review the mailbox's rate-limit configuration or hold policy rather than treating every occurrence as abuse.""]}","[""4.2.4"",""5.2.2""]","esc-4-2-1","transient","mailbox_state","unverified","retry_with_backoff","no_recommendation","medium","true"15"email-error-4-2-2","4.2.2","X.2.2","4-2-2","https://blazalek.com/en/email-errors/4-2-2","mailbox","temporary_failure","retry","check_context","[""sender"",""recipient"",""recipient_admin""]","4.2.2 — Recipient mailbox temporarily over its storage quota","The receiving system reports that the mailbox is currently over its storage limit and is not accepting messages. The code belongs to the temporary class: the recipient may free up space, so delivery may be retried in a controlled way.","The recipient mailbox is temporarily over its storage quota: transient, not permanent. Retry with an attempt limit and spacing; do not suppress the address on a single 4.2.2. If the code persists well past a reasonable window, or a permanent code such as 5.2.2/5.2.3 appears, treat that as the durable signal instead.","When the recipient mailbox exists but exceeds its storage limit on this attempt, code 4.2.2 assigns status-code list pattern X.2.2 (""Mailbox full"") a transient class rather than a permanent one. This catalog's mechanical enhanced status-code confirmation for X.2.2 covers only the class-5 variant (5.2.2, Associated Basic Status Code 552). The status names a mailbox-capacity condition at this attempt, not a permanently invalid address or an addressing error.","A destination mailbox that has exceeded an administrative storage quota or physical capacity, and that is not accepting messages, matches pattern X.2.2. SMTP specification describes this pattern generically, without settling the class for every possible use. In this catalog the enhanced status-code status-code list mechanically confirms only the class-5 variant (5.2.2, basic SMTP code 552), which is a permanent rejection.","The leading digit 4 denotes a persistent transient failure: at the moment of this attempt the mailbox is over quota, but the condition may clear once the recipient frees space. Do not conflate this with 5.2.2, where the same X.2.2 pattern appears as a permanent failure.","Retry with backoff, jitter, idempotency, and an attempt or time limit. Stop retrying after success, after a permanent code appears (e.g. 5.2.2, 5.2.3), or once the limit is exhausted; do not treat a single 4.2.2 as grounds to stop retrying immediately.","Do not add the address to a suppression list based on code 4.2.2 alone. Inspect the full response and the history of bounded retries within the relevant window; suppress only after an independent permanent signal (an actual 5.2.2/5.2.3) or when the applicable list policy justifies it.","[""The recipient has exceeded their personal mailbox storage quota (consumer Gmail account) and has not yet deleted messages to free space."",""A domain administrator (Google Workspace) has set a storage quota for the account that has been exceeded, and the organization has not yet increased the allocation.""]","[""Correlate the response with the specific message, attempt time, and recipient address; retain the full response text, including any provider link (such as an over-quota support page)."",""Ask the recipient to check mailbox usage and delete unneeded messages (including trash and spam); in a business setting, ask the administrator to check the account's allocated quota."",""Compare the results of bounded retries over time and stop them after success, after a permanent code appears, or once the configured attempt limit is reached.""]","{""sender"":[""Retry with backoff and an attempt limit; do not suppress the address based on a single 4.2.2."",""If the code persists past a reasonable retry window, reach the recipient through another channel and share the code, attempt time, and message context.""],""recipient"":[""Free up mailbox space: delete unneeded messages and empty the trash and spam folders."",""If a domain administrator controls the quota, ask them to increase the storage allocation for this account.""],""recipient_admin"":[""Check the account's allocated storage quota and the organization's retention policy; increase the allocation if the mailbox is business-critical."",""If the over-quota condition recurs despite the user freeing space, check whether an organizational limit or a lag in mailbox-state synchronization is producing a false signal.""]}","[""5.2.2"",""5.2.3""]","esc-4-2-2","transient","mailbox_state","unverified","retry_with_backoff","no_recommendation","high","false"16"email-error-4-2-4","4.2.4","X.2.4","4-2-4","https://blazalek.com/en/email-errors/4-2-4","mailbox","temporary_failure","retry","check_context","[""sender"",""recipient"",""recipient_admin""]","4.2.4 — Temporary mailing-list expansion problem","The receiving system recognized the destination as a mailing list but could not expand it to recipients during this attempt. The code belongs to the temporary class, so delivery may be retried in a controlled way.","The destination is a mailing list that could not be expanded this attempt: temporary, not permanent. Retry in a controlled way; do not treat as a hard bounce. List hygiene: hold suppressions until expansion succeeds or a permanent code appears.","List expansion failed on this attempt: the receiving system recognized the destination as a mailing-list address but could not expand it to individual recipients, so it returned status-code list pattern X.2.4 as a transient failure. Class 4 marks a persistent-transient condition; the same X.2.4 detail can appear under another leading digit and carry a different permanence reading. The status names a list-expansion problem, not a single-mailbox quota issue or an addressing error. Alone, it does not establish the list address is permanently invalid, identify which subsystem blocked expansion, or justify treating the bounce as a hard rejection of that list address.","status-code list pattern X.2.4 means the destination mailbox is a mailing-list address that could not be expanded. The standards description allows that detail to stand for either a permanent failure or a persistent transient failure; in the concrete code 4.2.4, the leading digit selects the transient class.","The leading digit 4 denotes a persistent transient failure: the current delivery attempt failed, but the condition may clear. The code alone neither identifies the cause of the expansion problem nor establishes that the list address is permanently invalid.","Retry with backoff, jitter, idempotency, and an attempt limit. Stop after success, a permanent result, or exhaustion of the time or attempt limit; refer repeated 4.2.4 results to the list administrator for investigation.","Do not add the list address to a suppression list based on code 4.2.4 alone. Inspect the full response and the history of bounded retries; suppress only after an independent permanent signal or the applicable policy justifies it.","[""A temporary condition in the system handling the mailing list prevented the list address from being expanded to recipients during this attempt.""]","[""Correlate the response with the intended message, attempt time, and destination address; confirm that the destination was meant to be a mailing list rather than an individual mailbox."",""Ask the recipient or list administrator to inspect the same attempt and determine whether the list can now be expanded; do not infer a specific cause from the code alone."",""Compare the results of bounded retries and stop them after success, a permanent rejection, or the configured limit is reached.""]","{""sender"":[""Confirm that the list address used is the intended destination for the message; change it only when a reliable correction is available."",""Do not resend manually without a limit. If controlled retries do not succeed, give the recipient or list contact the code, attempt time, and message context.""],""recipient"":[""Confirm to the sender whether the specified list address is the correct destination for this message."",""If the problem repeats, give the list administrator code 4.2.4 and the failed-attempt time so the expansion can be investigated.""],""recipient_admin"":[""Inspect the list-expansion mechanism's logs and state for the specified address and attempt time, then correct the condition blocking expansion."",""confirm the result after remediation; if the condition is permanent, return a permanent result instead of sustaining temporary retries.""]}","[""5.2.2"",""5.2.3""]","esc-4-2-4","transient","mailbox_state","unverified","retry_with_backoff","no_recommendation","medium","false"17"email-error-4-3-0","4.3.0","X.3.0","4-3-0","https://blazalek.com/en/email-errors/4-3-0","mail-system","temporary_failure","retry","check_context","[""sender_admin"",""recipient_admin"",""provider""]","4.3.0 — Other or undefined temporary mail-system status","The destination system exists and normally accepts mail, but a general problem in that system prevented delivery during this attempt. The leading digit 4 denotes a temporary failure, so delivery may be retried in a controlled way.","The destination mail system had a general problem preventing delivery this attempt: temporary failure without finer detail. Controlled retry is appropriate. Usually no lasting reputation hit; short-term queue impact only if retries are unbounded.","The destination host exists and normally accepts mail, yet an unspecified condition in that system stopped this delivery attempt from completing; temporary-failure class 4 places that catch-all under status-code list pattern X.3.0. The .3.0 detail means other or undefined system status, not a named quota, shutdown, or addressing fault. Class 4 means the condition may clear; it does not assume a lasting outage. The code alone does not identify the underlying fault, confirm an invalid recipient address, or settle whether a more specific enhanced code was available but unused.","The X.3.0 status-code list pattern denotes other or undefined mail-system status. The destination system exists and normally accepts mail, but a condition involving that system caused a DSN to be generated; the .3.0 detail itself does not identify a more specific problem type.","The leading digit 4 denotes a persistent transient failure: the current attempt failed, but the condition may clear. The code does not establish a permanent system failure or indicate that the recipient address is invalid.","Operational recommendation: retry with backoff, jitter, idempotency, and an attempt limit. Stop after success, a permanent result, or exhaustion of the time or attempt limit; route repeated 4.3.0 results for investigation instead of retrying indefinitely.","Operational recommendation: do not add the address to a suppression list based on 4.3.0 alone. Inspect the full response, bounded-retry history, and other events; suppress only when an independent permanent signal or the applicable policy justifies it.","[""A temporary, unspecified condition in the destination system disrupted acceptance or handling of the message during this attempt."",""The system generating the DSN reported the general X.3.0 status without a more specific code describing the mail-system problem.""]","[""Correlate the response with the intended message, attempt time, and SMTP stage; retain the full response text so that detail not present in the code itself is not lost."",""Compare sending-side and, when available, destination-side logs to determine which system generated the DSN and whether it recorded a more specific temporary condition."",""Compare the results of bounded retries and stop them after success, a permanent rejection, or the configured limit is reached.""]","{""sender_admin"":[""Group repeated 4.3.0 results by destination system and time, and after the limit is exhausted give the attempt data to the recipient administrator or applicable provider.""],""recipient_admin"":[""Inspect the destination system's state and logs for the specified time and attempt, then correct the temporary condition if it can be identified."",""After remediation, confirm that messages are accepted; when the system knows a more specific status, preserve it in the response instead of replacing it with general 4.3.0.""],""provider"":[""If you operate infrastructure involved in this attempt, retain the full SMTP response and inspect service logs for the specified time and destination system."",""Correct a confirmed temporary condition or provide administrators with any available, more specific status; do not suppress the recipient solely because of 4.3.0.""]}","[""2.3.0"",""5.3.0"",""4.3.1"",""4.3.2""]","esc-4-3-0","transient","infrastructure","unverified","retry_with_backoff","no_recommendation","low","false"18"email-error-4-3-1","4.3.1","X.3.1","4-3-1","https://blazalek.com/en/email-errors/4-3-1","mail-system","temporary_failure","retry","check_context","[""sender_admin"",""recipient_admin"",""provider""]","4.3.1 — Temporarily full mail system","The mail system exceeded its available storage during this attempt. This is a system-wide resource problem, so an individual recipient may be unable to free space on their own. Because the code begins with 4, delivery may be retried in a controlled way.","The mail system ran out of storage during this attempt: a system-wide temporary resource limit. Retry in a controlled way; the recipient alone may not fix it. Not a hard bounce; premature list removal hurts deliverability when space frees up.","Mail-system storage, not a single mailbox quota, was exceeded on this attempt: that is the temporary, system-level shortage named by status-code list pattern X.3.1. Standard semantics imply that freeing space may require operator action beyond what one recipient can do locally. Class 4 marks persistent-transient failure; the same X.3.1 pattern under digit 5 would mean permanent. The code does not name the exhausted storage component, identify which host returned it, or establish the recipient address itself is invalid.","The X.3.1 status-code list pattern means that mail-system storage has been exceeded. The standard notes that its general semantics imply an individual recipient may be unable to delete material to make room for additional messages. This detail is useful only as a persistent transient failure.","The leading digit 4 denotes a persistent transient failure: the current attempt failed, but the condition may clear. The code is not a permanent rejection and does not by itself identify the particular storage component or the owner of the system that returned it.","Operationally, retry with backoff, jitter, idempotency, and a time or attempt limit. Stop after success, a permanent result, or exhaustion of the limit; refer repeated 4.3.1 results to the recipient-system administrator or provider instead of retrying indefinitely.","Operationally, do not add the address to a suppression list based on 4.3.1 alone. Inspect the full response and the history of bounded retries; suppress only after an independent permanent signal or when the applicable policy justifies it.","[""Mail-system storage was exceeded during the current attempt.""]","[""Correlate the response with the intended message, attempt time, and system that returned it; do not infer the particular exhausted storage component from the code alone."",""Ask the recipient-system administrator or provider to inspect storage state for the same time and confirm whether capacity is available again."",""Compare the results of bounded retries and stop them after success, a permanent rejection, or the configured limit is reached.""]","{""sender_admin"":[""After the limit is exhausted, stop retrying and give the recipient-system administrator or provider the code, attempt time, and affected-flow identifier; do not suppress based on 4.3.1 alone.""],""recipient_admin"":[""Inspect the mail system's storage state and availability for the failed-attempt time, then restore available capacity if the limit was exceeded."",""confirm the result after clearing the condition; do not direct the recipient to clean up their own mailbox without separate context that its resource is involved.""],""provider"":[""If you manage the system that returned the error, inspect its storage use and limits for the specified time and clear the exceeded condition."",""After restoring the resource, confirm that a new attempt can be handled and preserve the exact status code in the response so the sender can stop retrying correctly.""]}","[""4.3.0"",""4.3.2"",""2.3.0"",""2.3.6""]","esc-4-3-1","transient","infrastructure","unverified","retry_with_backoff","no_recommendation","high","false"19"email-error-4-3-2","4.3.2","X.3.2","4-3-2","https://blazalek.com/en/email-errors/4-3-2","mail-system","temporary_failure","retry","check_context","[""sender_admin"",""recipient_admin"",""provider""]","4.3.2 — System temporarily not accepting network messages","The host on which the recipient's mailbox resides is not currently accepting messages. Because the code begins with 4, this is a temporary failure and delivery may be retried in a controlled way.","The recipient's host is not accepting messages right now: a transient mail-system condition. Controlled retry is appropriate. Not a permanent rejection or hard bounce; avoid list suppression until a permanent code confirms the address is bad.","The host that holds the recipient mailbox is not accepting network messages on this attempt, which is how status-code list pattern X.3.2 maps onto the transient class. The pattern covers conditions such as imminent shutdown, heavy load, or maintenance; a provider subcode in the full SMTP text may narrow the cause but is not part of the generic 4.3.2 meaning. The same X.3.2 detail under digit 5 would signal permanent refusal. This code does not establish an invalid recipient address, permanent host unavailability, or which operational limit was hit without reading the complete response.","status-code list pattern X.3.2 means that the host on which the mailbox resides is not accepting messages. The standard lists imminent shutdown, excessive load, and system maintenance as examples. The pattern itself can describe either a permanent or a persistent transient error; in the concrete 4.3.2 code, the leading digit assigns the result to the transient class.","The leading digit 4 denotes a persistent transient failure: the current attempt failed, but the condition may clear. The code does not by itself mean that the recipient address is invalid or establish that the host is permanently unable to accept mail.","Operational recommendation: check suppression state before every attempt, then retry with backoff, jitter, idempotency, and a time or attempt limit. Stop after success, a permanent result, or exhaustion of the limit; refer repeated 4.3.2 results to the recipient-system administrator or provider instead of retrying indefinitely.","Operational recommendation: do not add the address to a suppression list based on temporary code 4.3.2 alone. Inspect the full response, provider context, and bounded-retry history; suppress only after an independent permanent signal or when the applicable policy requires it.","[""The mailbox host is approaching shutdown and is temporarily not accepting messages."",""The host is excessively loaded or undergoing system maintenance.""]","[""Correlate the response with the intended message, attempt time, and host that returned it; retain the full text and any provider subcode because 4.3.2 alone does not identify the particular cause."",""Compare the results of bounded retries and stop them after success, a permanent rejection, or the configured limit is reached.""]","{""sender_admin"":[""Group repeated 4.3.2 results by host and time; after the limit is exhausted, stop retrying and give the collected context to the recipient-system administrator or provider.""],""recipient_admin"":[""Clear the confirmed temporary condition within your control and confirm that the host is accepting messages again before requesting another attempt.""],""provider"":[""If you operate the host that returned the error, inspect its availability, load, maintenance, and any other limits exposed by the full response for the specified time."",""Restore message acceptance after clearing the confirmed condition, and preserve the exact code and subcode in the response so that the sender can control retries correctly.""]}","[""5.3.2"",""4.3.0"",""4.3.1"",""2.3.0""]","esc-4-3-2","transient","infrastructure","unverified","retry_with_backoff","no_recommendation","high","false"20"email-error-4-4-0","4.4.0","X.4.0","4-4-0","https://blazalek.com/en/email-errors/4-4-0","network-dns-routing","temporary_failure","retry","check_context","[""sender_admin"",""recipient_admin"",""provider""]","4.4.0 — Temporary failure for an unspecified network or routing reason (other/undefined network status)","The receiving system reports a temporary failure using the generic ""other or undefined network or routing status"" code: some network-layer or routing/replication condition prevented delivery at this attempt, but the response does not identify one of the more specific network conditions this catalog also tracks (no answer from host, bad connection, directory server failure, mail system congestion, a routing loop, or delivery-time expiry). The code belongs to the temporary class: whatever condition triggered it may clear, so delivery may be retried in a controlled way.","Mail failed temporarily for an unspecified network or routing reason: transient, not permanent. Retry with an attempt limit and spacing; do not suppress the address on a single 4.4.0. The pattern is an explicit catch-all, so do not assume one cause (DNS lookup, replication) without checking the response text.","Inside the X.4 (Network and Routing Status) subject class, SMTP specification defines X.4.0 as the ""other or undefined"" catch-all for network conditions that fit none of the class's other detail codes; code 4.4.0 assigns that status-code list pattern to the temporary class. This catalog's status-code list mirror carries X.4.0 as fully unresolved: neither class 4 nor class 5 has ever received a confirmed status-code list entry for this pattern (concreteCodes is empty), a stronger evidentiary gap than a merely unconfirmed single class. The status names a generic, unspecified temporary network- or routing-layer condition at this attempt, not one of the family's more specific conditions, and not a mailbox or addressing problem.","X.4.0 is the X.4 ""Network and Routing Status"" subject's own ""other or undefined"" placeholder. SMTP specification Section 3.4 defines that subject class (X.4.0 through X.4.7) for failures tied to the network path or message routing rather than the mailbox or the address itself, and reserves X.4.0 for network or routing conditions that match none of the more specific details (X.4.1 no answer from host, X.4.2 bad connection, X.4.3 directory server failure, X.4.4 unable to route, X.4.5 mail system congestion, X.4.6 routing loop detected, X.4.7 delivery time expired). Explicitly a catch-all, SMTP specification does not tie X.4.0 to one production condition, and this catalog's enhanced status-code status-code list mirror confirms no class at all for this pattern.","The leading digit 4 denotes a persistent transient failure: at the moment of this attempt, some network- or routing-layer condition blocked delivery, but it may clear once that underlying condition resolves — a healthy secondary server becomes available again, or a DNS lookup succeeds on a later attempt. Do not conflate a 4.4.0 response with the family's more specific detail codes (4.4.1 no answer from host, 4.4.5 mail system congestion, and others): if the response instead carries one of those digits, follow that code's more specific guidance rather than this generic one.","Retry with backoff, jitter, and an attempt or time limit. Stop retrying after success, after a permanent code appears, or once the limit is exhausted; do not treat a single 4.4.0 as grounds to stop retrying immediately, since both accepted examples describe conditions (backend replication, a DNS lookup) that routinely clear on their own.","Do not add the address to a suppression list based on code 4.4.0 alone. This code's context in this catalog points to receiving-side infrastructure or DNS conditions unrelated to whether the recipient address is valid; inspect the full response and provider documentation, and suppress only after an independent permanent signal or when the applicable list policy justifies it.","[""Because the status-code list pattern is an explicit catch-all, providers reuse the same 4.4.0 digits for structurally different network- or routing-layer conditions; the digits alone do not identify which one occurred — read the accompanying response text.""]","[""Identify which provider returned the response and read its own description text carefully: the underlying cause differs across providers sharing the same 4.4.0 digits (a backend replication failure at Outlook, a DNS lookup failure at Rackspace)."",""Retry in a bounded, backed-off way and stop after success, after a permanent code appears, or once the attempt limit is reached; if the condition persists well past a reasonable window, escalate through the receiving provider's postmaster channel.""]","{""sender_admin"":[""Retry with backoff and an attempt limit; do not suppress the address based on a single 4.4.0, and do not expect a sender-side fix for a receiving-side replication or DNS condition."",""Group repeated 4.4.0 results by receiving domain and provider; if the condition persists past a reasonable retry window, reach the recipient's administrator through another channel and share the exact response text and attempt time.""],""recipient_admin"":[""Retry with backoff, jitter, and an attempt or time limit. Stop retrying after success, after a permanent code appears, or once the limit is exhausted; do not treat a single 4.4.0 as grounds to stop retrying immediately, since both accepted examples describe conditions (backend replication, a DNS lookup) that routinely clear on their own.""],""provider"":[""If you operate the receiving mail platform, keep enough redundancy in internal replication and DNS-lookup paths that a transient 4.4.0 does not recur, and prefer one of the family's more specific detail codes (4.4.1, 4.4.5, and others) over this generic catch-all where the actual condition is known."",""Preserve the exact status code and description text in the response so sending systems do not conflate this generic catch-all with a specific, independently actionable network condition.""]}","[""4.4.1"",""4.4.5"",""5.4.0""]","esc-4-4-0","transient","infrastructure","unverified","retry_with_backoff","no_recommendation","low","false"21"email-error-4-4-1","4.4.1","X.4.1","4-4-1","https://blazalek.com/en/email-errors/4-4-1","network-dns-routing","temporary_failure","retry","check_context","[""sender_admin"",""recipient_admin"",""provider""]","4.4.1 — No answer from remote host","An outbound connection attempt received no answer from the remote system. The standard indicates that the system may have been busy or unable to accept a connection. The code belongs to the temporary class, so delivery may be retried in a controlled way.","Outbound connection got no response from the remote host: a transient network/routing failure. Retry in a controlled way after checking connectivity and DNS. Usually no lasting deliverability or reputation harm if retries stay bounded.","No answer came back from the remote host on the outbound connection attempt; that is status-code list pattern X.4.1. Class 4 marks the outcome as a persistent transient failure in the enhanced status register, not a permanent rejection of the message. The standard allows that the remote system was busy or that it could not accept a connection at that moment. The code alone does not resolve which of those cases occurred, or on which side the answer was missing.","Pattern X.4.1 means no answer from the host: the outbound connection attempt went unanswered because the remote system was busy or unable to accept a connection. Under the standard, this detail is useful only as a persistent transient failure.","The leading digit 4 denotes a persistent transient failure: the current attempt failed, but the condition may clear. The code alone does not distinguish whether the remote system was busy or could not accept the connection, and it is not a permanent rejection of the message.","Operationally, route the message through a bounded retry mechanism with backoff, jitter, idempotency, and a time or attempt limit. Stop after success, a permanent result, or exhaustion of the limit; refer repeated 4.4.1 results for diagnosis instead of retrying indefinitely.","Operationally, do not add the address to a suppression list based on 4.4.1 alone. Inspect the full response, bounded-retry history, and other delivery events; suppress only when an independent permanent signal or the applicable policy justifies it.","[""The remote system was busy during the outbound connection attempt and did not answer."",""The remote system was unable to accept a connection during the current attempt.""]","[""Correlate the response with the intended message, attempt time, and remote system targeted by the connection; confirm in the connection logs that the outbound attempt received no answer."",""Ask the recipient-system administrator or provider to inspect the remote system's state for the same time and confirm whether it can currently accept connections."",""Compare the results of bounded retries and stop them after success, a permanent rejection, or the configured limit is reached.""]","{""sender_admin"":[""Group repeated 4.4.1 results by remote system and time; after the limit is exhausted, give the code and attempt data to the recipient administrator or provider, and do not suppress based on this code alone.""],""recipient_admin"":[""Inspect the remote system's state and ability to accept connections at the failed-attempt time, checking whether it was busy or unable to handle connections."",""Clear the confirmed temporary condition and confirm that the system answers a new, controlled connection attempt.""],""provider"":[""If you operate a system involved in the attempt, inspect service and connection logs for the specified time and remote system; do not assign a specific cause from the code alone."",""Restore the ability to handle connections if the problem is confirmed, and preserve the exact status code in the response so the sender can control retries correctly.""]}","[""4.4.2"",""4.4.3"",""4.4.5"",""5.4.3""]","esc-4-4-1","transient","infrastructure","unverified","retry_with_backoff","no_recommendation","high","false"22"email-error-4-4-2","4.4.2","X.4.2","4-4-2","https://blazalek.com/en/email-errors/4-4-2","network-dns-routing","temporary_failure","retry","check_context","[""sender_admin"",""recipient_admin"",""provider""]","4.4.2 — Bad connection","An outbound connection was established, but the message transaction could not be completed over it. The standard points to a timeout or inadequate connection quality. The code belongs to the temporary class, so delivery may be retried in a controlled way.","A connection was made but the message transaction could not complete: temporary network quality or timeout issue. Controlled retry is appropriate. Unbounded retries add queue load; reputation impact is usually short-lived if delivery eventually succeeds.","The outbound connection came up, yet the message transaction never completed on that path; status-code list pattern X.4.2 names that break. Class 4 signals a temporary failure, not a permanent rejection of the address or the message. The standard cites timeout and inadequate connection quality as possible causes. The enhanced status alone cannot tell which applied, or whether the fault lay with the sender, the recipient, or an intermediate hop.","An outbound connection was established but the message transaction could not be completed due to a timeout or inadequate connection quality: that is status-code list pattern X.4.2. Per the standard, this detail is useful only as a persistent transient failure.","The leading digit 4 denotes a persistent transient failure: the current attempt failed, but the condition may clear. The code alone does not establish whether the cause was a timeout or connection quality, and it is not a permanent rejection of the address or message.","Operational recommendation: check suppression state before every attempt, then retry with backoff, jitter, idempotency, and a time or attempt limit. Stop after success, a permanent result, or exhaustion of the limit; refer repeated 4.4.2 results for diagnosis instead of retrying indefinitely.","Operational recommendation: do not add the address to a suppression list based on temporary code 4.4.2 alone. Inspect the full response, provider context, bounded-retry history, and other delivery events; suppress only after an independent permanent signal or when the applicable policy requires it.","[""The message transaction did not finish before the timeout even though the connection had already been established."",""The established connection had inadequate quality for completing the message transaction.""]","[""Correlate the response with the intended message, attempt time, and both connection endpoints; retain the full response and confirm in the logs that the connection was established but the message transaction did not complete."",""Compare logs and timestamps from both sides for a timeout or signs of inadequate connection quality, without assigning either cause from the code alone.""]","{""sender_admin"":[""Group repeated 4.4.2 results by remote system and time; after the limit is exhausted, stop retrying and give the collected context to the recipient administrator or provider.""],""recipient_admin"":[""Inspect recipient-system logs for the failed transaction time and confirm whether a timeout or connection-quality problem occurred after the connection was established."",""Clear the confirmed temporary condition within your control and confirm that the message transaction completes during a new, controlled attempt.""],""provider"":[""Clear the confirmed problem in the managed layer and preserve the exact code and subcode in the response so that the sender can control retries correctly.""]}","[""4.4.1"",""4.4.3"",""4.4.5"",""5.4.3""]","esc-4-4-2","transient","infrastructure","unverified","retry_with_backoff","no_recommendation","high","false"23"email-error-4-4-3","4.4.3","X.4.3","4-4-3","https://blazalek.com/en/email-errors/4-4-3","network-dns-routing","temporary_failure","retry","check_context","[""sender_admin"",""recipient_admin"",""provider""]","4.4.3 — Directory server failure","The network system could not forward the message because a directory server was unavailable. Inability to connect to an Internet DNS server is one standards example, but the code alone does not establish that the problem involved DNS. The code belongs to the temporary class, so delivery may be retried in a controlled way.","Message forwarding failed because a directory server was unavailable: a transient routing failure. Retry in a controlled way after checking DNS/directory services. Usually no lasting reputation hit; deliverability recovers when the directory responds again.","Forwarding halted when the required directory service could not be reached: pattern X.4.3 means the network system could not forward the message further. Class 4 marks a temporary failure in the enhanced status register. The standard cites inability to connect to an Internet DNS server as one example of directory-service failure, but the code alone does not confirm DNS involvement, which service failed, or the operator of the unavailable server.","Directory server failure is what the X.4.3 pattern denotes: forwarding stopped when the required directory server could not be reached. The standard lists inability to connect to an Internet DNS server as one example of this error. That detail is useful only as a persistent transient failure in the enhanced register.","The leading digit 4 denotes a persistent transient failure: the current attempt failed, but the condition may clear. The code alone identifies neither the particular directory service nor the party responsible for its unavailability, and it is not a permanent rejection of the message.","Operationally, route the message through a bounded retry mechanism with backoff, jitter, idempotency, and a time or attempt limit. Stop after success, a permanent result, or exhaustion of the limit; refer repeated 4.4.3 results for diagnosis instead of retrying indefinitely.","Operationally, do not add the address to a suppression list based on 4.4.3 alone. Inspect the full response, bounded-retry history, and other delivery events; suppress only when an independent permanent signal or the applicable policy justifies it.","[""A directory server required to forward the message was unavailable during the current attempt."",""The network system could not connect to an Internet DNS server; the standard gives this as one example of directory server unavailability.""]","[""Correlate the response with the intended message, attempt time, and system that returned it; use available logs to determine whether forwarding stopped while accessing a directory service."",""Check the availability and connectivity of the actual directory service used in this flow; if it is Internet DNS, confirm its reachability for the same time without assuming from the code alone that DNS was the cause."",""Compare the results of bounded retries and stop them after success, a permanent rejection, or the configured limit is reached.""]","{""sender_admin"":[""Group repeated 4.4.3 results by destination system and time; after the limit is exhausted, give the code and attempt data to the recipient administrator or provider, and do not suppress based on this code alone.""],""recipient_admin"":[""If the error originated in a system you manage, inspect the availability of the directory service required to forward the message and its connectivity at the failed-attempt time."",""Restore the confirmed unavailable service or connectivity path and confirm the result of a new, controlled attempt.""],""provider"":[""If you operate a mail, directory, or network system involved in the attempt, inspect service and connectivity logs for the specified time; do not attribute the problem to DNS from the code alone."",""Restore the confirmed service or path, and preserve the exact status code in the response so the sender can control retries correctly.""]}","[""5.4.3"",""4.4.1"",""4.4.2"",""4.4.5""]","esc-4-4-3","transient","infrastructure","unverified","retry_with_backoff","no_recommendation","high","false"24"email-error-4-4-5","4.4.5","X.4.5","4-4-5","https://blazalek.com/en/email-errors/4-4-5","network-dns-routing","temporary_failure","retry","check_context","[""sender_admin"",""recipient_admin"",""provider""]","4.4.5 — Mail system congestion","A mail system could not deliver the message because it was congested. The code does not identify which system or party is responsible for that condition. It belongs to the temporary class, so delivery may be retried in a controlled way.","Delivery failed because a mail system was congested: a temporary capacity condition. Controlled retry is appropriate once load eases. Not a hard bounce; suppressing addresses prematurely risks unnecessary list hygiene loss.","Congestion at delivery time stopped a mail system from handing the message onward; status-code list pattern X.4.5 is what code 4.4.5 records for that condition. Class 4 frames a persistent transient failure: capacity may recover, so the recipient need not be treated as permanently invalid. The enhanced status does not identify which mail system was overloaded, who operates it, or which resource was congested; logs and response context beyond the status detail alone are required to diagnose that scope.","Mail system congestion is the meaning of X.4.5: the mail system was unable to deliver the message because it was congested. Under the standard, this detail is useful only as a persistent transient failure.","The leading digit 4 denotes a persistent transient failure: the current attempt failed, but the condition may clear. The code alone identifies neither the congested system, its operator, nor a particular resource, and it is not a permanent rejection of the address or message.","Operational recommendation: check suppression state before every attempt, then retry with backoff, jitter, idempotency, and a time or attempt limit. Stop after success, a permanent result, a suppression-state change that makes the recipient ineligible, or exhaustion of the limit; refer repeated 4.4.5 results for diagnosis instead of retrying indefinitely.","Operational recommendation: do not add the address to a suppression list based on temporary code 4.4.5 alone. Inspect the full response, the system that returned the code, bounded-retry history, and other delivery events; suppress only after an independent permanent signal or when the applicable policy requires it.","[""The mail system was congested and therefore could not deliver the message during the current attempt.""]","[""Correlate the response with the intended message, attempt time, and system that returned the code; determine the stage of the delivery path at which the failure occurred."",""Inspect logs from the system that returned the code for signs of congestion at the same time and confirm the problem's scope without assigning a particular resource or operator from 4.4.5 alone."",""Check suppression before each new attempt, compare bounded-retry outcomes, and stop after success, a permanent result, a recipient-eligibility change, or exhaustion of the configured limit.""]","{""sender_admin"":[""Group repeated 4.4.5 results by system and time; if the code came from a managed sender system, inspect its logs, otherwise give the collected context to the recipient administrator or provider after the retry limit is exhausted.""],""recipient_admin"":[""If the code came from a recipient system you manage, inspect its logs for the failed-attempt time and confirm whether congestion prevented delivery of the message."",""Clear the confirmed congestion condition within your control and confirm the result of a new, controlled attempt.""],""provider"":[""If you operate a mail system involved in the attempt, inspect its logs for the specified time and confirm which managed system was congested; do not assign a particular cause from the code alone."",""Clear the confirmed congestion condition in the managed system and preserve the exact status code in the response so that the sender can control retries correctly.""]}","[""4.4.1"",""4.4.2"",""4.4.3"",""5.4.3""]","esc-4-4-5","transient","infrastructure","unverified","retry_with_backoff","no_recommendation","medium","true"25"email-error-4-4-6","4.4.6","X.4.6","4-4-6","https://blazalek.com/en/email-errors/4-4-6","network-dns-routing","temporary_failure","retry","check_context","[""sender_admin"",""recipient_admin"",""provider""]","4.4.6 — Routing loop detected between mail systems","The sending or an intermediate mail system reports that this message was forwarded from system to system too many times without reaching its destination — a routing loop. The code belongs to the temporary class: once whichever forwarding rule or routing table is causing the loop gets fixed, delivery may succeed, so retrying in a controlled way is appropriate.","4.4.6 means a routing loop bounced this message between mail systems past the accepted hop limit: temporary in principle, but only if someone actually breaks the loop. Retry a bounded number of times while the forwarding rule or routing-table misconfiguration gets traced and fixed; if the condition persists past a reasonable window, stop retrying and escalate instead of hammering a path that keeps looping.","The status-code list's Associated Basic Status Code for X.4.6 is ""Not given"". That entry does not establish class 4 or class 5 mechanically, and this catalog's canonical mirror leaves the pattern's class-applicability resolution unresolved rather than treating descriptive language as class context.","A routing loop is what the X.4.6 pattern names. The message was forwarded between mail systems too many times, either because of incorrect routing tables or because a forwarding rule sent it back onto a path it had already taken. SMTP specification (Section 3.4) defines the pattern under the network-and-routing status subject and calls it useful only as a persistent transient error, without formally confirming any class. The status-code list's Associated Basic Status Code for X.4.6 is ""Not given,"" and this catalog's canonical mirror records the class-applicability resolution status as unresolved, because descriptive prose is not converted into class context here. In practice the same status-code list pattern is exclusive neither to class 4 nor to a single reply code. SMTP specification's non-exclusivity clause means a provider could equally reject or bounce a routing-loop condition under a different class or delivery mode, so always confirm the exact class and response text rather than assuming one universal treatment of X.4.6.","This differs from a hypothetical class-5 use of the same X.4.6 detail, which would treat the loop as unrecoverable by retrying.","Retry a bounded number of times with backoff, since the receiving system's own guidance treats the condition as potentially transient.","Do not suppress the recipient address based on 4.4.6 alone: the condition names a routing or forwarding misconfiguration somewhere in the path, not an invalid or unreachable address. Suppress only if an independent, address-specific permanent signal appears after the loop has been resolved and the message still cannot be delivered.","[""A recipient-side forwarding rule sends the message back toward a system that already handled it — for example, an address that forwards to another address which, directly or through a further rule, routes the message back into this same domain's path — creating a cycle the routing layer eventually aborts."",""A misconfigured routing table, MX record, or mail-relay chain sends the message hopping between systems without ever reaching a final destination, exceeding the accepted hop count before delivery completes.""]","[""Trace the message's path across mail-flow logs or Received: headers to identify which hop forwards the message back into a path it already took; look specifically at recipient-side forwarding rules and at any relay or routing-table entries touching this domain or address."",""Ask whoever administers the affected mailbox or domain whether a forwarding rule was recently added or changed, and whether any routing table, mail-relay, or MX configuration was modified around the time the loop started.""]","{""sender_admin"":[""Check whether your own outbound routing tables, relay chain, or auto-forwarding configuration contributes to the loop before assuming the fault lies entirely with the recipient's system; correct any hop that sends messages back through a path they already took.""],""recipient_admin"":[""Check forwarding rules on the affected mailbox or domain for a cycle — a rule that forwards to an address which, directly or through another rule, sends the message back into this domain's path."",""Review MX records and any routing or relay configuration for stale or conflicting entries that could route mail in a loop instead of to its final destination, and correct the entry that closes the cycle.""],""provider"":[""Confirm the hop-count or loop-detection threshold that triggered the rejection, and if the sender's postmaster escalates, help trace which hop in the path is looping so the responsible administrator can fix it."",""If the condition recurs for the same account or domain rather than being a one-off, flag it internally so a stale forwarding rule can be caught before the next sender hits the same loop.""]}","[""4.4.1"",""4.4.5"",""5.4.0"",""5.4.6""]","esc-4-4-6","transient","infrastructure","unverified","retry_after_correction","no_recommendation","medium","true"26"email-error-4-5-0","4.5.0","X.5.0","4-5-0","https://blazalek.com/en/email-errors/4-5-0","delivery-protocol","temporary_failure","retry","check_context","[""sender_admin"",""provider""]","4.5.0 — Other or undefined temporary protocol status","A problem occurred with the protocol needed to pass the message to the next system, but no other detail code described it adequately. The leading digit 4 makes this a temporary result, so delivery may be retried in a controlled way.","A protocol problem occurred while passing the message on: temporary failure without a more specific code. Check SMTP logs, then retry in a controlled way. Transient: unbounded retries add noise; deliverability impact is usually short-term.","When pattern X.5.0 meets class digit 4, the result is code 4.5.0: the protocol required to move the message to the next hop failed in a way no other available detail code could describe adequately. Class 4 keeps the outcome a persistent transient failure rather than a permanent protocol rejection. Because this is a catch-all, the code alone does not name the failing command, transaction stage, or underlying protocol fault; codes such as 4.5.1 or 4.5.3 become candidates only after the full SMTP exchange is inspected.","Something was wrong with the protocol required to hand the message onward to the next hop, and no other available detail code can express that condition adequately: that is X.5.0. In the concrete 4.5.0 code, the leading digit assigns the result to the transient class.","The leading digit 4 denotes a persistent transient failure: the current attempt failed, but the condition may clear. This is a general code: by itself it identifies neither a particular command, transaction stage, nor cause of the protocol problem, and it is not a permanent rejection of the message or address.","Operational recommendation: check suppression state before every attempt, then retry with backoff, jitter, idempotency, and a time or attempt limit. Stop after success, a permanent result, or exhaustion of the limit; refer repeated 4.5.0 results for diagnosis instead of retrying indefinitely.","Operational recommendation: do not add the address to a suppression list based on temporary code 4.5.0 alone. Inspect the full response, transaction stage, bounded-retry history, and other delivery events; suppress only after an independent permanent signal or when the applicable policy requires it.","[""A temporary protocol problem occurred while passing the message to the next system, and the reporting system could not describe it with a more specific available code.""]","[""Correlate the response with the intended message, attempt time, transaction stage, and next system on the path; retain the full command, response, and available logs because the code itself is general."",""Use the retained context to determine whether a more specific protocol status, such as 4.5.1, 4.5.3, or 4.5.4, describes the condition; do not assign any of them from 4.5.0 alone."",""Compare the results of bounded retries and stop them after success, a permanent rejection, or the configured limit is reached.""]","{""sender_admin"":[""Group repeated 4.5.0 results by next system, stage, and time; after the limit is exhausted, stop retrying, give the collected context to the provider, and do not suppress based on this code alone.""],""provider"":[""If you operate a system involved in the handoff, inspect logs and the available protocol trace for the specified time, stage, and next system; do not assign a specific cause from the code alone."",""Clear the confirmed temporary problem in the managed layer and preserve the exact class and response context; if a more specific protocol status is known, return it instead of general code 4.5.0.""]}","[""2.5.0"",""5.5.0"",""4.5.1"",""4.5.3""]","esc-4-5-0","transient","infrastructure","unverified","retry_with_backoff","no_recommendation","low","false"27"email-error-4-5-1","4.5.1","X.5.1","4-5-1","https://blazalek.com/en/email-errors/4-5-1","delivery-protocol","temporary_failure","retry","check_context","[""sender_admin"",""provider""]","4.5.1 — Temporarily invalid protocol command","A mail system rejected a protocol command because it was issued out of sequence or was unsupported. The leading digit 4 classifies this concrete result as temporary, so delivery may be retried in a controlled way after the command context is checked.","A protocol command was rejected as out of sequence or unsupported: classified temporary in this response. Inspect the SMTP transaction, then retry in a controlled way. Fixing the command order protects deliverability; reputation harm is unlikely if corrected.","A mail transaction protocol command that arrived out of sequence, or that the receiving system does not support, falls under status-code list pattern X.5.1 as code 4.5.1. Class 4 makes this concrete reply a transient failure in the enhanced status register, even though status-code list wording often documents the detail as a permanent error. What the code establishes is a command-order or support mismatch in the current session; it does not show which command failed, whether client or server state is wrong, or that the same sequence will succeed without correction.","Out-of-sequence or unsupported mail transaction protocol commands are what X.5.1 covers. The status-code list description says this detail is useful only as a permanent error, yet the accepted concrete 4.5.1 variant carries class 4; under the class-alignment rule, its result remains transient.","The leading digit 4 denotes a persistent transient failure: the current attempt failed, but the result is not a permanent rejection. The tension between class 4 and the status-code list note about using this detail as a permanent error makes the full response and context important; the code alone does not show that the same command and session state will succeed without correction.","Operational recommendation: before another attempt, check suppression state and confirm command ordering and support. Then retry delivery through a controlled mechanism with backoff, jitter, idempotency, and a time or attempt limit; after repeated 4.5.1 results, stop and refer the case for diagnosis instead of recreating the same context indefinitely.","Operational recommendation: do not add the address to a suppression list based on temporary code 4.5.1 alone. Inspect the full response, command, transaction state, bounded-attempt history, and other delivery events; suppress only after an independent permanent signal or when the applicable policy requires it.","[""A mail transaction protocol command was issued out of sequence for the current transaction state."",""The system that returned the code did not support the issued protocol command.""]","[""Correlate the response with the intended message, attempt time, system that returned the code, and exact command; retain the transaction trace before the command and the response after it."",""Use the retained trace and logs to determine whether the command was out of sequence or unsupported; do not choose between those causes from the code alone."",""Check suppression before retrying, then compare the results of bounded attempts; stop after success, a permanent result, or the configured limit is reached.""]","{""sender_admin"":[""Check suppression and route the message through a bounded retry mechanism with backoff and idempotency. If 4.5.1 repeats in the same context, stop after the configured limit and give the collected trace to the provider.""],""provider"":[""For the specified time and system, inspect logs and the available protocol trace to determine whether the command was out of sequence or unsupported; do not assign either cause from 4.5.1 alone."",""Clear any confirmed temporary problem in the managed implementation or transaction state and preserve a reply class that matches the actual result; give the sender administrator the exact context needed for correction when the problem is on the client side.""]}","[""5.5.1"",""4.5.0"",""4.5.3"",""4.5.4""]","esc-4-5-1","transient","infrastructure","unverified","retry_after_correction","no_recommendation","medium","false"28"email-error-4-5-3","4.5.3","X.5.3","4-5-3","https://blazalek.com/en/email-errors/4-5-3","delivery-protocol","temporary_failure","retry","check_context","[""sender_admin"",""provider""]","4.5.3 — Too many recipients","One message specified more recipients than the protocol could handle in that attempt. The code belongs to the temporary class; normally, the remaining recipients should be separated and delivery to them retried in a controlled way.","Too many recipients were specified for one message in this attempt: a temporary protocol limit. Split remaining recipients and retry in a controlled way. Not a bounce for valid addresses; list hygiene should follow actual permanent failures, not this code alone.","More recipients than the protocol can accept in a single delivery attempt is the trigger for code 4.5.3 under pattern X.5.3. Class 4 keeps the outcome transient; the standard normally expects the remainder to go out on a later attempt, though the pattern also covers cases where splitting is impossible. The detail marks a per-attempt recipient ceiling, not bad addresses. It does not state how many recipients were already accepted, what the limit is, or which RCPT TO commands succeeded before the refusal.","When more recipients were specified for the message than the protocol could deliver, the X.5.3 pattern applies. The standard says this should normally result in splitting the message into two and delivering the remainder of the recipients on a subsequent attempt; the code is also included for cases where such segmentation is not possible. In the concrete 4.5.3 code, the leading digit assigns the result to the transient class.","The leading digit 4 denotes a persistent transient failure: the current attempt failed, but the remaining part of the delivery may be retried. The code alone neither means that any recipient address is invalid nor identifies the limit or which recipients were already accepted; that requires the full transaction context.","Operational recommendation: use the full transaction trace to identify the remaining, unprocessed recipients, split them into smaller batches, and retry only that remainder with backoff, jitter, idempotency, and a time or attempt limit. Check suppression state before every attempt; stop after success, a permanent result, or exhaustion of the limit, and do not indiscriminately resend to the entire original list.","Operational recommendation: do not add addresses to a suppression list based on temporary code 4.5.3 alone. Inspect the per-recipient outcome, full response, bounded-retry history, and other delivery events; suppress only after an independent permanent signal or when the applicable policy requires it.","[""The message specified more recipients than the protocol in use could handle in one delivery attempt.""]","[""Correlate the response with the intended message, attempt time, and sequence of recipient commands; use logs to identify the original list, already accepted recipients, and recipients still to be processed rather than inferring that split from the code alone."",""Split the remaining recipients into smaller batches, make a bounded attempt, and compare the outcomes; stop retrying after success, a permanent rejection, or exhaustion of the configured limit.""]","{""sender_admin"":[""Retain the complete response, time, remote system, and outcomes of individual recipient commands; check suppression, separate the remaining recipients, and route only them through a bounded retry mechanism with backoff and idempotency."",""Group repeated 4.5.3 results by remote system and time; after the limit is exhausted, stop retrying and give the provider the collected transaction trace and batch size without suppressing addresses based on this code alone.""],""provider"":[""Confirm the supported batch size and preserve the exact 4xx reply, enhanced code, and per-recipient outcome so that the sender can safely continue delivery to the remainder of the list.""]}","[""4.5.0"",""4.5.1"",""4.5.4"",""2.5.0""]","esc-4-5-3","transient","rate_limited","unverified","retry_after_correction","no_recommendation","medium","true"29"email-error-4-5-4","4.5.4","X.5.4","4-5-4","https://blazalek.com/en/email-errors/4-5-4","delivery-protocol","temporary_failure","retry","check_context","[""sender_admin"",""provider""]","4.5.4 — Temporarily invalid command arguments","A mail system recognized the command but rejected its arguments as invalid. The leading digit 4 classifies this concrete result as temporary, so delivery may be retried in a controlled way after the arguments are checked and, when necessary, corrected.","The mail system rejected command arguments as invalid: temporary in this response. Correct the arguments, then retry in a controlled way. Transient protocol issue; deliverability and reputation are usually unaffected once arguments are fixed.","Arguments that are out of range or that name an unrecognized feature, on an otherwise recognized mail transaction command, yield code 4.5.4 from status-code list pattern X.5.4. Class 4 keeps this concrete reply transient, even though the status-code list note typically associates the detail with permanent errors. The contrast with 4.5.1 is that the command itself was valid; only the parameters failed validation. The code does not identify which argument failed, whether the fault is sender-side formatting or server capability limits, or that unchanged arguments will succeed on retry.","Invalid arguments on an otherwise valid mail transaction protocol command define X.5.4: the arguments were out of range or represented unrecognized features. The status-code list description says this detail is useful only as a permanent error, but the accepted concrete 4.5.4 variant has class 4; under the class-alignment rule, its result remains transient.","The leading digit 4 denotes a persistent transient failure: the current attempt failed, but the result is not a permanent rejection. The tension between class 4 and the status-code list note about using this detail as a permanent error makes the full response and command context important; the code alone does not show that retrying the same arguments unchanged will succeed.","Operational recommendation: before another attempt, check suppression state and inspect the exact command, its arguments, and transaction state; first correct any confirmed range or feature-compatibility defect. Then retry delivery through a controlled mechanism with backoff, jitter, idempotency, and a time or attempt limit. If 4.5.4 repeats in the same context, stop retrying and refer the case for diagnosis.","Operational recommendation: do not add the address to a suppression list based on temporary code 4.5.4 alone. Inspect the full response, command and arguments, bounded-attempt history, and other delivery events; suppress only after an independent permanent signal or when the applicable policy requires it.","[""An argument to a valid mail transaction protocol command was outside the range accepted by the system that returned the code."",""An argument to a valid command represented a feature that the system returning the code did not recognize.""]","[""Correlate the response with the intended message, attempt time, system that returned the code, and exact command; retain the arguments, transaction state before the command, and response after it."",""Use the retained trace and logs to determine whether an argument was out of range or represented an unrecognized feature; do not choose between these causes from the code alone."",""Check suppression before retrying, correct the confirmed argument problem, and compare the results of bounded attempts; stop after success, a permanent result, or the configured limit is reached.""]","{""sender_admin"":[""Check suppression and route the message through a bounded retry mechanism with backoff and idempotency. If 4.5.4 repeats in the same context, stop after the configured limit and give the collected trace to the provider.""],""provider"":[""For the specified time and system, inspect logs and the available protocol trace to determine which argument was out of range or which feature was treated as unrecognized; do not assign either cause from 4.5.4 alone."",""Clear any confirmed temporary problem in the managed implementation or give the sender administrator the supported range or feature needed for correction; preserve a reply class that matches the actual result.""]}","[""5.5.4"",""4.5.0"",""4.5.1"",""4.5.3""]","esc-4-5-4","transient","infrastructure","unverified","retry_after_correction","no_recommendation","medium","false"30"email-error-4-7-0","4.7.0","X.7.0","4-7-0","https://blazalek.com/en/email-errors/4-7-0","security-authentication-policy","temporary_failure","retry","check_context","[""sender"",""sender_admin"",""recipient_admin"",""provider""]","4.7.0 — Other or undefined temporary security status","The message was returned because of a security-related problem, but the response does not describe it more precisely. The leading digit 4 denotes a temporary failure, so delivery may be retried in a controlled way.","The message was returned for an unspecified security-related reason: a temporary failure. Investigate auth/policy context, then retry in a controlled way. Unresolved repeats can signal reputation risk; do not treat as a hard bounce without a permanent code.","As the transient form of X.7.0, code 4.7.0 is returned when a message comes back for a security-related condition that no finer X.7 detail can express, or when policy forbids a more precise disclosure. Class 4 marks a persistent transient failure: the attempt failed now, yet the underlying condition may clear. This catch-all names the security domain without specifying mechanism, rule, responsible party, or whether the recipient address is invalid. Operators still need the full response text, transaction stage, and logs; the code alone cannot distinguish auth failure, policy block, or intentional vagueness.","A security-related condition that cannot be properly expressed by another available detail code is what returns a message under X.7.0. The code may also be used when an applicable security policy prevents the condition from being described more precisely. In the concrete 4.7.0 code, the leading digit assigns the result to the transient class.","The leading digit 4 denotes a persistent transient failure: the current attempt failed, but the condition may clear. The code alone identifies neither a particular security mechanism, policy rule, responsible party, nor the condition's duration, and it does not establish that the recipient address is invalid.","Operational recommendation: check suppression state before every attempt, then retry with backoff, jitter, idempotency, and a time or attempt limit. Stop after success, a permanent result, a suppression-state change that makes the recipient ineligible, or exhaustion of the limit; refer repeated 4.7.0 results for diagnosis instead of retrying indefinitely.","Operational recommendation: do not add the address to a suppression list based on temporary code 4.7.0 alone. Inspect the full response, security context available for the attempt, bounded-retry history, and other delivery events; suppress only after an independent permanent signal or when the applicable policy requires it.","[""A temporary security-related condition caused the message to be returned, but the reporting system could not describe it with a more specific available code."",""An applicable security policy may have prevented the system from disclosing a more precise description of the condition.""]","[""Correlate the response with the intended message, attempt time, transaction stage, and system that returned the code; retain the full response text and available security context because the code itself is general."",""Inspect available logs to determine whether the system recorded a more specific X.7.x condition or intentionally limited detail under its security policy; do not assign a specific cause from 4.7.0 alone."",""Check suppression before the next attempt, compare bounded-retry outcomes, and stop after success, a permanent result, a recipient-eligibility change, or exhaustion of the configured limit.""]","{""sender"":[""Confirm that the send was intended and that the recipient should still receive the message; give the sender administrator the attempt time and available context without repeatedly retrying it manually."",""Do not change credentials or security settings based on the code alone; follow only a confirmed administrator instruction and report the outcome of the new, controlled attempt.""],""sender_admin"":[""Group repeated 4.7.0 results by remote system and time; after the limit is exhausted, stop retrying and give the collected context to the recipient administrator or provider without suppressing based on this code alone.""],""recipient_admin"":[""If the code came from a recipient system you manage, inspect its security and policy logs for the specified time and attempt to identify a more precise condition when policy permits disclosure."",""Clear the confirmed temporary condition within your control and confirm the result of a new, controlled attempt; when safe, preserve a more specific status code in the response.""],""provider"":[""If you operate a system involved in the attempt, inspect managed-service logs and the security rules applied at the specified time; do not assign a particular cause from the code alone."",""Clear the confirmed temporary condition in the managed layer and, when policy permits, return a more specific X.7.x code instead of general 4.7.0.""]}","[""2.7.0"",""5.7.0"",""4.7.1"",""4.7.12""]","esc-4-7-0","transient","policy_block","unverified","retry_with_backoff","no_recommendation","low","false"31"email-error-4-7-1","4.7.1","X.7.1","4-7-1","https://blazalek.com/en/email-errors/4-7-1","security-authentication-policy","temporary_failure","retry","check_context","[""sender"",""sender_admin"",""recipient_admin"",""provider""]","4.7.1 — Delivery not authorized, message temporarily refused","The system refused the current attempt because the sender was not authorized to send to the destination. The decision may result from per-host or per-recipient filtering. The leading digit 4 denotes a temporary failure, so delivery may be retried in a controlled way.","The sender was not authorized to deliver to this destination: a temporary filtering or policy block. Fix authorization or alignment, then retry in a controlled way. Repeated blocks can hurt sender reputation; not a hard bounce for the recipient address itself.","Whenever class 4 applies, pattern X.7.1 surfaces as 4.7.1: the responding host judged the submission unauthorized for the target destination and deferred the message. Filtering at host or recipient scope can produce that outcome. Class 4 makes the authorization failure transient, even though SMTP specification treats the detail as permanent-only and enhanced status-code now maps X.7.1 onto both 4xx and 5xx basic replies. The status signals a policy or filtering refusal, not an invalid mailbox. It does not name the rule, the enforcing system, block duration, or whether alignment or credentials need correction.","Unauthorized sending to the destination, with the message refused, is the meaning of X.7.1; per-host or per-recipient filtering may produce this result. The SMTP specification description calls this detail useful only as a permanent error, but the current enhanced status-code status-code list associates X.7.1 with basic replies in both the 4xx and 5xx classes. In the concrete 4.7.1 code, the leading digit assigns the result to the transient class.","The leading digit 4 denotes a persistent transient failure: the current attempt failed, but the condition may clear. The code identifies an authorization or filtering outcome, but by itself it does not identify the specific rule, the system that applied it, or the condition's duration, and it does not establish that the recipient address is invalid.","Operational recommendation: check suppression state before every attempt, then retry with backoff, jitter, idempotency, and a time or attempt limit. Stop after success, a permanent result, a suppression-state change that makes the recipient ineligible, or exhaustion of the limit; refer repeated 4.7.1 results for diagnosis instead of retrying indefinitely.","Operational recommendation: do not add the address to a suppression list based on temporary code 4.7.1 alone. Inspect the full response, authorization and filtering context available for the attempt, bounded-retry history, and other delivery events; suppress only after an independent permanent signal or when the applicable policy requires it.","[""During the current attempt, the reporting system determined that the sender was not authorized to send the message to the destination."",""Per-host or per-recipient filtering may have returned the refusal decision.""]","[""Correlate the response with the intended message, attempt time, transaction stage, sender host and identity used, destination, and system that returned the code."",""Inspect available authorization and filtering logs to determine whether the decision was applied per host or per recipient and identify the specific rule; do not infer its contents or owner from code 4.7.1 alone."",""Check suppression before the next attempt, compare bounded-retry outcomes, and stop after success, a permanent result, a recipient-eligibility change, or exhaustion of the configured limit.""]","{""sender"":[""Confirm that the send was intended and that the sender and destination are correct; give the sender administrator the attempt time and complete response without repeatedly retrying it manually."",""Correct only a confirmed error in the sender, destination, or required sending path, then report the outcome of a new, controlled attempt.""],""sender_admin"":[""Group repeated 4.7.1 results by destination system, host or recipient, and time; confirm the sending configuration, and after the limit is exhausted give the collected context to the recipient administrator or provider without suppressing the address based on this code alone.""],""recipient_admin"":[""If the code came from a recipient system you manage, inspect authorization decisions and host- or recipient-level filters for the specified attempt to identify the rule that refused delivery."",""If the confirmed condition is temporary or the rule does not match the intended policy, clear the problem within your control and confirm the result of a new, controlled attempt.""],""provider"":[""If you operate a system involved in the attempt, inspect managed-service logs and the rules applied at the specified time; determine whether the decision was per host or per recipient without assigning a particular cause from the code alone."",""Clear the confirmed temporary condition in the managed layer and preserve the exact 4xx class, code 4.7.1, and safe context needed by the sender to control retries.""]}","[""5.7.1"",""4.7.0"",""4.7.12"",""4.7.15""]","esc-4-7-1","transient","policy_block","unverified","retry_after_correction","no_recommendation","medium","true"32"email-error-4-7-12","4.7.12","X.7.12","4-7-12","https://blazalek.com/en/email-errors/4-7-12","security-authentication-policy","temporary_failure","retry","check_context","[""sender"",""sender_admin"",""recipient_admin"",""provider""]","4.7.12 — Authentication mechanism transition required","The server replied to the AUTH command that the user must first transition to the selected authentication mechanism. The leading digit 4 denotes a temporary failure, so a controlled attempt may be made after the required transition is completed safely.","SMTP AUTH failed because the account must first switch to a required authentication mechanism. Fix auth configuration before resubmitting mail; this is an operational gate, not a recipient deliverability signal. Temporary failure: retry with backoff only after the approved mechanism transition.","During SMTP session setup, code 4.7.12 answers the AUTH command under status-code list pattern X.7.12. The detail requires the authenticating user to transition to a server-selected mechanism before that mechanism may be used in later sessions. Class 4 in the enhanced status register marks a transient outcome: the present AUTH exchange failed, yet the condition may clear once the required transition completes. The code alone does not establish wrong credentials, an invalid mailbox, or a permanent refusal of the message itself, and it does not define the approved transition steps for a given host.","As a response to the AUTH command, X.7.12 means the user needs to transition to the selected authentication mechanism. The standards description says this is typically done by authenticating once with the PLAIN mechanism; the selected mechanism should then work for authentications in subsequent sessions. In the concrete 4.7.12 code, the leading digit assigns the result to the temporary class.","The leading digit 4 denotes a persistent transient failure: the current SMTP authentication attempt failed, but the condition may clear after the required transition. The code alone establishes neither an incorrect password, an invalid recipient address, nor a permanent message refusal, and it does not specify the safe transition procedure for a particular system.","Operational recommendation: do not repeat the same AUTH command unchanged. Retain the full response, check suppression before the next send, establish the approved mechanism-transition procedure, and only after completing it safely retry with backoff, jitter, idempotency, and a time or attempt limit. Stop after success, a permanent result, a suppression-state change that makes the recipient ineligible, or exhaustion of the limit.","Operational recommendation: do not add the recipient address to a suppression list based on temporary code 4.7.12 alone, because the described condition concerns a user's authentication to a server. Inspect the full response, the affected account or service scope, bounded-attempt history, and other delivery events; suppress only after an independent permanent signal or when the applicable policy requires it.","[""The authentication server requires the user to transition to the selected authentication mechanism before it can be used in subsequent sessions."",""The required transitional authentication — typically a one-time authentication with the PLAIN mechanism according to the standards description — has not yet been completed.""]","[""Correlate the response with the attempt time, authenticating account, client, server endpoint, and selected mechanism; retain the full response text without treating the code's title alone as context of an incorrect password."",""Use available server or provider logs and policy to confirm whether the account actually requires a mechanism transition and which procedure is approved for that system; do not reconstruct it from memory or from the code alone."",""Check suppression before a new attempt, perform only the confirmed transition without exposing credentials, and compare the bounded attempt's result; stop after success, a permanent result, or exhaustion of the limit.""]","{""sender"":[""Confirm that the send was intended and give the sender administrator the attempt time, account used, and full response without repeatedly retrying it manually."",""Follow only confirmed instructions to reauthenticate or change configuration; do not disclose credentials, and report the outcome of the new, controlled attempt.""],""sender_admin"":[""Establish the required, approved transition procedure with the server administrator or provider; after completing it safely, test the selected mechanism in one controlled attempt and stop on a permanent result or after exhausting the limit.""],""recipient_admin"":[""If you manage the server that returned the code, inspect its AUTH policy, transition state for the specified account, and logs for the attempt time, then confirm the correct mechanism and permitted transition procedure."",""Clear the confirmed temporary state within your control, then confirm that the selected mechanism works in a subsequent session after the required transition and that the server returns a precise result.""],""provider"":[""If you operate an authentication service involved in the attempt, inspect its logs and policy for the specified account, time, and mechanism, then provide approved transition steps without requesting disclosure of credentials."",""Clear the confirmed temporary state in the managed layer and confirm the next controlled attempt; if the problem remains, return precise diagnostic context consistent with the security policy.""]}","[""4.7.0"",""4.7.1"",""4.7.15"",""4.7.16""]","esc-4-7-12","transient","authentication_failure","unverified","retry_after_correction","no_recommendation","high","false"33"email-error-4-7-15","4.7.15","X.7.15","4-7-15","https://blazalek.com/en/email-errors/4-7-15","security-authentication-policy","temporary_failure","retry","check_context","[""sender"",""sender_admin"",""recipient_admin"",""provider""]","4.7.15 — Priority level is too low","The receiving SMTP server did not accept the message because the specified priority level was below the lowest level the server currently accepts. The leading digit 4 denotes a temporary failure, so a controlled retry is appropriate.","The receiving server refused the message because its declared priority was below the minimum it currently accepts. Important for bulk or low-priority traffic scheduling, not list hygiene. Temporary: retry later or adjust priority if your path supports it; no lasting reputation hit if retries stay bounded.","Priority attached to a message can fall below the lowest level the receiving SMTP server will accept at that moment; pattern X.7.15 under code 4.7.15 records that refusal. The .7 subcode situates it in the security, authentication, and policy family, not in addressing or routing syntax. Class 4 marks a transient result, so the threshold or server mode that produced the reply may shift later. The enhanced code does not by itself show which priority was sent, how long the restriction lasts, or whether the sender assigned an incorrect value.","The specified priority level sits below the lowest priority acceptable to the receiving SMTP server: that is pattern X.7.15. The standard names, as one possible temporary condition, a mode that accepts only higher-priority messages for transfer and delivery while rejecting lower-priority ones. For the concrete 4.7.15 reply, the leading digit places the outcome in the temporary class.","Code 4.7.15 describes a temporary failure of the current attempt; the condition may clear when the server's accepted threshold or operating mode changes. The code alone does not explain why the threshold applies, how long it will last, or whether the level specified by the sender is incorrect.","Operational recommendation: check suppression before every attempt, retain the full response and priority level used, then retry with backoff, jitter, idempotency, and a time or attempt limit. Do not raise priority merely to bypass the threshold without confirming the message's applicable policy. Stop after success, a permanent result, a suppression-state change that makes the recipient ineligible, or exhaustion of the limit.","Operational recommendation: do not add the recipient address to a suppression list based on temporary code 4.7.15 alone, because the described condition concerns the priority level accepted by the server. Inspect the full response, priority used, bounded-retry outcomes, and other delivery events; suppress only after an independent permanent signal or when the applicable policy requires it.","[""The priority level specified for the message was below the lowest level accepted by the receiving SMTP server."",""The receiving server may have been operating temporarily in a mode that accepts only higher-priority messages while rejecting lower-priority messages.""]","[""Correlate the response with the intended message, attempt time and stage, receiving endpoint, and priority level specified for that message."",""Use available sender, recipient, or provider configuration and logs to compare the level used with the accepted threshold and determine whether the server was in a temporary mode that restricted lower priorities; do not infer those details from the code alone."",""Check suppression before the next attempt, make a bounded retry without an unconfirmed priority increase, and compare the outcome; stop after success, a permanent result, or exhaustion of the limit.""]","{""sender"":[""Confirm the message's intended priority and give the sender administrator the attempt time and complete response without repeatedly retrying it manually."",""Change the priority only when the confirmed message policy justifies another value, then report the outcome of one controlled attempt.""],""sender_admin"":[""confirm that the sending system specified the intended priority, and coordinate with the recipient administrator or provider to confirm the accepted threshold without raising the value on your own.""],""recipient_admin"":[""If you manage the server that returned the code, inspect the configured threshold, operating mode, and priority-decision logs for the specified attempt."",""Clear the confirmed temporary condition within your control or provide safe context about the required threshold, then confirm the result of a controlled attempt.""],""provider"":[""If you operate a service involved in the attempt, inspect managed logs for the specified time, message, and endpoint, then confirm the level used, active threshold, and server-mode state."",""Clear the confirmed temporary condition in the managed layer or identify the permitted configuration while preserving the exact 4xx class, code 4.7.15, and safe diagnostic context in the response.""]}","[""5.7.15"",""4.7.0"",""4.7.1"",""4.7.12""]","esc-4-7-15","transient","policy_block","unverified","retry_with_backoff","no_recommendation","high","false"34"email-error-4-7-16","4.7.16","X.7.16","4-7-16","https://blazalek.com/en/email-errors/4-7-16","security-authentication-policy","temporary_failure","retry","check_context","[""sender"",""sender_admin"",""recipient_admin"",""provider""]","4.7.16 — Message too big for the specified priority","The server temporarily rejected the message because it is too big for the specified priority. A controlled retry may be made after the condition clears.","The server temporarily rejected the message because it exceeds the size allowed for its priority level. Size and priority settings matter for throughput, not recipient list quality. Temporary failure: retry after the condition clears or with a smaller message or higher priority where supported.","An arriving message that exceeds the size limit the receiving server applies for the specified priority level produces code 4.7.16 from status-code list pattern X.7.16. The refusal sits under the .7 security and policy subcode, tying message size to priority policy rather than to generic oversize handling alone. Class 4 marks the outcome as transient, matching modes in which a host temporarily accepts only higher-priority traffic below a defined size ceiling. The code does not state the measured size, the active limit, the priority value used, or how long the restrictive mode will remain in effect.","Message size beyond what the specified priority allows is the X.7.16 condition. The standard notes it may be temporary, for example when the server runs in a mode that accepts only higher-priority messages below a defined size limit. In code 4.7.16, the leading digit assigns the result to the temporary class.","The leading digit 4 denotes a temporary failure: the current attempt failed, but the condition may clear. The code alone gives neither the message size, the applied limit, the priority value, nor the duration of the server mode.","Operational recommendation: check suppression before every attempt, then retry with backoff, jitter, idempotency, and a time or attempt limit. Stop after success, a permanent result, a recipient-eligibility change, or exhaustion of the limit; refer repeated 4.7.16 results for diagnosis.","Operational recommendation: do not add the recipient address to a suppression list based on temporary code 4.7.16 alone. Inspect the full response, bounded-retry history, and other delivery events; suppress only after an independent permanent signal or when the applicable policy requires it.","[""The message size exceeds the limit applied by the server to the specified priority."",""The server is temporarily operating in a mode that accepts only higher-priority messages below a defined size limit.""]","[""Correlate the response with the intended message, attempt time and stage, server that returned the code, message size, and specified priority."",""Use available server logs and policy to check the size limit for that priority and any temporary operating mode; do not infer their values from the code alone."",""Check suppression before the next attempt and compare the bounded retry result; stop after success, a permanent result, or exhaustion of the limit.""]","{""sender"":[""Confirm that the message, its attachments, and the specified priority are intended, and give the sender administrator the full response without repeatedly retrying it manually."",""Reduce the message or change its priority only when justified by the content and confirmed by an administrator; report the result of the controlled attempt.""],""sender_admin"":[""Retain the full response, message size, priority, time, and server that returned the code, check suppression, and route the send through a bounded retry mechanism."",""If the code repeats, compare results by server, size, and priority, then establish the applicable limits with the recipient administrator or provider.""],""recipient_admin"":[""If you manage the server that returned the code, inspect its logs, active operating mode, and size limits for the specified priority at the attempt time."",""Clear the confirmed temporary condition within your control, or give the sender a safe, precise description of the applicable constraints, and confirm the next attempt.""],""provider"":[""If you operate a system involved in the attempt, inspect managed-service logs and the size and priority limits applied at the specified time."",""Clear the confirmed temporary condition in the managed layer, or give the appropriate administrators the precise context needed to resolve it.""]}","[""5.7.16"",""4.7.0"",""4.7.1"",""4.7.12""]","esc-4-7-16","transient","policy_block","unverified","retry_after_correction","no_recommendation","medium","true"35"email-error-4-7-24","4.7.24","X.7.24","4-7-24","https://blazalek.com/en/email-errors/4-7-24","security-authentication-policy","temporary_failure","retry","check_context","[""sender"",""sender_admin"",""recipient_admin"",""provider""]","4.7.24 — SPF validation error","An error occurred while SPF was evaluated for the arriving message, so the current attempt ended in a temporary failure. A controlled retry is appropriate, not unlimited retries.","SPF evaluation failed with an error during inbound authentication checks, so delivery paused temporarily. Repeated SPF failures can hurt sender reputation if misconfigured. Temporary: retry with bounded backoff after fixing DNS/SPF or clearing the transient lookup issue; do not retry unchanged indefinitely.","SPF evaluation of an arriving message ended in an error rather than pass, fail, or neutral, and code 4.7.24 reports that outcome under status-code list pattern X.7.24. SMTP specification assigns this enhanced status to the error cases described in its evaluation sections, separate from generic DNS or syntax failures reported under other codes. Class 4 classifies the SMTP-layer outcome as transient even when the underlying DNS or lookup fault may still need sender-side correction. The status detail alone does not identify which lookup step failed, whether the SPF record is missing or malformed, or whether the recipient address is invalid.","Under X.7.24, relative SPF evaluation for an arriving message produced an error. The standard supplies this code in place of 4.4.3 or 5.5.2 for the cases described in Sections 8.6 and 8.7 of SMTP specification. In the concrete 4.7.24 form, the leading digit assigns the result to the temporary class.","The leading digit 4 denotes a persistent transient failure: the current attempt failed, but the condition may clear. The code alone identifies neither the cause of the SPF evaluation error, its duration, nor a permanent problem with the recipient address.","Operational recommendation: check suppression before every attempt, retain the full response, and retry with backoff, jitter, idempotency, and a time or attempt limit. Stop after success, a permanent result, a suppression-state change that makes the recipient ineligible, or exhaustion of the limit; refer repeated 4.7.24 results for diagnosis.","Operational recommendation: do not add the recipient address to a suppression list based on temporary code 4.7.24 alone, because it describes an SPF evaluation error rather than proving that the recipient address is invalid. Inspect the full response, event scope, bounded-retry outcomes, and other delivery signals; suppress only after an independent permanent signal or when the applicable policy requires it.","[""SPF evaluation for the arriving message resulted in an error; the code alone does not identify the technical condition that caused it.""]","[""Correlate the result with the intended message, attempt time and stage, sender identity, and server that returned the code."",""Use available logs from the SPF-evaluating system and supporting services to establish the actual error; do not infer its cause from the code alone."",""Check suppression before the next attempt and compare the bounded retry result; stop after success, a permanent result, or exhaustion of the limit.""]","{""sender"":[""Confirm that the message and sender identity used are intended, then give the sender administrator the full response and attempt time without repeatedly retrying it manually."",""Do not change SPF configuration based on the code alone; perform only confirmed corrective actions and report the controlled attempt's outcome.""],""sender_admin"":[""Retain the full response, correlate it with the message, sender identity, and receiving endpoint, check suppression, and route the send through a bounded retry mechanism."",""Inspect available sender-side configuration and logs, then establish the confirmed cause with the recipient administrator or provider before making a change.""],""recipient_admin"":[""If you manage the server that returned the code, inspect its SPF-evaluation and supporting-service logs for the specified time, message, and sender identity."",""Clear the confirmed temporary condition within your control, then confirm one controlled attempt and return a precise code.""],""provider"":[""If you operate a service involved in SPF evaluation, inspect managed logs and service state for the specified time and event scope."",""Clear the confirmed temporary condition in the managed layer, or give the appropriate administrators safe, precise diagnostic context.""]}","[""5.7.24"",""4.7.0"",""4.7.1"",""4.7.12""]","esc-4-7-24","transient","authentication_failure","unverified","retry_with_backoff","no_recommendation","medium","true"36"email-error-4-7-26","4.7.26","X.7.26","4-7-26","https://blazalek.com/en/email-errors/4-7-26","security-authentication-policy","temporary_failure","retry","check_context","[""sender"",""sender_admin"",""provider""]","4.7.26 — Mail rate-limited for missing SPF/DKIM authentication (Gmail)","The receiving system reports that mail from this sender is being rate-limited because it arrived without a passing SPF or DKIM authentication result. The code belongs to the temporary class: once the sender's authentication is corrected, delivery may be retried in a controlled way.","Gmail is temporarily rate-limiting your mail because it arrived unauthenticated: neither SPF nor DKIM passed. This is transient, not permanent, but retrying without fixing authentication will keep triggering the same limit. Set up SPF and/or DKIM correctly, confirm alignment, then retry with backoff; do not suppress recipient addresses based on this code alone, since the condition is attached to the sender's own authentication, not to any one mailbox.","In this catalog, mechanical enhanced status-code confirmation for X.7.26 applies only to the class-5 variant (5.7.26, Associated Basic Status Code 550); the concrete class-4 form has no such status-code list here. The status reports a transient authentication shortfall on this attempt, not a permanently invalid address and not a mailbox condition.","SMTP specification registers X.7.26 specifically for a multiple-authentication-failure condition: a message failed more than one message-authentication check, contrary to local policy, without naming which mechanisms failed.","In this catalog, mechanical enhanced status-code confirmation for X.7.26 applies only to the class-5 variant (5.7.26, Associated Basic Status Code 550); the concrete class-4 form has no such status-code list here. The status reports a transient authentication shortfall on this attempt, not a permanently invalid address and not a mailbox condition.","Retrying without changing anything will not help: fix SPF and/or DKIM for the sending domain first, confirm the records have propagated and that outgoing mail actually carries a passing signature or SPF result, then retry with backoff and an attempt limit. Stop retrying once messages start passing authentication and delivering, or once the limit is exhausted; do not keep resending the same unauthenticated stream expecting a different result.","Do not suppress or remove the recipient address based on 4.7.26 alone: the condition is attached to the sender's own authentication setup, not to the recipient's mailbox or address validity. Suppression decisions should follow independent, per-recipient signals (hard bounces, permanent codes), not this sender-side authentication gap.","[""The sending domain has no SPF record, or the SPF record does not include the sending infrastructure's IP address, so SPF fails or returns none/softfail instead of pass."",""DKIM is not configured, the signing key does not match the available DNS selector record, or the message was modified in transit (for example by a forwarding step or relay) so the DKIM signature no longer confirm.""]","[""Check the sending domain's available SPF record and DKIM selector against the infrastructure that actually sent the message, including any third-party ESP or relay in the path."",""After correcting the DNS records, send a fresh test message and confirm the Authentication-Results header shows a pass before resuming full-volume sending.""]","{""sender"":[""Confirm with your sending administrator or provider that SPF and DKIM are available and correctly aligned for this domain; do not keep resending the same unauthenticated stream."",""Once authentication is fixed, retry with backoff and monitor the Authentication-Results header on the next attempts before resuming normal volume.""],""sender_admin"":[""confirm DMARC alignment between the From: domain and the SPF/DKIM identifiers, and re-test with a tool or a real send before telling the sender to resume.""],""provider"":[""If you operate the sending infrastructure (ESP, MTA), confirm outgoing mail is actually signed with a valid DKIM key and that the envelope sender falls under a domain covered by SPF for your sending IPs."",""Route customers who lack authentication through onboarding checks before allowing high-volume sends, since Gmail enforces SPF/DKIM under its bulk-sender requirements.""]}","[""5.7.26"",""4.7.28""]","esc-4-7-26","transient","authentication_failure","unverified","retry_after_correction","no_recommendation","high","false"37"email-error-4-7-28","4.7.28","X.7.28","4-7-28","https://blazalek.com/en/email-errors/4-7-28","security-authentication-policy","temporary_failure","retry","check_context","[""sender"",""sender_admin"",""recipient_admin"",""provider""]","4.7.28 — Sender IP temporarily rate-limited for unsolicited mail (Gmail)","The receiving system reports that mail from this sending IP address is being rate-limited because Gmail judged an unusual portion of that traffic to be unsolicited. The code belongs to the temporary class: sending behavior and reputation may improve, so delivery may be retried in a controlled way.","Gmail is temporarily rate-limiting your sending IP because of an unusual rate of mail it judges unsolicited: transient, not permanent. Retry with backoff and a reduced send rate; do not suppress recipient addresses based on this code alone, since the limit is attached to the sending IP, not to any one recipient. Review Gmail's Bulk Email Senders Guidelines and your authentication and list-hygiene practices before returning to full volume.","Nowhere in this catalog's enhanced status-code status-code list mirror is Gmail's own concrete detail code 4.7.28 confirmed for any class under the X.7 (Security or Policy Status) subject; the X.7.28 pattern remains unresolved (null confirmedClasses). Any permanent-class counterpart is banned outright here and is never available or inferred. The status names a temporary, IP-level rate limit at this attempt, not a permanent block or an addressing error.","SMTP specification Section 3.8 defines the general X.7 ""Security or Policy Status"" subject class (X.7.0 through X.7.7) for delivery failures caused by security or policy, not by an addressing or mailbox problem; SMTP specification itself never lists detail code 28. SMTP specification sets out the enhanced status-code status-code list process that lets providers register further detail codes under an existing subject class beyond SMTP specification's base table, and treats the Associated Basic Status Code list for any entry as illustrative rather than exhaustive. In this catalog the status-code list mirror keeps X.7.28 unresolved for every class: it has never gained a confirmed status-code list entry, unlike some other X.7.2x details.","The leading digit 4 denotes a persistent transient failure: at the moment of this attempt, Gmail is rate-limiting the sending IP, but the condition may clear once sending volume, authentication, and list hygiene improve and Gmail's systems reassess the IP's reputation. Do not conflate this with a permanent block; this code does not mean the domain or IP has been blocklisted outright, only that the current rate is being throttled.","Retry with backoff, jitter, and a reduced sending rate; do not keep sending at the volume that triggered the limit. Treat the response code, not a fixed schedule, as the signal to resume normal volume: stop escalating once deliveries succeed at a lower rate, then ramp volume back up gradually. Do not treat a single 4.7.28 as grounds to stop sending to this domain outright — it is a rate signal, not a permanent rejection.","Do not suppress or remove any recipient address based on 4.7.28 alone: the condition is attached to the sending IP's behavior and reputation, not to any single recipient's mailbox or address validity. Suppression decisions should follow independent, per-recipient signals (hard bounces, permanent codes) rather than this shared, IP-level rate limit.","[""The sending IP or domain recently increased volume, changed sending patterns, or began sending to a list with a high proportion of unengaged or invalid addresses, and Gmail's abuse-detection systems classified a portion of that traffic as unsolicited."",""The sender lacks consistent authentication (SPF, DKIM, DMARC alignment) or is sending from a shared or dynamic IP with mixed reputation, both of which make Gmail more likely to apply this rate limit.""]","[""Identify which sending IP or domain triggered the limit and correlate it with recent volume, list-available information, and authentication changes around the time of the attempt."",""Review the sending IP's or domain's standing against Gmail's Bulk Email Senders Guidelines and, where available, Postmaster Tools (spam rate, IP/domain reputation)."",""Reduce the sending rate and retry in a bounded, backed-off way; stop escalating once deliveries succeed, and only then ramp volume back up gradually.""]","{""sender"":[""Do not keep sending at the volume that triggered the limit; pause or throttle sends to this recipient domain and retry with backoff once the rate condition has had time to clear."",""Review your list hygiene and authentication (SPF, DKIM, DMARC) before resuming full volume, and give your sending administrator the attempt time and full response text.""],""sender_admin"":[""Check Postmaster Tools and sending logs for the IP or domain named in the attempt; confirm authentication alignment and reduce or ramp sending volume gradually rather than reverting immediately to the prior rate."",""Group repeated 4.7.28 results by sending IP and time; once the rate condition clears and retries succeed at a lower volume, ramp back up gradually rather than reverting immediately to the prior level.""],""recipient_admin"":[""If your organization manages inbound mail routing or filtering that affects this outcome, confirm no additional local policy is compounding the rate limit before advising the sender."",""Where policy permits, share the exact response text and timing with the sender's administrator so they can correlate it with their own sending logs.""],""provider"":[""If you operate the sending infrastructure (ESP, MTA), monitor for repeated 4.7.28 across the IP pool, apply your own rate control ahead of Gmail's limit, and route senders through IP warm-up before high-volume sends."",""Escalate to Gmail's postmaster support channels only once the rate limit persists well past a reasonable remediation window despite confirmed authentication and volume changes.""]}","[""4.7.0"",""4.7.1""]","esc-4-7-28","transient","reputation_block","unverified","retry_with_backoff","no_recommendation","medium","true"38"email-error-4-7-3","4.7.3","X.7.3","4-7-3","https://blazalek.com/en/email-errors/4-7-3","security-authentication-policy","temporary_failure","retry","check_context","[""sender"",""sender_admin"",""recipient_admin"",""provider""]","4.7.3 — Receiving domain's inbound queue temporarily over its rate quota (Outlook.com)","The receiving system reports that the destination domain's incoming mail queue is currently receiving mail faster than its allotted rate quota and is not accepting messages at this time. The code belongs to the temporary class: the condition is tied to inbound volume, not to this message or this sender, so delivery may be retried once the queue has room again.","Retry with backoff and a reduced pace to this domain; do not suppress the recipient address on a single 4.7.3.","Stamping status-code list pattern X.7.3 with a transient class does not make code 4.7.3 share that pattern's meaning here.","By contrast, SMTP specification Section 3.8 defines X.7.3 for the case in which a message required conversion between secure messaging protocols and that conversion could not be performed; the RFC marks the detail useful only as a permanent error and gives no Associated Basic Status Code. SMTP specification establishes the enhanced status-code registration process for X.7 detail codes and treats the Associated Basic Status Code list as illustrative rather than exhaustive, yet neither that RFC nor this catalog's status-code list mirror grants X.7.3 a confirmed class-4 or class-5 status.","The leading digit 4 denotes a persistent transient failure: at the moment of this attempt, the receiving domain's queue is over its rate allowance, but the condition is expected to clear as inbound volume subsides, independent of anything the sender did wrong.","Retry with backoff, jitter, and a reduced sending rate to this receiving domain; do not keep sending at the pace that triggered the deferral. Stop retrying after success or once an attempt or time limit is reached; a single 4.7.3 is not grounds to treat the address, domain, or your own authentication as broken.","Do not suppress or remove any recipient address based on 4.7.3 alone: the condition is attached to the receiving domain's inbound queue capacity, not to any individual mailbox's validity or engagement. Suppression decisions should follow independent, per-recipient signals (hard bounces, permanent codes) rather than this shared, domain-level rate condition.","[""The receiving domain's Outlook.com-hosted mail infrastructure is currently accepting inbound mail more slowly than the rate at which messages are arriving for it, whether from one large sender, several senders at once, or a backlog working through the queue.""]","[""Reduce the sending rate to the named receiving domain and retry in a bounded, backed-off way; a queue-quota condition tied to inbound volume typically clears once the backlog or burst passes."",""If 4.7.3 recurs repeatedly for one receiving domain across separate sends, treat it as a signal to pace outbound volume to that domain specifically, rather than as a per-recipient or per-message defect.""]","{""sender"":[""Retry with backoff and a reduced pace to this receiving domain; do not treat a single 4.7.3 as an authentication, security, or address-validity problem."",""If the code persists past a reasonable retry window, give your sending administrator the receiving domain, attempt time, and full response text before escalating.""],""sender_admin"":[""Check sending logs and volume to the named receiving domain; throttle or spread sends across a longer window rather than retrying at the same pace that triggered the deferral."",""Group repeated 4.7.3 results by receiving domain and time; once retries at a lower pace succeed, ramp volume back up gradually rather than reverting immediately to the prior rate.""],""recipient_admin"":[""If your organization's inbound mail is routed through this Outlook.com-hosted domain, review inbound volume and any Microsoft-side queue or throughput settings with your mail administrator or Microsoft support."",""Where policy permits, share the exact response text and timing with the sender's administrator so they can correlate it with their own sending logs.""],""provider"":[""If you operate sending infrastructure (ESP, MTA), monitor for repeated 4.7.3 by receiving domain and apply your own outbound pacing ahead of the receiving domain's queue limit."",""Escalate to Microsoft's postmaster or support channels only once the condition persists well past a reasonable window despite confirmed pacing changes on your side.""]}","[""4.7.0"",""4.7.1""]","esc-4-7-3","transient","infrastructure","unverified","retry_after_correction","no_recommendation","medium","true"39"email-error-5-0-0","5.0.0","X.0.0","5-0-0","https://blazalek.com/en/email-errors/5-0-0","other-undefined","permanent_failure","do_not_retry","check_context","[""sender_admin"",""provider""]","Other undefined permanent status","Code 5.0.0 is a general permanent failure: only class 5 is known, with no more specific status. Do not retry the same unchanged attempt.","A permanent delivery failure occurred, but the response only reports generic class 5 with no specific detail. Treat as operationally serious until you identify the underlying cause from logs and context. Do not retry unchanged; deliverability impact depends on root cause: address bad data before resending.","In the enhanced status register, code 5.0.0 is the concrete form of pattern X.0.0, reserved for cases where only the result class is known and no finer enhanced subcode applies. The leading digit 5 marks permanent failure, yet the .0.0 suffix signals that the rejecting host did not supply a more specific subject or detail field. Operators therefore know the attempt will not succeed if repeated unchanged, but must derive the actual reason from the basic SMTP reply text, transaction stage, and surrounding logs. The generic code does not establish a bad recipient address, a policy block, or any particular RFC-level condition.","X.0.0 is the sole undefined status code and applies when nothing finer than the result class is known. In the 5.0.0 variant, that result class is permanent failure.","This is a permanent status, not a temporary error. The code alone does not identify the exact cause or establish that the recipient address is the problem.","Do not retry an unchanged attempt after code 5.0.0. Before any new submission, determine the cause from the full response and change the relevant data, configuration, or handling.","Do not apply automatic blanket suppression based on code 5.0.0 alone. Inspect the full response, context, and other permanent signals, then decide according to the established cause and applicable policy.","[""Only the permanent-failure class is known, so the general 5.0.0 code is used."",""The exact reason remains unspecified; code 5.0.0 itself provides no more specific status.""]","[""Inspect the raw SMTP transaction response or delivery report and confirm that it contains the exact enhanced code 5.0.0."",""Trace response mapping in logs and webhooks to determine whether a more specific status was lost or normalized to 5.0.0.""]","{""sender_admin"":[""Establish the cause before a new submission; base suppression on the full context and policy, not solely on code 5.0.0.""],""provider"":[""Review normalization rules when available permanent-failure detail is replaced by the general 5.0.0 code.""]}","[""2.0.0"",""4.0.0""]","esc-5-0-0","permanent","unknown","unverified","do_not_retry","no_recommendation","low","true"40"email-error-5-1-0","5.1.0","X.1.0","5-1-0","https://blazalek.com/en/email-errors/5-1-0","addressing","permanent_failure","do_not_retry","check_context","[""sender"",""sender_admin""]","5.1.0 — Generic address-status rejection, for both sender and recipient addresses","5.1.0 — Generic address-status rejection, for both sender and recipient addresses","5.1.0 — Generic address-status rejection, for both sender and recipient addresses","enhanced status-code's generic catch-all detail in the addressing subject family is status-code list pattern X.1.0 (""Other address status""), for cases where no more specific address-status code applies; code 5.1.0 assigns it a permanent class. Mechanical enhanced status-code confirmation for X.1.0 in this catalog covers no class at all: the status-code list's Associated Basic Status Code reads ""Not given,"" and the catalog's canonical mirror records the pattern's resolution status as unresolved.","Neither class 4 nor class 5 is mechanically confirmed by enhanced status-code for this pattern.","This differs from a hypothetical class-4 use of the same X.1.0 detail, which would describe a condition expected to clear on its own; no such class-4 concrete code is available in this catalog on the context available.","5.1.0 — Generic address-status rejection, for both sender and recipient addresses","Do not suppress the recipient address based on 5.1.0 alone without first reading the full response text: the code covers two different situations in this catalog's context, and only one of them (a rejected recipient address) is actually about that address. When the text names a sender-identity or authentication problem, route the signal to the sending domain's authentication owner instead of the list-hygiene process; suppress the recipient address only when the exact text names that address as the one rejected.","[""The sending system's HELO/EHLO identity or authenticated account does not match the domain in the envelope sender, so the receiving system treats the sender address itself as invalid for this connection."",""Because X.1.0 is enhanced status-code's undefined catch-all for the addressing subject, individual providers attach it to whichever address-related condition does not fit a more specific detail code in their own implementation — the exact response text, not the enhanced code, identifies the actual cause.""]","[""Read the full response text before assuming a cause: if it names the sender, envelope-from, Return-Path, or an authentication mechanism (SPF/DKIM/alignment), treat this as a sender-side rejection; if it names the recipient address or appears in direct reply to RCPT TO with no sender-side language, treat it as a recipient-side rejection."",""For a sender-side 5.1.0, check the sending domain's SPF record for the sending IP and confirm Return-Path/From: alignment; check whether the HELO/EHLO or authenticated submission identity matches the envelope sender domain.""]","{""sender"":[""Stop retrying the identical message: read the exact response text first to learn whether the sender identity or the recipient address is the one being rejected, since 5.1.0 covers both in this catalog's context."",""If the text names the sender, envelope-from, or an authentication mechanism, pause sending from that domain and escalate to sender_admin; if it names the recipient address, confirm that address with the recipient through another channel before resending.""],""sender_admin"":[""For a sender-identity rejection, confirm the sending domain's SPF record authorizes the sending IP and that the Return-Path domain aligns with the From: header domain; correct whichever mechanism the response text points to."",""Confirm the HELO/EHLO identity and any authenticated submission account match the envelope sender domain, since some receiving systems reject 5.1.0 specifically on an identity mismatch rather than a DNS-record problem.""]}","[""5.1.1"",""5.1.2"",""5.1.8""]","esc-5-1-0","permanent","unknown","unverified","retry_after_correction","no_recommendation","low","true"41"email-error-5-1-1","5.1.1","X.1.1","5-1-1","https://blazalek.com/en/email-errors/5-1-1","addressing","permanent_failure","do_not_retry","check_context","[""sender"",""sender_admin""]","5.1.1 — Recipient mailbox does not exist","The specified recipient mailbox does not exist. This is a permanent failure, so do not retry delivery to the same unchanged address.","The recipient mailbox does not exist: a classic hard bounce. Remove or correct the address for list hygiene; repeated sends hurt sender reputation. Permanent failure: do not retry the same unchanged address.","The local-part of the destination address does not correspond to an existing mailbox at the receiving system; that is status-code list pattern X.1.1 as code 5.1.1. In the enhanced status code register, class 5 marks a permanent condition for this detail. The numeric reply names an addressing mismatch, not whether the gap came from a typo, a stale list entry, or an account removed on purpose; that distinction belongs to the full SMTP response and your sender-side records.","Under X.1.1, the mailbox specified in the address does not exist; for an Internet mail address, the part to the left of the ""@"" sign is invalid. The standard states this status is useful only for permanent failures, and code 5.1.1 belongs to permanent class 5.","The leading digit 5 denotes a permanent failure. Repeating the same attempt with an unchanged address is not the appropriate response; a new send is justified only after the address has been reliably corrected.","Do not automatically or manually retry delivery to the same unchanged address. Make a new attempt only when the address has been corrected from a trusted available information; do not guess a missing or different mailbox name.","Do not apply unconditional or blanket suppression based solely on code 5.1.1. Confirm that the permanent rejection applies to this exact address, inspect the full response, and apply the appropriate policy for that recipient; do not suppress the entire domain or other recipients.","[""The part of the address before the “@” sign does not correspond to any mailbox in the recipient system, for example because of a typo."",""The sending system used an outdated or incorrectly recorded recipient mailbox address.""]","[""Compare the full recipient address with a trusted available information value, paying particular attention to the part before the “@” sign; do not try to guess the correct address."",""Trace the address to its available information in sender data and review the attempt history so the permanent rejection is tied to the correct address and further unchanged sends are stopped.""]","{""sender"":[""confirm the address against a trusted available information or through another channel, and change it only when you have a confirmed replacement value."",""Do not resend to the same address; if no confirmed correction is available, route the result for handling under the recipient policy.""],""sender_admin"":[""Stop automatic retries for the unchanged address, retain the full response, and determine which available information supplied the recipient value."",""Decide suppression for this recipient only after evaluating the full context and policy; do not extend it to the domain or other addresses.""]}","[""4.1.1"",""5.1.3"",""5.1.8"",""5.1.10""]","esc-5-1-1","permanent","recipient_invalid","invalid","do_not_retry","suppression_recommended","high","false"42"email-error-5-1-10","5.1.10","X.1.10","5-1-10","https://blazalek.com/en/email-errors/5-1-10","addressing","permanent_failure","do_not_retry","check_context","[""sender"",""sender_admin""]","5.1.10 — Recipient address points to a null-MX domain","The recipient address is associated with a domain marked by a null MX as not accepting mail. This is a permanent failure, so do not retry delivery to the same unchanged address.","The recipient domain publishes a null MX, meaning it does not accept mail. Treat as a hard bounce for list hygiene: continuing to send damages reputation. Permanent: do not retry the same unchanged address.","A null MX available by the recipient domain marks the associated address invalid under pattern X.1.10 as code 5.1.10, signalling that the domain does not accept Internet mail. Class 5 classifies the result as permanent in the enhanced status register. The enhanced detail names a DNS-level non-reception signal rather than a missing mailbox name inside an otherwise normal domain. Some providers add recipient-not-found wording next to the code, but that phrasing does not replace the standards definition of null MX.","Using a null MX to mark the associated address invalid is the X.1.10 pattern.","The leading digit 5 denotes a permanent failure. The unchanged attempt should not be retried; a new send is justified only after the address has been reliably corrected or a change in the domain's state has been confirmed.","Operational guidance: stop automatic and manual retries to the same unchanged address. Consider a new attempt only after a confirmed address correction or a fresh confirm of the domain's MX state.","Operational guidance: inspect the full response, exact address, and MX result before deciding suppression. Do not blanket-suppress other addresses or domains from a single 5.1.10 result; handle a confirmed address under local policy.","[""The domain in the recipient address publishes a null MX, indicating that it does not accept mail."",""Sender data contains an incorrect recipient domain that leads to a null MX.""]","[""Compare the full address, especially its domain part, with a trusted available information value; do not guess the correct address."",""Check the MX records for the exact domain and confirm that the result actually denotes a null MX; retain that result with the full response for the handling decision.""]","{""sender"":[""confirm the address with the recipient or another trusted available information, and correct it only when a confirmed value is available."",""Do not resend to the same address; if no correction is available, use another agreed contact channel.""],""sender_admin"":[""Make a suppression decision for the confirmed address under local policy without automatically extending it to other addresses or domains.""]}","[""5.1.1"",""5.1.3"",""5.1.8"",""2.1.5""]","esc-5-1-10","permanent","recipient_invalid","invalid","do_not_retry","no_recommendation","high","true"43"email-error-5-1-2","5.1.2","X.1.2","5-1-2","https://blazalek.com/en/email-errors/5-1-2","addressing","permanent_failure","do_not_retry","check_context","[""sender"",""sender_admin""]","5.1.2 — Recipient address rejected as an invalid destination","The receiving system reports that the recipient address itself failed its address-validity check and was rejected at the RCPT TO stage. The code belongs to the permanent class: correct or remove the address before sending again, and do not retry the same unchanged value.","The destination system rejected the recipient address as invalid: a permanent failure, not a temporary block. Correct or remove the address for list hygiene; do not retry the same unchanged address. Gmail's own context shows this specific rejection is address-format based, not confirmation the domain itself does not exist.","SMTP specification glosses status-code list pattern X.1.2 (""Bad destination system address"") as a destination system that does not exist or cannot accept mail at all, locates the fault on the address part to the right of the ""@"" sign, and limits the detail to permanent failures; code 5.1.2 marks that pattern with a permanent class. This catalog's enhanced status-code mirror gives X.1.2 no Associated Basic Status Code confirmation at any class: neither 4.1.2 nor 5.1.2 is mechanically status-code list-confirmed here. That context rejects recipient-address format; it does not establish a domain-does-not-exist condition, and so reads narrower and more provider-specific than the status-code list gloss.","Pattern X.1.2 names a destination system that does not exist or cannot accept mail at all. For an Internet mail address, SMTP specification places the fault on the part to the right of the ""@"" sign and treats the detail as useful only for permanent failures.","The leading digit 5 denotes a permanent failure. Repeating the same attempt with an unchanged address is not the appropriate response; a new send is justified only after the address has been corrected from a trusted available information. Do not conflate this with 5.1.3, the confirmed code for bad destination mailbox address syntax, even though the context text below also invokes address-format validity.","Do not automatically or manually retry delivery to the same unchanged address. Treat 5.1.2 like any other hard-bounce addressing failure: stop sending to this exact address until it has been corrected from a trusted available information, and do not guess a replacement value.","Do not apply unconditional or blanket suppression across a domain based on a single 5.1.2. Confirm the rejection targets this exact address, inspect the full response text, and apply your addressing-failure policy to that one recipient; a malformed or mistyped address is often sender-side data quality, not context against the domain or other recipients there.","[""The recipient address as submitted does not conform to the syntax SMTP specification requires for a valid SMTP mailbox address — for example a malformed local-part or domain segment — and the destination system rejects it outright at RCPT TO."",""The sending application built, copied, or imported the address incorrectly (truncation, stray characters, or an encoding problem), producing a value close to a real address but not itself valid.""]","[""Compare the exact recipient address against SMTP specification's mailbox syntax rules and against the value held in your trusted available information system; look specifically for malformed characters, missing or duplicated segments, or encoding damage introduced before the send."",""Trace the address to where it entered your sending data (import, form submission, API call) to find whether the corruption happened at capture time or later in your pipeline."",""Do not resend to the same address; treat it as a hard bounce and route it through your standard permanent-failure handling once the exact code and full response are confirmed.""]","{""sender"":[""Do not resend to the same unchanged address; confirm it against a trusted available information and correct it only with a confirmed replacement value."",""If malformed addresses like this recur across many recipients, check the code path that builds or imports addresses for a systematic bug rather than fixing entries one at a time.""],""sender_admin"":[""Stop automatic retries for the unchanged address, retain the full response text, and confirm which system or import supplied the malformed value."",""Apply your organization's permanent-failure and suppression policy to this specific address once the rejection is confirmed; do not extend suppression to the domain or other recipients.""]}","[""5.1.0"",""5.1.1"",""5.1.3"",""5.1.10""]","esc-5-1-2","permanent","recipient_invalid","invalid","retry_after_correction","no_recommendation","medium","true"44"email-error-5-1-3","5.1.3","X.1.3","5-1-3","https://blazalek.com/en/email-errors/5-1-3","addressing","permanent_failure","do_not_retry","check_context","[""sender"",""sender_admin""]","5.1.3 — Invalid recipient address syntax","The message was permanently rejected because the recipient mailbox address has invalid syntax. Retrying with the same address will not remove the error.","The recipient address syntax is invalid, so the message was permanently rejected before delivery. Fix addressing at the available information: bad syntax poisons list quality and wastes sends. Permanent: do not retry until the address is corrected from a trusted available information.","Code 5.1.3 instantiates pattern X.1.3 when the destination mailbox address fails syntactic validation, and the fault may sit in any field of that address string, not only the local-part. Class 5 in the enhanced register reports this as a permanent refusal for the current transaction. The status detail states that the submitted address form is unusable; it does not by itself identify which field broke, which upstream system introduced the bad value, or whether a corrected form would succeed.","Syntactic invalidity of the destination mailbox address is what X.1.3 means; the error can apply to any field in that address. Concrete code 5.1.3 pairs this meaning with permanent class 5, for which the standard defines this detail.","The leading digit 5 denotes a permanent failure. The current delivery request should not be retried unchanged, although correcting the address from reliable information may allow a new send.","Operational guidance: stop automatic and manual retries with the unchanged address. Send again only after obtaining and applying a reliable address correction, treating it as a new attempt with corrected data.","Operational guidance: evaluate suppression in the context of the exact address and the available information of the invalid value. Do not blanket-suppress the recipient, domain, or broader traffic from a single 5.1.3 result; a confirmed unusable address may be blocked under local policy.","[""The available information data contains a destination mailbox address with invalid syntax."",""The message-construction process produced a syntactically invalid destination-address field.""]","[""Compare the complete destination address with a trusted available information value and check the syntax of each field; do not guess the correct address."",""Trace the address from input data to the completed message to determine whether the invalid syntax came from the stored value or the message-construction process.""]","{""sender"":[""confirm the address against a value supplied or confirmed by the recipient, and change it only when you have a reliable correction."",""Do not resend to the same address; if it cannot be confirmed, request a correct address through another available channel.""],""sender_admin"":[""Review input validation and address-field construction, and limit any suppression decision to the confirmed address and local policy instead of applying a blanket rule.""]}","[""5.1.1"",""5.1.8"",""5.1.10"",""2.1.5""]","esc-5-1-3","permanent","recipient_invalid","invalid","retry_after_correction","no_recommendation","high","false"45"email-error-5-1-8","5.1.8","X.1.8","5-1-8","https://blazalek.com/en/email-errors/5-1-8","addressing","permanent_failure","do_not_retry","check_context","[""sender"",""sender_admin""]","5.1.8 — Invalid sender system address","The system identified by the sender address does not exist or cannot accept return mail. Code 5.1.8 is a permanent failure, so do not retry the unchanged send.","The sender system in the MAIL FROM address does not exist or cannot accept return mail. Fix sender identity and bounce routing: bad From domains affect deliverability and reputation. Permanent failure: do not retry until sender addressing is corrected.","On the envelope return path rather than the recipient mailbox, code 5.1.8 targets the sender system named under pattern X.1.8. The status means the identified mail host is missing or cannot receive bounce traffic back; when the address uses a domain name, the right-hand domain segment is at issue. Class 5 places the result in the permanent category of the enhanced register. The enhanced detail records an envelope addressing problem; it does not by itself diagnose a wrong visible From header or support broad suppression of other destinations.","The sender system specified in the address does not exist or is incapable of accepting return mail: that is X.1.8. For a domain name, the part of the address to the right of the ""@"" sign is invalid for mail. Code 5.1.8 combines this meaning with permanent class 5.","The leading digit 5 denotes a permanent failure. The same attempt should not be retried unchanged; a new send is justified only after the sender address or its system has been reliably corrected.","Operational guidance: stop automatic and manual retries with the same sender address and unchanged configuration. Send again only after a confirmed address correction or after the identified system has been restored to a state in which it can accept return mail.","Operational guidance: do not apply unconditional or blanket suppression solely from code 5.1.8. First inspect the full response, exact sender address, and its configuration; this code alone does not justify suppressing the recipient or the recipient domain.","[""The domain part of the sender address does not identify an existing mail system."",""The system identified by the sender address is incapable of accepting return mail.""]","[""Read the sender address used in the rejected attempt and compare the part after the “@” sign with the trusted configuration of the sending system."",""confirm that the identified system exists and can accept return mail, then trace the available information of the address or configuration before preparing a new send.""]","{""sender"":[""confirm the sender address against a trusted available information and change it only when you have a confirmed replacement value."",""Do not retry with the same address and configuration; if you cannot confirm a correction, escalate the problem to the sender-system administrator.""],""sender_admin"":[""Stop retries of the unchanged send, retain the full response, and determine how the exact sender address used in the transaction was produced."",""Correct the address or configuration of the identified system, confirm that it can accept return mail, and only then allow a new send; do not suppress the recipient because of this code.""]}","[""4.1.8"",""5.1.1"",""5.1.3"",""5.1.10""]","esc-5-1-8","permanent","infrastructure","unverified","retry_after_correction","no_recommendation","high","true"46"email-error-5-2-0","5.2.0","X.2.0","5-2-0","https://blazalek.com/en/email-errors/5-2-0","mailbox","permanent_failure","do_not_retry","check_context","[""sender"",""sender_admin"",""recipient_admin""]","5.2.0 — Generic mailbox-status rejection, identified as a DMARC policy failure","5.2.0 — Generic mailbox-status rejection, identified as a DMARC policy failure","Treat it as permanent: fix the sending domain's SPF/DKIM alignment and DMARC policy. Do not just retry, and do not suppress the address on this code alone.","Mechanical enhanced status-code confirmation for status-code list pattern X.2.0 (""Other or undefined mailbox status"") covers no class at all in this catalog: the status-code list lists Associated Basic Status Code as ""Not given,"" and the canonical mirror leaves the pattern's resolution status unresolved. Code 5.2.0 nonetheless puts a permanent class on that generic catch-all detail in the mailbox subject family when no more specific status code fits.","Within the mailbox subject family (subject 2), X.2.0 is enhanced status-code's generic/undefined status: ""the mailbox exists, but something about the destination mailbox has caused the sending of this DSN."" SMTP specification lays out the subject/detail scheme without fixing a class for every pattern. For X.2.0 itself, the status-code list's Associated Basic Status Code remains ""Not given,"" and this catalog's canonical mirror stores classApplicability.resolutionStatus as ""unresolved"", so neither class 4 nor class 5 has mechanical enhanced status-code confirmation for the pattern.","This differs from a hypothetical class-4 use of the same X.2.0 detail, which would describe a condition expected to clear on its own — no such class-4 concrete code is available in this catalog on the context available.","Do not retry the identical message unchanged: a DMARC-driven 5.2.0 will recur on every attempt until the sending domain's SPF/DKIM alignment or DMARC policy changes. Stop automatic retries of this send; escalate to the domain's authentication owner (sender_admin), and only resend after the domain's SPF, DKIM, or DMARC configuration has been corrected and recheck.","Route the signal to the team responsible for the sending domain's authentication rather than the list-hygiene process, and only apply suppression if an independent, address-specific signal (not this code) justifies it.","[""The sending domain's DKIM signature is missing, invalid, or not aligned with the From: header domain, so DMARC has no passing, aligned mechanism."",""The sending domain's SPF record does not authorize the sending IP, or the Return-Path domain is not aligned with the From: domain, removing the SPF path to a DMARC pass."",""The sending domain publishes a DMARC policy of p=reject (or the receiving system escalates p=quarantine to an outright rejection), and this specific message has no aligned pass, so the receiving system rejects it during the SMTP session rather than delivering it.""]","[""Pull the authentication results for this exact message: SPF result and alignment, DKIM result and alignment (signing d= domain versus the From: header domain), and the sending domain's available DMARC policy (dig txt _dmarc.<domain>)."",""If DKIM fails, check whether the signing key or selector rotated or broke, and whether an intermediate hop (forwarder, mailing-list expansion, security gateway) altered the message and invalidated the signature in transit."",""If the response text does not reference DMARC or authentication, treat 5.2.0 as this provider's generic mailbox-status catch-all and correlate with other available signals before assuming an authentication cause.""]","{""sender"":[""Stop retrying the identical message: without a change to the sending domain's authentication, the same DMARC rejection will recur on every attempt."",""Escalate to sender_admin with the exact response text, the message's Message-ID, and the attempt time before resending this message or any campaign from the same domain.""],""sender_admin"":[""Fix DKIM signing so the signing domain aligns with the From: header domain, and/or fix SPF so the Return-Path domain aligns — either aligned, passing mechanism satisfies DMARC."",""Review the domain's available DMARC policy and aggregate (rua) reports to confirm which mechanism is failing and whether the receiving system's enforcement matches the policy on record before resending affected traffic.""],""recipient_admin"":[""If 5.2.0 appears on a system you administer and the response text does not mention DMARC or authentication, treat it as this provider's generic mailbox-status code and inspect the exact text rather than assuming an authentication cause."",""For a confirmed DMARC rejection there is no fix available on the receiving side: the receiving system is enforcing the sending domain's own available policy, so direct the sender to their domain's authentication owner rather than adjusting local mail-flow rules.""]}","[""5.2.2"",""5.2.3""]","esc-5-2-0","permanent","unknown","unverified","retry_after_correction","no_recommendation","low","true"47"email-error-5-2-1","5.2.1","X.2.1","5-2-1","https://blazalek.com/en/email-errors/5-2-1","mailbox","permanent_failure","do_not_retry","check_context","[""sender"",""recipient"",""recipient_admin""]","5.2.1 — Recipient mailbox exists but is disabled","The receiving system reports that the mailbox exists but is disabled and is not accepting messages. The code belongs to the permanent class for this attempt: do not retry the same unchanged send.","The recipient mailbox exists but is disabled and is not accepting any mail. Permanent for this attempt: do not retry unchanged. This is not the same as a nonexistent address (5.1.1) — the account exists but has been deactivated, suspended, or closed. Confirm the situation through another channel before removing the address from a list for good.","Under code 5.2.1 the status names a disabled-account condition: it applies status-code list pattern X.2.1 (""Mailbox disabled, not accepting messages""), so the mailbox exists, yet the receiving system refuses messages for it because the account has been disabled. It does not signal a nonexistent address or a temporary rate limit.","That pattern means the destination mailbox exists but will not accept messages because it has been disabled. SMTP specification notes that this condition may be permanent (the mailbox will never be re-enabled) or transient (temporarily disabled), without settling which class belongs to any concrete code; in this catalog, the enhanced status-code status-code list does not mechanically confirm any class for X.2.1.","The leading digit 5 denotes a permanent failure of this attempt: the account is disabled, and the send should not be retried unchanged. This does not certify that the account can never be re-enabled — only that, absent a confirmed change, retrying now will fail the same way. Do not conflate this with 5.1.1, where the address itself does not exist.","Stop automatic and manual retries of the unchanged send. Consider a new attempt only after independent confirmation — from the recipient through another channel, or from their administrator — that the account has been re-enabled.","Treat a confirmed 5.2.1 as a strong suppression candidate, but inspect the full response and recent delivery history first: a disabled account can later be reactivated by its owner or administrator, so record the date of the disable signal and consider re-validating the address rather than deleting it outright, especially in a business (Workspace) context where the account may return after a temporary leave or an offboarding process.","[""The recipient closed their own account, or it was suspended by the mailbox provider (for example, for a Terms of Service violation), and the account is not accepting any mail while in that state.""]","[""Correlate the response with the specific message, attempt time, and recipient address; retain the full response text, including any provider link (such as a disabled-account support page)."",""Ask the recipient, ideally through another channel, whether the account was intentionally closed, suspended, or is under administrator review; in a business setting, ask the domain administrator directly."",""Check delivery history for this address: a sudden 5.2.1 after a long run of successful deliveries points to a recent suspension or offboarding event rather than a long-stale address.""]","{""sender"":[""Stop retrying the unchanged send immediately; a disabled account will keep rejecting the same message."",""Mark the address for review rather than deleting it right away, and re-attempt only after independent confirmation that the account is active again.""],""recipient"":[""If you closed or suspended your own account intentionally, no action is needed; senders will keep seeing this response until the account is reopened."",""If the account was disabled unexpectedly, contact your mailbox provider or, on a business account, your domain administrator to confirm the reason and request reinstatement.""],""recipient_admin"":[""Confirm whether the suspension was deliberate (policy violation, offboarding, security hold) or unexpected, and check the organization's suspension log for this user."",""If the suspension was accidental or the user should regain access, re-enable the account and confirm it with a test message before advising senders to retry.""]}","[""5.1.1"",""5.2.2""]","esc-5-2-1","permanent","mailbox_state","unverified","do_not_retry","no_recommendation","medium","false"48"email-error-5-2-2","5.2.2","X.2.2","5-2-2","https://blazalek.com/en/email-errors/5-2-2","mailbox","permanent_failure","do_not_retry","check_context","[""sender"",""recipient"",""recipient_admin""]","5.2.2 — Recipient mailbox is full","The recipient mailbox has exceeded its assigned quota or reached physical capacity. Code 5.2.2 is a permanent failure, so do not retry the same unchanged send.","The recipient mailbox exceeded its quota or physical capacity. Not a list-hygiene hard bounce, but repeated permanent rejects to the same address add noise to metrics. Permanent for this attempt: do not retry unchanged; recipient must free space or raise quota.","Mailbox-full detail X.2.2 appears as code 5.2.2 in the mailbox family when the destination mailbox is full because its user hit an administrative quota or the physical storage limit. Class 5 makes this attempt a permanent failure in the enhanced register even though the underlying capacity state can change later. Unlike pure addressing refusals, the recipient address itself may remain valid once space is freed. The code alone does not show which quota was exceeded, current usage, or that the recipient has already cleared mail.","A full mailbox, because its user exceeded a per-mailbox administrative quota or its physical capacity, is what X.2.2 means. The standard indicates that the recipient may make space by deleting messages. Concrete code 5.2.2 pairs that meaning with permanent class 5.","The leading digit 5 denotes a permanent failure of the current send. Although the recipient or administrator may later free space, the same attempt should not be retried without a confirmed change that removes the cause.","Operational guidance: stop automatic and manual retries of the unchanged send. Consider a new attempt only after the recipient or administrator confirms that space has been freed or the applicable quota has been changed.","Operational guidance: inspect the full response, exact address, delivery history, and local policy before deciding suppression. Code 5.2.2 alone does not justify automatically suppressing the address or its entire domain because the capacity condition may later change.","[""The recipient exceeded the administrative quota assigned to the mailbox."",""The mailbox reached its available physical capacity.""]","[""Correlate the result with the intended message, attempt time, and exact recipient address; do not infer the product or mailbox type from the code alone."",""Ask the recipient or their administrator to inspect the quota and capacity of that mailbox and confirm whether space has been freed."",""Retain the full response and record the confirmed state change before preparing a new send; do not retry without such a change.""]","{""sender"":[""Stop retries of the unchanged send and give the recipient the code, attempt time, and full response without data unrelated to the diagnosis."",""Send a new message only after reliable confirmation that space is available; do not guess a different recipient address.""],""recipient"":[""Check mailbox usage and, where possible, delete unneeded messages or otherwise free space."",""If you cannot remove the limit yourself, give the administrator code 5.2.2 and the attempt time, and tell the sender only after space has actually been freed.""],""recipient_admin"":[""Inspect the specified mailbox's administrative quota, capacity usage, and logs corresponding to the failed-attempt time."",""Remove the confirmed constraint by freeing capacity or making the appropriate quota change, confirm the new state, and only then advise that a new attempt can be made.""]}","[""5.2.3"",""4.2.4""]","esc-5-2-2","permanent","mailbox_state","unverified","do_not_retry","no_recommendation","high","false"49"email-error-5-2-3","5.2.3","X.2.3","5-2-3","https://blazalek.com/en/email-errors/5-2-3","mailbox","permanent_failure","do_not_retry","check_context","[""sender"",""recipient"",""recipient_admin""]","5.2.3 — Message exceeds the mailbox limit","The message was permanently rejected because its length exceeds the administrative limit for the recipient's specific mailbox. Do not retry the unchanged send.","The message exceeds the administrative length limit for that specific mailbox. Reduce content size or split the send: retrying unchanged will always fail. Permanent failure with no list-hygiene action unless the address itself is wrong.","During transfer, code 5.2.3 maps pattern X.2.3 when a per-mailbox administrative size ceiling was exceeded. In the enhanced status register, class 5 treats the outcome as permanent. The status-code list text uses this detail when a mailbox-specific cap is lower than the general system limit; the status names a size policy conflict at that mailbox, not invalid recipient data.","An administrative message-length limit set for a specific mailbox has been exceeded under X.2.3. The standard identifies this code when a mailbox-specific cap sits below the system-wide maximum and says it should be used as a permanent failure. Code 5.2.3 combines that meaning with class 5.","The leading digit 5 denotes a permanent failure of the current delivery request. Retrying the same message to the same mailbox without changing the message length or the limit should not be expected to succeed.","Operational guidance: stop automatic and manual retries of the unchanged message. Consider a new send only after the message has been confirmed smaller or the mailbox limit has been confirmed changed.","Operational guidance: do not automatically add the recipient address to a suppression list solely because of code 5.2.3. The code describes the relationship between message length and a mailbox limit, not address validity; decide only after inspecting the full response, address, message, and applicable policy.","[""The message length exceeds the administrative limit set for the recipient mailbox; that mailbox's limit may be lower than the general system limit.""]","[""Correlate the response with the intended message, recipient address, and attempt time, then determine the length of the message actually transferred in that attempt."",""Ask the recipient or recipient-system administrator to confirm the limit applied to that mailbox and compare it with the message length; do not infer a specific limit value from the code alone."",""Before a new send, confirm that the message was actually reduced or that the mailbox limit was changed.""]","{""sender"":[""Stop retries of the unchanged message and retain the full response and failed-attempt context."",""Agree with the recipient on a safe way to reduce the message, and send again only after a confirmed change.""],""recipient"":[""Confirm to the sender that the mailbox address used is correct, and give the code and attempt time to the administrator if the limit is unknown."",""Agree with the sender on an acceptable way to deliver a smaller message, or wait for a confirmed limit change.""],""recipient_admin"":[""Inspect configuration and logs for the specified mailbox and attempt time to confirm the applicable limit and how it applied to this message."",""If policy permits, adjust the limit or communicate the confirmed restriction to the sender and recipient; confirm the change before another attempt.""]}","[""5.2.2"",""4.2.4""]","esc-5-2-3","permanent","policy_block","unverified","retry_after_correction","no_recommendation","high","false"50"email-error-5-3-0","5.3.0","X.3.0","5-3-0","https://blazalek.com/en/email-errors/5-3-0","mail-system","permanent_failure","do_not_retry","check_context","[""sender_admin"",""recipient_admin"",""provider""]","5.3.0 — Other or undefined permanent mail-system status","The destination system exists and normally accepts mail, but a general problem in that system caused a permanent failure. Do not retry the same unchanged attempt.","The destination mail system exists but returned a permanent, undefined internal failure. Investigate provider-side status before resending: blind retries waste capacity and can look like poor sending hygiene. Permanent: do not retry the unchanged attempt.","Without a finer sub-detail, code 5.3.0 applies status-code list pattern X.3.0 as a permanent mail-system status. The destination host is reachable as a mail system, yet some internal condition there triggered a DSN at class 5. The .3.0 subcode is intentionally general: it reports an unspecified system-side fault, not an invalid recipient address or a routing miss.","Another or undefined mail-system status is what X.3.0 denotes. The destination system exists and normally accepts mail, but a condition involving that system caused a DSN to be generated; in 5.3.0, class 5 denotes permanent failure.","This is a permanent status, not a temporary error. The .3.0 detail does not identify a more specific type of problem and does not by itself establish that the recipient address is invalid.","Operational recommendation: stop automatic retries of the unchanged attempt. Consider a new submission only after establishing the cause from the full response and making an appropriate change to configuration, routing, or handling.","Operational recommendation: do not add the address to a suppression list based on 5.3.0 alone. Inspect the full response, event history, and established cause; suppress only when the applicable policy or an independent permanent signal justifies it.","[""An unspecified condition in the destination system caused a permanent failure while handling the message."",""The system generating the DSN reported the general X.3.0 status without a more specific code describing the mail-system problem.""]","[""Correlate the response with the intended message, attempt time, and SMTP stage; retain the full response text because the code alone does not identify the exact cause."",""Compare sending-side and, when available, destination-side logs to determine which system generated the DSN and whether it recorded a more specific permanent condition."",""Before any new submission, confirm that the identified problem was corrected or that configuration, routing, or handling was changed.""]","{""sender_admin"":[""Establish the cause before a new submission; base suppression on the full context, and give the attempt data to the recipient administrator or applicable provider.""],""recipient_admin"":[""Inspect the destination system's state and logs for the specified time and attempt, and identify the permanent condition when possible."",""Correct the confirmed problem and confirm message acceptance; when the system knows a more specific status, preserve it in the response instead of replacing it with general 5.3.0.""],""provider"":[""If you operate infrastructure involved in this attempt, retain the full SMTP response and inspect service logs for the specified time and destination system."",""Correct a confirmed permanent problem or provide administrators with any available, more specific status; do not suppress the recipient solely because of 5.3.0.""]}","[""2.3.0"",""4.3.0"",""5.3.2"",""5.3.4""]","esc-5-3-0","permanent","infrastructure","unverified","retry_after_correction","no_recommendation","low","false"51"email-error-5-3-2","5.3.2","X.3.2","5-3-2","https://blazalek.com/en/email-errors/5-3-2","mail-system","permanent_failure","do_not_retry","check_context","[""sender_admin"",""recipient_admin"",""provider""]","5.3.2 — System not accepting network messages — permanent failure","The host on which the recipient's mailbox resides is not accepting messages and rejected the current request as a permanent failure. Do not retry the unchanged send.","The host holding the recipient mailbox is not accepting network messages and permanently rejected the attempt. Often signals a decommissioned or blocked destination: confirm routing before any retry. Permanent failure; address-level list hygiene may apply if the mailbox is gone.","When the mailbox host refuses network message intake for this attempt, status-code list pattern X.3.2 surfaces as code 5.3.2 under class 5. The status-code list cites imminent shutdown, excessive load, and maintenance as illustrative causes, yet the subcode alone does not pick among them. That class digit makes the outcome permanent for this response; it still does not establish the recipient address is wrong or that the host will never accept mail again.","Not accepting messages on the host where the mailbox resides is the meaning of X.3.2. The standard lists an imminent shutdown, excessive load, and system maintenance as examples. The pattern can describe either a permanent or a persistent transient error; in code 5.3.2, the leading digit assigns the result to the permanent class.","The leading digit 5 denotes a permanent failure of the current delivery request. The code does not, however, establish that the recipient address is invalid or that the host will never accept mail again.","Operational guidance: stop automatic and manual retries of the unchanged send. Consider a new attempt only after a reliable confirmation that the host's state or configuration has changed and after checking suppression again.","Operational guidance: do not automatically add the recipient address to a suppression list solely because of 5.3.2. The code concerns a mail-system host, not address validity; inspect the full response, event scope, history, and applicable policy, and suppress only with independent justification.","[""The host rejects network messages because it is approaching shutdown."",""Excessive load or system maintenance caused the host to stop accepting messages.""]","[""Correlate the response with the intended message, attempt time, SMTP stage, and host that returned it; retain the full text because the code alone does not identify the particular cause."",""Ask the recipient-system administrator or provider to inspect shutdown state, load, and maintenance for the same time and confirm that the host is accepting messages again before a new send is prepared.""]","{""sender_admin"":[""Evaluate suppression in the context of the full event and consider a new send only after a confirmed host-side change; do not suppress the recipient solely because of 5.3.2.""],""recipient_admin"":[""Inspect the mailbox host's state and logs for the rejection time, especially shutdown, load, and maintenance."",""Clear the confirmed condition within your control, confirm that messages are accepted, and only then tell the sender that a new attempt can be made.""],""provider"":[""If you operate the host that returned the error, inspect its availability, load, maintenance, and configuration for the specified time."",""Clear the confirmed condition, confirm message acceptance, and preserve the exact status code in responses so that the sender does not retry a permanent result without a change.""]}","[""4.3.2"",""5.3.0"",""5.3.4"",""2.3.0""]","esc-5-3-2","permanent","infrastructure","unverified","do_not_retry","no_recommendation","medium","true"52"email-error-5-3-4","5.3.4","X.3.4","5-3-4","https://blazalek.com/en/email-errors/5-3-4","mail-system","permanent_failure","do_not_retry","check_context","[""sender_admin"",""recipient_admin"",""provider""]","5.3.4 — Message exceeds the system size limit","The message was permanently rejected because it is larger than the system's per-message size limit. Do not retry the same unchanged send.","The message exceeds the destination system's per-message size limit. Shrink attachments or use links: unchanged retries will never deliver. Permanent failure; deliverability is unaffected once message size fits policy.","Oversize relative to a per-message size cap on the processing mail system is what code 5.3.4 records under status-code list pattern X.3.4 at class 5. The status-code list allows this subcode only for permanent errors and covers limits set for physical or administrative reasons. Exceeding a header-size ceiling, as in some provider responses, fits the same pattern; the status describes system policy, not recipient address validity.","A message larger than a per-message size limit imposed for physical or administrative reasons falls under X.3.4. The standard specifies this status as useful only for permanent errors; code 5.3.4 combines that meaning with class 5.","The leading digit 5 denotes a permanent failure of the current delivery request. The unchanged message should not be resubmitted to a system with the same limit; the code does not, however, mean that the recipient address is invalid.","Operational guidance: stop automatic and manual retries of the unchanged message. Consider a new send only after the message or its headers have been confirmed smaller, or after a confirmed change to the system limit.","Operational guidance: do not automatically add the recipient address to a suppression list solely because of 5.3.4. Inspect the full response, message, applied limit, and event history; suppress only when the applicable policy or an independent permanent signal justifies it.","[""The message size exceeds a physical or administrative per-message limit in the system processing it.""]","[""Correlate the response with the intended message, attempt time, and system that returned it; retain the full response text and determine the size of the message actually presented in that attempt."",""Before a new send, confirm that the message or its headers were actually reduced or that the applied system limit was changed.""]","{""sender_admin"":[""Determine the presented message size and scope of the exceeded limit; prepare a new send only after a confirmed reduction of the message or headers, or a confirmed limit change.""],""recipient_admin"":[""Inspect system configuration and logs for the specified time to confirm the applied per-message or header limit."",""If policy permits, adjust the limit or communicate the confirmed restriction to the sender; confirm the change before another attempt.""],""provider"":[""If you operate the system that returned the error, inspect the applied message and header limits and the logs for the specified attempt."",""Correct a confirmed configuration error or provide administrators with the exact restriction; preserve the exact code and response text, and do not suppress the recipient solely because of 5.3.4.""]}","[""5.3.0"",""5.3.2"",""2.3.0"",""2.3.6""]","esc-5-3-4","permanent","policy_block","unverified","retry_after_correction","no_recommendation","high","false"53"email-error-5-4-0","5.4.0","X.4.0","5-4-0","https://blazalek.com/en/email-errors/5-4-0","network-dns-routing","permanent_failure","do_not_retry","check_context","[""sender_admin"",""recipient_admin"",""provider""]","5.4.0 — Message rejected for exceeding the mail system's hop limit (routing-loop protection)","The receiving system reports a permanent delivery failure using the enhanced code 5.4.0: in the accepted context, a mail system aborted delivery because the message had already passed through more hops than its configured safety limit allows — the mechanism mail systems use to abort suspected routing loops. The code itself is the status-code list's generic ""other or undefined network or routing status"" catch-all, not a status defined specifically for hop-count loop protection.","Do not resend the identical message; find and remove the routing or forwarding loop first, then let the sender try again.","The code maps status-code list pattern X.4.0 onto class 5. SMTP specification seats X.4.0 in the base table as the generic network-and-routing catch-all for problems that do not fit any of the pattern's more specific detail codes, yet enhanced status-code's Associated Basic Status Code for X.4.0 is ""Not given"" for every class, and this catalog's status-code list mirror treats the pattern as fully unresolved: no class is mechanically confirmed at all, not even a class-4 reading.","Unlike siblings such as X.4.1 (""no answer from host"", class 4 confirmed) or X.4.3 (""directory server failure"", classes 4 and 5 confirmed), enhanced status-code records the Associated Basic Status Code for X.4.0 as ""Not given"" for every class, and this catalog's status-code list mirror carries the pattern as fully unresolved. SMTP specification (Section 3.4) defines the X.4 subject class as network-and-routing status and lists X.4.0 in the base table as that class's generic catch-all detail: something went wrong with the networking, but it is not clear what the problem is, or the problem cannot be well expressed with any of the other provided detail codes. Neither 4.4.0 nor 5.4.0 rests on an enhanced status-code class confirmation.","The leading digit 5 denotes a permanent failure for this message in its current context: resending it unchanged will not succeed, because the condition producing a hop-count abort — typically a routing or forwarding loop — reproduces identically on the same path. This does not by itself mean the recipient address is invalid; it means the path the message took looped, or grew too long, before reaching it.","Do not resend the identical message on the same path. A resend only makes sense once the loop has actually been found and removed — a forwarding rule corrected, a relay or smart-host route fixed — not simply after time has passed. If the same 5.4.0 recurs on an unmodified path, that confirms the loop is still present rather than transient congestion.","Do not add the address to a suppression list based on a single 5.4.0. The condition describes the message's path, not necessarily the address itself; correlate repeated occurrences with an actual routing or forwarding diagnosis before treating the address as unreachable, and suppress only when list policy or an independent permanent signal justifies it.","[""A mailbox-level forwarding loop: the recipient's account (or a mailing list it belongs to) auto-forwards mail back along a path that returns to the same message, adding Received: header hops until the destination's configured limit is exceeded."",""A misconfigured relay or routing chain between two or more mail systems — for example a smart host or gateway whose route points back at itself, or two systems relaying to each other — that keeps re-injecting the same message until the hop-count safety check trips.""]","[""Pull the full Received: header chain from the original message (or the copy attached to the bounce, if present) and count the hops; look for a repeating hostname or address, which indicates a cycle rather than an ordinary long relay chain."",""Check the recipient's own forwarding configuration — webmail auto-forward rules, mailing-list membership, or alias chains — for a rule that resends the message back toward the sender or back through the same relay."",""If a corporate relay, smart host, or gateway sits between sender and recipient, inspect its routing table for a self-referencing or circular route, and correct it before asking the sender to resend.""]","{""sender_admin"":[""Stop resending the identical message on the same path; a hop-count rejection reflects a routing condition that reproduces unchanged. Retain the full response text and the exact time of the attempt."",""Reach the recipient, or their mail administrator, through another channel, share the response text, and ask whether a forwarding rule or relay configuration on their side could be creating a loop.""],""recipient_admin"":[""Check the recipient's own forwarding rules and any mailing-list or alias membership for a cycle that sends mail back toward its origin or repeatedly through the same relay."",""If you operate the receiving platform yourself, inspect the routing or relay chain for a misconfigured smart host or gateway that re-injects the message instead of delivering it, and confirm the fix before the sender retries.""],""provider"":[""If you operate the receiving mail system, confirm the hop-count abort is firing on a genuine loop and not on a legitimate long-but-valid forwarding chain, before advising senders that the message cannot be delivered as addressed."",""Preserve the full diagnostic text, including the host that issued the rejection and the SMTP phase (end of DATA), so downstream systems can distinguish this hop-limit abort from unrelated 5.4.x failures.""]}","[""4.4.0"",""4.4.1"",""4.4.6"",""5.4.3""]","esc-5-4-0","permanent","infrastructure","unverified","retry_after_correction","no_recommendation","low","true"54"email-error-5-4-1","5.4.1","X.4.1","5-4-1","https://blazalek.com/en/email-errors/5-4-1","network-dns-routing","permanent_failure","do_not_retry","check_context","[""sender_admin"",""recipient_admin"",""provider""]","5.4.1 — Mail rejected by the destination domain (permanent)","The receiving system reports a permanent, destination-side rejection of the message using the enhanced code 5.4.1: the destination domain's own mail filters, or a recipient-address access policy, refused the message or address in a way this catalog's collected context never ties to a literal, unanswered connection attempt. Class 5 makes this a permanent result for the current context.","In production, 5.4.1 means a permanent, destination-side rejection — the receiving domain's own mail filters or its recipient-access policy, not (based on the delivery context gathered here) a literal unanswered connection attempt. Do not retry the same message unchanged; reach the recipient or their mail administrator through another channel, and only resend after something has actually changed.","This catalog's enhanced status-code status-code list mirror mechanically confirms only the class-4 reading of status-code list pattern X.4.1 (code 4.4.1). No enhanced status-code status-code list exists here for any class-5 variant of the pattern, yet code 5.4.1 maps that pattern onto class 5. Under SMTP specification, X.4.1 means ""no answer from host"" and is useful only as a persistent transient failure.","Pattern X.4.1 denotes no answer from the remote host: an outbound connection attempt went unanswered because the remote system was busy or unable to accept the call. SMTP specification states the pattern generically, and this catalog's enhanced status-code status-code list mirror mechanically confirms only the class-4 variant (4.4.1, basic SMTP code 451, a persistent transient failure). No enhanced status-code status-code list mechanism confirms a class-5 variant of X.4.1 here.","The leading digit 5 denotes a permanent failure for this message in the current context: do not repeat the exact same send unchanged. This does not by itself mean the recipient address is permanently invalid — both accepted examples describe a filter or access-policy decision, which can change if the receiving domain adjusts it. Do not conflate this with 4.4.1, where the same X.4.1 pattern is status context as a class-4, retryable condition describing an unanswered connection.","Operational recommendation: stop automatic and manual retries of the same message to this address in the unchanged context. A new send makes sense only after a relevant condition has demonstrably changed — the receiving domain adjusting its filter, or its administrator confirming the recipient-access policy no longer blocks the address — not merely after time has passed.","Operational recommendation: do not add the address to a suppression list from a single 5.4.1 alone. Inspect the full response text and the system that returned it: a destination-domain filter or a recipient-access policy decision may be reversible by the recipient's administrator and is not the same as a permanently invalid address. Suppress only once the applicable list policy, or an independent permanent signal, justifies it.","[""The receiving domain has its own mail filters configured to block this specific message, independent of the sender's own reputation — documented Zoho behavior for domains hosted with this provider."",""The receiving system's recipient-address access policy denies delivery to this specific address, reported inside a non-delivery report rather than a live SMTP reply — documented Microsoft 365 / Exchange Online Protection behavior.""]","[""Correlate the response with the specific message, attempt time, and recipient address or domain; retain the full response text, including any bracketed server or message identifiers the provider includes."",""Stop unchanged automated retries; before any new send, confirm with the recipient or their administrator that the underlying filter, policy, or address issue has actually changed.""]","{""sender_admin"":[""Operational recommendation: stop automatic and manual retries of the same message to this address in the unchanged context. A new send makes sense only after a relevant condition has demonstrably changed — the receiving domain adjusting its filter, or its administrator confirming the recipient-access policy no longer blocks the address — not merely after time has passed.""],""recipient_admin"":[""If you administer the receiving domain, check the domain's own mail-filter or recipient-access policy (Zoho: domain-level filters; Microsoft 365 / Exchange Online Protection: recipient-address access policy) for the rule blocking this sender or address."",""Adjust the filter, allow-list the sender, or confirm the recipient address is correct and active, then tell the sender what changed so they can decide whether to resend.""],""provider"":[""If you operate the receiving mail platform, confirm which layer produced the 5.4.1 response (a domain-level content/recipient filter vs. a security or access policy) and that the digits reflect a genuine permanent destination-side refusal, not a transient issue mis-coded as permanent.""]}","[""4.4.1"",""5.4.3""]","esc-5-4-1","permanent","policy_block","unverified","do_not_retry","no_recommendation","medium","true"55"email-error-5-4-3","5.4.3","X.4.3","5-4-3","https://blazalek.com/en/email-errors/5-4-3","network-dns-routing","permanent_failure","do_not_retry","check_context","[""sender_admin"",""recipient_admin"",""provider""]","5.4.3 — Directory server failure","The network system could not forward the message because a directory server was unavailable. Inability to connect to an Internet DNS server is one standards example, but the code alone does not establish that the problem involved DNS. Class 5 makes this a permanent result, so do not retry in the unchanged context.","Mail could not be forwarded because a directory server (often DNS) was unavailable, and the hop treated it as permanent. That blocks deliverability until DNS or path config is fixed. Permanent: do not retry in the unchanged context.","Forwarding halted when a required directory server was unreachable: code 5.4.3 records that condition once status-code list pattern X.4.3 meets class 5. Internet DNS connectivity failure is a standards example, but the subcode does not identify which directory service failed. The status concerns infrastructure lookup availability on the forwarding path, not the validity of the recipient address.","Directory server failure defines X.4.3: the network system was unable to forward the message because a directory server was unavailable. The standard identifies inability to connect to an Internet DNS server as one example and describes this detail as useful only for a persistent transient failure. The status-code list nevertheless also confirms a concrete class-5 variant; under the class-alignment rule, code 5.4.3 has a permanent result.","The leading digit 5 denotes a permanent failure for this message in the current context. This does not mean that directory-service unavailability can never clear, but the response does not justify repeating the same unchanged attempt. The code alone identifies neither the particular service nor the party responsible for its unavailability.","Operational recommendation: stop automatic and manual retries of the same message in the unchanged context. Consider a new send only after a relevant condition has demonstrably changed, such as restoration of the required directory service or connectivity path, after checking suppression again and using idempotency; do not treat elapsed time alone as a sufficient change.","Operational recommendation: do not add the address to a suppression list based on 5.4.3 alone. Inspect the full response, the system returning the code, delivery history, and other permanent signals; suppress only when a separate recipient-specific signal or the applicable policy justifies it.","[""A directory server required to forward the message was unavailable to the network system handling the attempt."",""The network system could not connect to an Internet DNS server; the standard gives this as one example of directory server failure.""]","[""Correlate the response with the intended message, attempt time, and system that returned it; use available logs to determine whether forwarding stopped while accessing a directory service."",""Check the availability and connectivity of the actual directory service used in this flow; if it is Internet DNS, confirm its reachability for the specified time without assuming from the code alone that DNS was the cause."",""Stop unchanged retries and, before any new send, confirm that the relevant condition was repaired and check suppression state again.""]","{""sender_admin"":[""Stop retries of the same message in the unchanged context, retain the full response and attempt data, and determine which system returned 5.4.3."",""Give the context to the appropriate administrator or provider; permit a new send only after a relevant condition has demonstrably changed and suppression has been checked again.""],""recipient_admin"":[""If the code originated in a system you manage, inspect the availability of the directory service required to forward the message and its connectivity at the failed-attempt time."",""Restore the confirmed unavailable service or path and tell the sender what changed so they can decide on a new send instead of repeating the unchanged attempt.""],""provider"":[""If you operate a mail, directory, or network system involved in the attempt, inspect service and connectivity logs for the specified time; do not attribute the problem to DNS from the code alone."",""Restore the confirmed service or path, and preserve the exact status code in the response so the sender does not treat a permanent result as an instruction to retry unchanged.""]}","[""4.4.3"",""4.4.1"",""4.4.2"",""4.4.5""]","esc-5-4-3","permanent","infrastructure","unverified","retry_after_correction","no_recommendation","high","false"56"email-error-5-4-6","5.4.6","X.4.6","5-4-6","https://blazalek.com/en/email-errors/5-4-6","network-dns-routing","permanent_failure","do_not_retry","check_context","[""sender"",""recipient"",""recipient_admin""]","5.4.6 — Recipient or domain quota exceeded on a hosted mailbox platform (Titan)","The receiving system reports a permanent rejection at RCPT TO using the enhanced code 5.4.6 when either a specific recipient mailbox has exceeded its own storage/rate quota, or the receiving domain as a whole has hit its hosting plan's hourly or daily incoming-mail quota. This catalog's context for the pattern comes entirely from Titan Email and does not describe a routing loop, the meaning SMTP specification assigns to this pattern.","In production, 5.4.6 is a permanent over-quota rejection: one recipient mailbox's own limit, or the whole receiving domain's hosting-plan limit (hourly or daily) — not a routing loop, despite the pattern's name. Do not retry unchanged; wait out the window for a domain limit, or for confirmation for a mailbox limit.","Code 5.4.6 places status-code list pattern X.4.6 in class 5. SMTP specification supplies X.4.6 with the sample text ""Routing loop detected"" and frames it as useful only as a persistent transient error, yet the enhanced status-code status-code list records ""Not given"" for this pattern's Associated Basic Status Code. Neither class 4 nor class 5 has a mechanically confirmed basic code here, so this catalog's enhanced status-code status-code list mirror marks X.4.6 unresolved for that reason.","Because the enhanced status-code status-code list's Associated Basic Status Code field for X.4.6 reads ""Not given"", this catalog's status-code list mirror leaves the pattern's class applicability unresolved for both class 4 and class 5. Under SMTP specification, the X.4.6 pattern means a routing loop: a message forwarded too many times because of incorrect routing tables or a user-forwarding loop, and it is described as useful only as a persistent transient failure. Unlike patterns such as X.2.2 or X.4.1 in this catalog, where at least one class carries a mechanically confirmed basic code, X.4.6 confirms none.","The leading digit 5 denotes a permanent failure for this message in the current context: do not repeat the exact same send unchanged. In the context collected here, the underlying condition is a quota — a personal mailbox allocation or a domain-wide hourly/daily incoming-mail limit — that can and does change over time, so ""permanent"" describes this specific attempt, not a durable statement about the address or the domain. Do not read the class-5 digit as a signal that the recipient address itself is invalid, and do not conflate this code with an actual routing loop, since neither the enhanced status-code status-code list nor SMTP specification's own worked example is confirmed for this class here.","Operational recommendation: stop identical, tightly-spaced automated retries of the same message.","Suppress only once an independent, unambiguous permanent signal (such as an actual 5.1.1 or 5.2.1 response) appears, or when the applicable list policy otherwise justifies it.","[""The receiving system reports a permanent rejection at RCPT TO using the enhanced code 5.4.6 when either a specific recipient mailbox has exceeded its own storage/rate quota, or the receiving domain as a whole has hit its hosting plan's hourly or daily incoming-mail quota. This catalog's context for the pattern comes entirely from Titan Email and does not describe a routing loop, the meaning SMTP specification assigns to this pattern.""]","[""Correlate the rejection with the recipient count and send volume to that domain over the preceding hour and day; a burst pattern immediately before the rejection points to the domain-wide throttle rather than one mailbox's own storage limit."",""If the pattern recurs, consult Titan's own support documentation on sending/receiving limits (linked below), or ask the domain administrator to check the account's plan tier and current usage before the next attempt.""]","{""sender"":[""Stop identical automated retries; if this looks like the domain-wide hourly/daily throttle, wait for the corresponding window to roll over before resending, rather than retrying on a short fixed schedule."",""If the code persists across multiple windows, reach the recipient through another channel and share the exact response text, since it is the only signal that distinguishes a personal mailbox quota from a domain-wide one.""],""recipient"":[""If the response names your own mailbox quota, free up space or ask your domain administrator to raise your personal allocation on the hosting plan.""],""recipient_admin"":[""Raise the plan tier or the specific mailbox's quota if the domain is business-critical and the throttle recurs; confirm with the sender once the change is in place.""]}","[""4.4.6"",""5.4.1"",""5.4.3"",""5.4.7""]","esc-5-4-6","permanent","infrastructure","unverified","retry_after_correction","no_recommendation","medium","true"57"email-error-5-4-7","5.4.7","X.4.7","5-4-7","https://blazalek.com/en/email-errors/5-4-7","network-dns-routing","permanent_failure","do_not_retry","check_context","[""sender"",""recipient_admin"",""provider""]","5.4.7 — Recipient domain's inbound rate quota exceeded (Titan Email)","The receiving system reports that the recipient's domain has exceeded an administrative rate quota for accepting mail (hourly or daily) and is temporarily rejecting further messages. The code belongs to the permanent class: treat this specific delivery attempt as failed, and treat a later send as a new attempt once the limiting window clears, not as an automatic retry.","The recipient domain, hosted on Titan Email, has exceeded its own rate quota for accepting mail (hourly or daily) and rejects this message with a permanent-class code. Do not let your MTA auto-retry this same attempt; if the message matters, resend it after some time and consider reaching the recipient domain's administrator. Do not suppress the address based on 5.4.7 alone — the signal is about the whole domain's quota, not this particular address's validity.","Code 5.4.7 pins a permanent class onto status-code list pattern X.4.7, but X.4.7 itself stays unresolved for every class in this catalog.","That uses code number 5.4.7 for a rate-quota condition, not for the delivery-time expiry named in the status-code list's sample text. SMTP specification confirms that the Associated Basic Status Code list is illustrative rather than exclusive, yet it adds no further class confirmation here. In this catalog the status-code list mirror marks X.4.7 unresolved for every class: no confirmed entry exists, matching the evidentiary gap for other unconfirmed detail codes in this catalog.","This does not mean the recipient domain is blocked outright — the limit is tied to a time window (hour or day) and may clear once that window resets. Treat this specific attempt as failed, and a later send to this domain as a new attempt, not as an automatic retry of the same SMTP transaction.","Do not let your MTA auto-retry this same delivery attempt at short intervals — the class-5 code signals a permanent rejection of this transaction. If the message matters, consider a manual resend after a reasonable interval (longer than the typical hourly or daily window, depending on which variant occurred), treating it as a new delivery attempt. Do not treat a single 5.4.7 as grounds to give up on this domain permanently.","Do not suppress the recipient address based on code 5.4.7 alone: the condition is a rate quota on the recipient domain's mail acceptance as a whole, hosted on Titan Email, not the validity of this particular address or the state of one mailbox. Suppression decisions should follow independent, address-specific signals (hard bounces, addressing codes) rather than this shared, domain-level limit.","[""The recipient domain, hosted on Titan Email, is on a plan with a cap on the number of messages it accepts within an hourly or daily window, and current inbound volume (from this and other senders combined) has exceeded that cap."",""A sudden spike in mail sent to this domain in a short period (a campaign, a mailing list, or many senders at once) exhausted the available quota faster than usual.""]","[""Correlate the response with the specific message, recipient address, and exact attempt time — needed to judge when the relevant window (hour or day) might have reset."",""If you send to multiple recipients on the same Titan-hosted domain, check whether similar 5.4.7 rejections occur for other addresses in the same time window — a sign of a domain-wide limit rather than a single address's problem."",""Where possible, contact the recipient domain's administrator (or ask the recipient to do so) about the domain's current Titan Email plan and rate quota.""]","{""sender"":[""Do not configure automatic retries of this same attempt at short intervals; if the message matters, resend it after a reasonable interval as a new delivery attempt."",""If 5.4.7 rejections to this domain recur, give your sending administrator the full response text, the attempt time, and whether it names the hourly or daily variant.""],""recipient_admin"":[""Check the Titan Email control panel for the domain's current plan and inbound rate quota, and whether the hourly or daily limit is being regularly exhausted."",""If the domain routinely needs a higher volume of inbound mail, consider a Titan Email plan change or contact their support about raising the quota.""],""provider"":[""If you operate the recipient domain's mail hosting (Titan Email or a reseller of it), confirm the current inbound rate quota for this plan and notify the customer when usage nears the limit within a given window."",""Give the customer a clear path to check current quota usage and raise it before 5.4.7 rejections start affecting business-critical correspondence.""]}","[""5.4.1"",""5.4.3"",""5.4.6""]","esc-5-4-7","permanent","infrastructure","unverified","do_not_retry","no_recommendation","medium","true"58"email-error-5-5-0","5.5.0","X.5.0","5-5-0","https://blazalek.com/en/email-errors/5-5-0","delivery-protocol","permanent_failure","do_not_retry","check_context","[""sender_admin"",""provider""]","5.5.0 — Other or undefined permanent protocol status","A permanent problem occurred with the protocol needed to pass the message to the next system, but no more specific code described it adequately. Do not retry the unchanged send.","A permanent SMTP protocol error occurred with no more specific subcode. Usually points to client or relay misconfiguration rather than recipient list quality. Permanent: do not retry unchanged; fix the protocol exchange before resending to protect deliverability.","As a catch-all for permanent protocol problems during handoff to the next system, code 5.5.0 applies status-code list pattern X.5.0 when no finer detail code fits. The first digit places the result in class 5. The status does not name the affected command, session stage, or root cause, and it does not establish the recipient address is bad. Diagnosis needs the full SMTP response, trace, and returning system context.","Something was wrong with the protocol needed to deliver the message to the next hop, and no other available detail code can express that condition adequately: that is X.5.0. In the concrete 5.5.0 code, the leading digit assigns the result to permanent class 5.","The leading digit 5 denotes a permanent failure of the current attempt. This is a general code: by itself it identifies neither a particular command, stage, nor cause of the protocol problem, and it does not establish that the recipient address is invalid.","Operational guidance: stop automatic and manual retries of the same unchanged send. Consider a new send only after establishing the cause from the full context and confirming a relevant change in the condition, configuration, or handling.","Operational guidance: do not apply automatic suppression based on code 5.5.0 alone. Inspect the full response, stage, system returning the code, delivery history, and other permanent signals, then decide according to the established cause and applicable policy.","[""A permanent problem occurred with the protocol required to pass the message to the next system, and the reporting system could not describe it with a more specific available code.""]","[""Correlate the response with the intended message, attempt time, SMTP stage or DSN context, and next system on the path; retain the full response and available logs because the code itself is general."",""Use the retained context to determine whether a more specific protocol status or a confirmed provider-specific condition describes the problem; do not assign a cause from 5.5.0 alone."",""Stop unchanged retries; before any new send, confirm a relevant change and check suppression state again.""]","{""sender_admin"":[""Stop retries of the unchanged send and retain the full response, time, stage, and next system for diagnosis."",""Give the collected context to the provider if the cause remains unclear; permit a new send only after a relevant change has been confirmed and suppression has been checked again.""],""provider"":[""If you operate a system involved in the handoff, inspect logs and the available protocol trace for the specified time, stage, and next system; do not derive a specific cause from the code alone."",""Correct the confirmed problem in the managed layer and preserve the exact class and response context; if a more specific protocol status is known, return it instead of general code 5.5.0.""]}","[""2.5.0"",""4.5.0"",""5.5.1"",""5.5.2""]","esc-5-5-0","permanent","infrastructure","unverified","do_not_retry","no_recommendation","low","true"59"email-error-5-5-1","5.5.1","X.5.1","5-5-1","https://blazalek.com/en/email-errors/5-5-1","delivery-protocol","permanent_failure","do_not_retry","check_context","[""sender_admin"",""provider""]","5.5.1 — Invalid protocol command","A mail system permanently rejected a protocol command because it was issued out of sequence or was unsupported. Do not retry the same unchanged attempt.","The mail system permanently rejected an SMTP command issued out of sequence or unsupported by the peer. Fix client or middleware behavior: protocol errors can trigger provider throttling and hurt reputation. Permanent: do not retry the same unchanged attempt.","Mail-transaction commands issued out of order for the current state, or unsupported by the peer, land under status-code list pattern X.5.1 as code 5.5.1. The enhanced status places this attempt in permanent class 5. The status alone does not show which command failed, whether ordering or support was the issue, or which side owns the defect. Parse the transaction trace and the system's advertised capabilities before assigning cause.","Out-of-sequence or unsupported mail transaction protocol commands are what X.5.1 covers. The status-code list description says this detail is useful only as a permanent error, and the concrete 5.5.1 variant carries the matching class 5.","The leading digit 5 denotes a permanent failure for this message in the current context. The code alone does not determine whether the command was out of sequence or unsupported, or which side has the implementation or configuration defect.","Operational recommendation: stop automatic and manual retries of the same attempt in the unchanged context. Consider a new send only after command ordering has demonstrably been corrected, the unsupported command has been removed, or system support has changed; first check suppression again and use idempotency.","Operational recommendation: do not add the address to a suppression list based on 5.5.1 alone because the code describes a protocol problem, not mailbox status. Inspect the full response, transaction trace, other permanent events, and the applicable policy before suppressing.","[""A mail transaction protocol command was issued out of sequence for the current transaction state."",""The system that returned the code did not support the issued protocol command.""]","[""Correlate the response with the intended message, attempt time, system that returned the code, and exact command; retain the transaction trace preceding that command."",""Use the trace, logs, and advertised system capabilities to determine whether the command was out of sequence or unsupported; do not choose a cause from the code alone."",""Stop unchanged retries; before any new send, confirm a relevant correction and check suppression state again.""]","{""sender_admin"":[""Retain the full response, exact command, and preceding transaction trace, then correct any confirmed ordering defect or use of an unsupported command."",""Stop retries in the unchanged context; permit a new send only after a confirmed correction and another suppression check.""],""provider"":[""For the specified time and system, inspect logs, transaction state, and supported commands to distinguish an ordering error from lack of support."",""Correct any confirmed defect in the managed implementation, or tell the sender administrator the required sequence and supported command set while preserving the exact status code in the response.""]}","[""4.5.1"",""5.5.0"",""5.5.2"",""5.5.4""]","esc-5-5-1","permanent","infrastructure","unverified","retry_after_correction","no_recommendation","high","false"60"email-error-5-5-2","5.5.2","X.5.2","5-5-2","https://blazalek.com/en/email-errors/5-5-2","delivery-protocol","permanent_failure","do_not_retry","check_context","[""sender_admin"",""provider""]","5.5.2 — Protocol command syntax error","A mail system permanently rejected a mail transaction protocol command because it could not interpret it: the syntax was wrong or the command was unrecognized. Do not retry the same unchanged attempt.","The server could not parse an SMTP command because syntax was wrong or the command was unrecognized. Correct the sending client's command formatting before any resend. Permanent failure: unchanged retries add noise without improving deliverability.","Whenever the receiving host rejects a mail-transaction command as unparseable, status-code list pattern X.5.2 appears as code 5.5.2: either the line syntax is malformed or the verb is unknown to that peer. Permanent class 5 is what the enhanced status register records for this attempt. The status detail does not name the exact command line, distinguish syntax failure from unsupported verbs, or locate the defect on client versus server side. Narrowing cause requires the full SMTP reply and the transaction trace preceding the rejected command.","A mail transaction protocol command that could not be interpreted because its syntax was wrong or the command was unrecognized is X.5.2. The status-code list description says this detail is useful only as a permanent error, and the concrete 5.5.2 variant carries the corresponding class 5.","The leading digit 5 denotes a permanent failure for this message in the current context. The code alone identifies neither the exact command nor its faulty part, does not determine whether the cause was invalid syntax or an unrecognized command, and does not establish which side has the problem.","Operational recommendation: stop automatic and manual retries of the same command in the unchanged context. Consider a new send only after the syntax has demonstrably been corrected, the unrecognized command has been removed or replaced, or its handling has demonstrably changed; first check suppression again and use idempotency.","Operational recommendation: do not add the address to a suppression list based on 5.5.2 alone because the code describes a protocol-command interpretation problem, not mailbox status. Inspect the full response, transaction trace, other permanent events, and the applicable policy before suppressing.","[""A mail transaction protocol command had invalid syntax."",""The system that returned the code did not recognize the issued protocol command.""]","[""Correlate the response with the intended message, attempt time, system that returned the code, and exact command; also retain the preceding transaction trace."",""Compare the command with the applicable protocol syntax and inspect available logs to determine whether it was malformed or unrecognized; do not choose a cause from the code alone."",""Stop unchanged retries; before any new send, confirm a relevant correction or handling change and check suppression state again.""]","{""sender_admin"":[""Retain the full response, exact command, and preceding transaction trace, then correct any confirmed syntax defect or remove or replace the unrecognized command."",""Stop retries in the unchanged context; permit a new send only after a correction or handling change has been confirmed and suppression has been checked again.""],""provider"":[""For the specified time and system, inspect logs, the protocol parser, and the transaction trace to identify the exact command and distinguish invalid syntax from an unrecognized command."",""Correct any confirmed problem in the managed implementation, or tell the sender administrator the required syntax and recognized command set while preserving the exact status code in the response.""]}","[""5.5.0"",""5.5.1"",""5.5.4"",""5.5.6""]","esc-5-5-2","permanent","infrastructure","unverified","retry_after_correction","no_recommendation","high","false"61"email-error-5-5-4","5.5.4","X.5.4","5-5-4","https://blazalek.com/en/email-errors/5-5-4","delivery-protocol","permanent_failure","do_not_retry","check_context","[""sender_admin"",""provider""]","5.5.4 — Invalid command arguments","A mail system permanently rejected a valid protocol command because its arguments were invalid. Do not retry the same attempt without changing the arguments or conditions that caused the rejection.","A valid SMTP command was rejected because its arguments were invalid for this session. Adjust command parameters or session state: do not blindly retry. Permanent failure; fix configuration to avoid repeated protocol rejects that providers may treat as abusive.","Rejected arguments on an otherwise syntactically valid mail-transaction command yield code 5.5.4 under pattern X.5.4: the arguments were out of acceptable range or named an unrecognized feature. Permanent refusal for this message is what class 5 denotes. The code does not expose the command name, offending argument, or whether range or feature mismatch triggered the reply, and it does not invalidate the recipient address.","Invalid arguments on an otherwise valid mail transaction protocol command define X.5.4: the arguments were out of range or represented unrecognized features. The T0 status-code list says this detail is useful only as a permanent error, and the concrete 5.5.4 code has the corresponding class 5.","The leading digit 5 denotes a permanent failure for the current message in this context. The code alone identifies neither the exact command nor argument, does not distinguish an out-of-range value from an unrecognized feature, and does not establish that the recipient address is invalid.","Operational recommendation: stop automatic and manual retries of the same unchanged attempt. Consider a new send only after the argument or feature compatibility has demonstrably been corrected, or the relevant configuration has materially changed; first check suppression state again and use idempotency.","Operational recommendation: do not add the address to a suppression list based on 5.5.4 alone because the code describes a protocol-command argument, not mailbox status. Inspect the full response, command, arguments, system returning the code, and other permanent events, then suppress only according to the established cause and applicable policy.","[""An argument to a valid mail transaction protocol command was outside the range accepted by the system that returned the code."",""An argument to a valid command represented a feature that the system returning the code did not recognize.""]","[""Correlate the response with the intended message, attempt time, system that returned the code, and exact command and arguments; also retain the transaction state before the command."",""Use the trace, logs, and documented system capabilities to determine whether an argument was out of range or represented an unrecognized feature."",""Stop unchanged retries; before any new send, confirm that the established cause has been corrected and check suppression state again.""]","{""sender_admin"":[""Retain the full response, command, exact arguments, and preceding transaction trace, then correct the confirmed out-of-range argument or use of an unrecognized feature."",""Stop retries in the unchanged context; permit a new send only after a confirmed correction and another suppression check.""],""provider"":[""For the specified time and system, inspect logs, argument constraints, and supported features to establish which argument was rejected and why."",""Correct any confirmed defect in the managed implementation, or give the sender administrator the accepted range or supported feature needed for correction; preserve the exact code and response context.""]}","[""4.5.4"",""5.5.0"",""5.5.1"",""5.5.2""]","esc-5-5-4","permanent","infrastructure","unverified","retry_after_correction","no_recommendation","high","false"62"email-error-5-5-6","5.5.6","X.5.6","5-5-6","https://blazalek.com/en/email-errors/5-5-6","delivery-protocol","permanent_failure","do_not_retry","check_context","[""sender_admin"",""provider""]","5.5.6 — Authentication exchange line is too long","Do not retry the same unchanged attempt.","SMTP authentication failed permanently because the client's SASL response exceeded the server's buffer for that mechanism. Shorten credentials or switch mechanisms: do not retry unchanged. Permanent; misconfigured auth loops waste sends without deliverability gain.","AUTH exchanges fail under code 5.5.6 when pattern X.5.6 applies: the client's BASE64 response exceeds the buffer limit for the active SASL mechanism. The first digit classifies the outcome as permanent class 5. The status reports size rejection only; it does not explain why the payload grew that long, which mechanism limits apply, or whether client formatting or server buffer policy must change.","AUTH failed because the client's [BASE64] response exceeded the maximum buffer size available for the currently selected SASL mechanism: that is X.5.6. The status-code list description says this detail is useful for both permanent and persistent transient errors; this record concerns the concrete permanent class-5 variant 5.5.6.","The leading digit 5 denotes a permanent failure of the current attempt. The code alone does not explain why the client response has that length or establish whether the client, configuration, or server-side handling needs correction.","Operational recommendation: stop automatic and manual retries of the unchanged AUTH attempt. Consider a new attempt only after confirming that the client response fits the buffer for the selected SASL mechanism or that the relevant server-side handling has genuinely changed; check suppression state again before the attempt.","Operational recommendation: do not add the recipient address to a suppression list based on 5.5.6 alone because the code describes an AUTH exchange, not mailbox status. Inspect the full response context, authentication stage, system returning the code, event history, and applicable policy before deciding on suppression.","[""During the AUTH exchange, the client sent a [BASE64] response longer than the maximum buffer available for the currently selected SASL mechanism.""]","[""Correlate the response with the intended attempt, time, client, and selected SASL mechanism; retain the code, stage, and safe diagnostic metadata without storing authentication material."",""Use logs and configuration to compare the client-response length with the maximum buffer available for the selected mechanism; do not assign the precise reason for the excess length from the code alone."",""Stop unchanged retries; before a new attempt, confirm that the excess has been removed or handling has genuinely changed, then check suppression state again.""]","{""sender_admin"":[""Retain the full code, time, AUTH stage, selected SASL mechanism, and response length without storing its sensitive contents, then inspect how the client constructs the response."",""Stop unchanged retries and correct the confirmed cause of the oversized response; permit a new attempt only after checking it against the limit and reassessing suppression.""],""provider"":[""For the specified time and system, inspect AUTH logs, the selected SASL mechanism, and the available buffer limit to confirm where and why the rejection occurred without exposing authentication material."",""Correct any confirmed problem in the managed configuration or implementation, or give the sender administrator safe information about the applicable constraint; preserve the exact code and response context.""]}","[""5.5.0"",""5.5.1"",""5.5.2"",""5.5.4""]","esc-5-5-6","permanent","authentication_failure","unverified","retry_after_correction","no_recommendation","high","false"63"email-error-5-6-3","5.6.3","X.6.3","5-6-3","https://blazalek.com/en/email-errors/5-6-3","message-content-format","permanent_failure","do_not_retry","check_context","[""sender"",""sender_admin"",""provider""]","5.6.3 — Required conversion is not supported","The message failed permanently because forwarding it required a content conversion that a host in the path could not practically perform. Do not retry the same unchanged attempt.","Forwarding required a content conversion the path could not perform, so delivery failed permanently. Change message format or routing to match downstream capabilities. Permanent: do not retry unchanged; format mismatches are not list-hygiene issues.","A host on the forwarding path needed to convert content for a downstream hop but could not do so practically; code 5.6.3 records that condition under status-code list pattern X.6.3 within enhanced status class 5. The leading digit marks a permanent outcome in the SMTP enhanced status register; this detail describes a format or transport capability gap, not mailbox existence. The code alone does not identify which hop refused conversion or whether the fix is format change, routing change, or gateway configuration.","Forwarding that requires a content conversion the path cannot perform, or that is not practical, is the X.6.3 condition the standard describes. Code 5.6.3 applies this detail in class 5; the enhanced status-code status-code list associates the pattern with basic status 554 as well.","The leading digit 5 denotes a permanent failure for this message in the current context. The code identifies a conversion problem in the forwarding path, but it does not by itself identify the specific host or establish that the recipient address is invalid.","Operational guidance: stop automatic and manual retries of the same unchanged attempt. Consider a new send only after a confirm diagnostic change, such as to the message format, transport path, or conversion capability; reassess suppression before sending it.","Operational guidance: do not add the address or domain to a suppression list based on 5.6.3 alone. Inspect the complete response, forwarding path, results for this recipient, and the applicable policy because the code may describe a conversion problem unrelated to address validity.","[""A host in the forwarding path must convert the message content for the next hop, but that conversion is impossible or impractical."",""One possible case is an ESMTP gateway that supports 8-bit transport but cannot transform the message into the 7-bit form required by the next hop.""]","[""Correlate the response with the intended message, attempt time, and forwarding path; retain the complete text and available logs to identify the host that returned the code when the context permits."",""Compare the message's format and transport requirements with the capabilities of that host and the next hop. Check whether 8-bit-to-7-bit conversion was required, but do not assume that cause from the code alone."",""Stop unchanged retries; before a controlled new send, confirm a material correction and reassess the suppression decision.""]","{""sender"":[""Do not resend the same unchanged message; give the administrator the complete report and attempt context."",""Prepare a corrected version only when diagnosis identifies a necessary format or transport change; do not treat this code alone as confirmation that the address is invalid.""],""sender_admin"":[""After confirming the cause, change the format, route, or conversion capability in managed infrastructure, or coordinate the correction with the provider; confirm it before a new attempt and reassess suppression.""],""provider"":[""If a managed host returned the code, inspect its logs, conversion capabilities, and the next hop's requirements for the specified attempt."",""Correct a confirmed conversion or configuration problem, or give the administrator the exact unsupported requirement; preserve the code and complete response without automatically suppressing the recipient.""]}","[""5.6.6"",""5.6.7"",""5.6.8"",""5.6.9""]","esc-5-6-3","permanent","content_block","unverified","retry_after_correction","no_recommendation","high","false"64"email-error-5-6-6","5.6.6","X.6.6","5-6-6","https://blazalek.com/en/email-errors/5-6-6","message-content-format","permanent_failure","do_not_retry","check_context","[""sender"",""sender_admin"",""provider""]","5.6.6 — Message content is not available","The attempt failed permanently because the message content could not be fetched from a remote system. Do not retry the same unchanged attempt.","Delivery failed permanently because message content could not be fetched from a remote system in the path. Resolve upstream availability or routing before resending. Permanent: unchanged retries will fail and add failed-delivery noise without reputation benefit.","Remote content needed for further processing could not be retrieved along the delivery path, and code 5.6.6 reports that under status-code list pattern X.6.6. The enhanced status register places this attempt in permanent class 5. The detail names a remote retrieval failure, does not establish that the recipient mailbox is missing or unreachable. Identifying the remote system, fetch stage, and access barrier still depends on the full SMTP response text and session logs rather than on the numeric code alone.","Message content that could not be fetched from a remote system is what X.6.6 covers. The status-code list notes the detail can cover a permanent or persistent transient error; code 5.6.6 applies it in class 5 and is associated with basic status 554.","The leading digit 5 denotes a permanent failure for this message in the current context. The code alone does not identify the remote system, stage, or cause of the failed retrieval, and it does not establish that the recipient address is invalid.","Operational recommendation: stop automatic and manual retries of the same unchanged attempt. Consider a new send only after confirming a material change that restores access to the content or removes the diagnosed retrieval problem; reassess suppression before sending.","Operational recommendation: do not add the address or domain to a suppression list based on 5.6.6 alone. Inspect the complete response, results for this recipient, event history, and applicable policy because the code describes unavailable content, not mailbox status.","[""The message content required for further processing could not be fetched from a remote system.""]","[""Correlate the response with the intended message, recipient, time, and attempt stage; retain the complete text and available identifiers and logs."",""Use the logs to determine which system fetched the content and from where, then check content availability and the exact retrieval failure; do not assume a specific cause from the code alone."",""Stop unchanged retries; before a controlled new send, confirm a material correction and reassess the suppression decision.""]","{""sender"":[""Do not resend the same unchanged message; give the administrator the complete report and attempt context."",""Prepare a new send only after confirming that the content is available or that the diagnosed retrieval problem has been removed.""],""sender_admin"":[""Correct the confirmed problem in the managed available information or retrieval path, or coordinate the correction with the provider; confirm the change before a new send and reassess suppression.""],""provider"":[""For the specified attempt, inspect the managed system's logs and confirm the available information from which content was to be fetched and where retrieval failed."",""Correct a confirmed problem in the managed service, or give the sender administrator exact, safe error context; preserve the code and complete response without automatically suppressing the recipient.""]}","[""5.6.3"",""5.6.7"",""5.6.8"",""5.6.9""]","esc-5-6-6","permanent","infrastructure","unverified","retry_after_correction","no_recommendation","medium","true"65"email-error-5-6-7","5.6.7","X.6.7","5-6-7","https://blazalek.com/en/email-errors/5-6-7","message-content-format","permanent_failure","do_not_retry","check_context","[""sender"",""sender_admin"",""provider""]","5.6.7 — Non-ASCII address is not permitted for the sender or recipient","A system permanently rejected a MAIL or RCPT command because the sender or recipient address contained non-ASCII characters that were not permitted in that context. Do not retry the same unchanged attempt.","MAIL or RCPT was permanently rejected because a sender or recipient address used disallowed non-ASCII characters. Use SMTPUTF8 or ASCII-compatible addresses: internationalization misconfig blocks delivery. Permanent: do not retry unchanged; fix addressing for deliverability.","Non-ASCII characters in a sender or recipient address on MAIL or RCPT can trigger code 5.6.7 when the receiving context refuses them under status-code list pattern X.6.7. The leading digit places the result in permanent class 5 of the enhanced status taxonomy. This detail concerns internationalized address handling limits, not context that a mailbox is absent. The code alone does not say whether rejection hit MAIL or RCPT, which address triggered it, or whether SMTPUTF8 negotiation was attempted.","While receiving a MAIL or RCPT command, a system determined that a non-ASCII address was not permitted for the relevant sender or recipient: that is X.6.7. Code 5.6.7 applies this detail in class 5; the enhanced status-code status-code list associates the pattern with basic statuses 553 and 550.","The leading digit 5 denotes a permanent failure of the current attempt. The code identifies a restriction involving a non-ASCII address, but it does not establish that the mailbox does not exist or establish whether the address, system configuration, or policy caused the rejection.","Operational guidance: stop automatic and manual retries of the same unchanged attempt. Consider a new send only after a confirm address correction or a change to non-ASCII address handling on the relevant path; reassess suppression before sending.","Operational guidance: do not automatically add the address or domain to a suppression list based on 5.6.7 alone. First determine whether the failure occurred at MAIL or RCPT, which address it concerned, and whether the restriction was specific to the attempt, route, or policy; then apply the appropriate suppression rule.","[""The MAIL command contained a sender address with non-ASCII characters that the receiving system did not permit in that context."",""The RCPT command contained a recipient address with non-ASCII characters that the receiving system did not permit in that context."",""The system or route used for the attempt did not permit the required non-ASCII address handling because of configuration or policy.""]","[""Correlate the response with the intended attempt and determine whether rejection occurred at MAIL or RCPT and whether it concerned the sender or recipient address; retain the complete text and safe metadata without exposing the address."",""Inspect the address form and the configuration, capabilities, and policy of systems on the relevant path to confirm why non-ASCII characters were not permitted; do not assign the cause from the code alone."",""Stop unchanged retries; before a controlled new send, confirm a material correction and reassess suppression.""]","{""sender"":[""Do not resend the same unchanged message; give the administrator the complete report and attempt context."",""Check the intended sender and recipient addresses, but use a different form or confirm alternative address only after diagnosis; do not automatically treat the mailbox as nonexistent.""],""sender_admin"":[""After confirming the cause, correct the confirm address, configuration, or handling on the managed path, or coordinate a change with the provider; confirm the correction before a new send and reassess suppression.""],""provider"":[""For the specified attempt, inspect logs, the MAIL or RCPT stage, and the configuration and policy for non-ASCII address handling to confirm the exact rejection point."",""Remove a confirmed restriction in the managed service, or give the administrator the exact condition and safe diagnostic details; do not automatically suppress the recipient based on this code alone.""]}","[""5.6.3"",""5.6.6"",""5.6.8"",""5.6.9""]","esc-5-6-7","permanent","infrastructure","unverified","retry_after_correction","no_recommendation","high","true"66"email-error-5-6-8","5.6.8","X.6.8","5-6-8","https://blazalek.com/en/email-errors/5-6-8","message-content-format","permanent_failure","do_not_retry","check_context","[""sender"",""sender_admin"",""provider""]","5.6.8 — Required UTF-8 reply not permitted by the SMTP client","The attempt failed permanently because showing the mailbox name required a reply containing a UTF-8 string, but the SMTP client did not permit that form of reply. Do not retry the same unchanged attempt.","The server needed a UTF-8 mailbox string in the reply, but the SMTP client forbids that response form. Enable UTF-8 support or use ASCII addresses on the client side. Permanent failure: fix client capabilities before retrying to restore deliverability.","Displaying the mailbox name required an SMTP reply containing a UTF-8 string, yet the client on this session would not accept that reply form; status-code list pattern X.6.8 appears as code 5.6.8. The enhanced status result for the attempt is permanent under class 5. The status captures a client-server capability mismatch around UTF-8 replies, not context that the mailbox itself is invalid. Diagnosis must separate server reply requirements from client restrictions using session logs instead of inferring cause from the numeric code alone.","X.6.8 covers the case where showing the mailbox name requires a reply containing a UTF-8 string, but the SMTP client does not permit such a reply. Code 5.6.8 applies this detail in class 5.","The leading digit 5 denotes a permanent failure of the current attempt. The code identifies a conflict between the required reply form and an SMTP client restriction, but it does not establish that the mailbox does not exist or that the recipient address is invalid.","Operational guidance: stop automatic and manual retries of the same unchanged attempt. Consider a new attempt only after a confirm change to the client's handling of UTF-8 replies or another correction identified through diagnosis.","Operational guidance: do not automatically add the address or domain to a suppression list based on 5.6.8 alone. Inspect the complete response, client behavior, event history, and applicable policy, then make the suppression decision in that context.","[""Showing the mailbox name required a reply with a UTF-8 string that the SMTP client did not permit.""]","[""Correlate the response with the intended attempt and retain its complete text and available context to confirm that it concerns a mailbox name requiring a UTF-8 string."",""Inspect the SMTP client's configuration, UTF-8 reply handling, and available logs to identify the restriction; before a new attempt, confirm a material correction and reassess suppression.""]","{""sender"":[""Do not resend the same unchanged message; give the administrator the complete response and attempt context.""],""sender_admin"":[""Determine why the client did not permit the required UTF-8 reply, then correct its configuration or handling if diagnosis confirms that option."",""confirm the correction before a controlled new attempt and reassess suppression instead of treating the mailbox as invalid from this code alone.""],""provider"":[""For the specified attempt, inspect available logs and give the administrator exact, safe context for the UTF-8 reply restriction."",""Correct a confirmed problem in the managed service or identify the required client-side change; do not trigger automatic suppression from this code alone.""]}","[""2.6.8"",""5.6.3"",""5.6.6"",""5.6.7""]","esc-5-6-8","permanent","infrastructure","unverified","retry_after_correction","no_recommendation","high","true"67"email-error-5-6-9","5.6.9","X.6.9","5-6-9","https://blazalek.com/en/email-errors/5-6-9","message-content-format","permanent_failure","do_not_retry","check_context","[""sender"",""sender_admin"",""provider""]","5.6.9 — Message with a UTF-8 header cannot be transferred","The message was permanently rejected after its data had been transmitted because it could not be transferred with its UTF-8 header to one or more recipients. Do not retry the same unchanged attempt.","The message was rejected after DATA because its UTF-8 header could not be relayed to one or more recipients. Downgrade or re-encode headers, or use a UTF-8-capable path. Permanent: do not retry unchanged; header policy mismatches hurt delivery success rates.","After the final DATA dot, relay of a message whose headers use UTF-8 failed for at least one recipient; that is code 5.6.9 under status-code list detail X.6.9. The leading digit places the outcome in the permanent enhanced status class for this message. The pattern names a header transfer barrier on the delivery path, not by itself an invalid recipient address. It does not identify the affected recipients, the blocking system, or whether header re-encoding or a UTF-8-capable route is the right remedy.","A message with a UTF-8 header that cannot be transferred to one or more recipients must be rejected under X.6.9. The failure occurs after the final dot of the DATA command, as the standard defines. Code 5.6.9 applies this detail in class 5; the enhanced status-code status-code list associates the pattern with basic status 550.","The leading digit 5 denotes a permanent failure for this message in the current context. The code identifies a problem transferring a message with a UTF-8 header after DATA, but it does not by itself identify the affected recipient or system or explain the exact cause.","Operational guidance: stop automatic and manual retries of the same unchanged attempt. Consider a new send only after a confirm change to the message, configuration, or path removes the diagnosed transfer barrier; reassess suppression before sending.","Operational guidance: do not automatically add an address or domain to a suppression list based on 5.6.9 alone. Inspect the complete response and per-recipient results because the code concerns transfer of a message with a UTF-8 header and does not establish that an address is invalid.","[""A message with a UTF-8 header could not be transferred to one or more recipients, so the entire message had to be rejected after DATA completed.""]","[""Correlate the response with the intended message and attempt; confirm that the failure occurred after the final DATA dot, and identify the recipients covered by the event when the context permits."",""Inspect the message headers and available logs from systems on the path to determine the exact barrier to transferring the message with its UTF-8 header; do not assign a specific cause from the code alone."",""Stop unchanged retries; before a controlled new send, confirm a material correction and reassess suppression for each recipient.""]","{""sender"":[""Do not resend the same unchanged message; give the administrator the complete report and attempt context."",""Prepare a changed message or use a confirm alternative sending method only after diagnosis; do not automatically treat the recipient address as invalid.""],""sender_admin"":[""After confirming the cause, correct the message, configuration, or path in managed infrastructure, or coordinate the correction with the provider; confirm it before a new send and reassess suppression.""],""provider"":[""For the specified attempt, inspect managed-system logs after DATA completed and determine why the message with its UTF-8 header could not be transferred to the affected recipients."",""Correct a confirmed problem in the managed service, or give the administrator the exact safe diagnostic context; preserve the code and complete response without automatically suppressing the recipients.""]}","[""5.6.3"",""5.6.6"",""5.6.7"",""5.6.8""]","esc-5-6-9","permanent","content_block","unverified","retry_after_correction","no_recommendation","high","false"68"email-error-5-7-0","5.7.0","X.7.0","5-7-0","https://blazalek.com/en/email-errors/5-7-0","security-authentication-policy","permanent_failure","do_not_retry","check_context","[""sender"",""sender_admin"",""recipient_admin"",""provider""]","5.7.0 — Other or undefined permanent security status","The message was permanently rejected because of a security-related problem, but the response does not describe it more precisely. Do not retry the unchanged send.","A permanent catch-all for security-related rejections when the server gives no more specific X.7 detail. The cause must come from the full response, not the code alone. Repeated policy blocks can signal deliverability or reputation risk if misconfiguration persists. Do not retry the unchanged send.","Security-related conditions that no available X.7 subcode can name return under pattern X.7.0 as code 5.7.0 in the enhanced status register. Permanent class 5 attaches to this generic security detail for the attempt. The code may also appear when an applicable security policy limits how precisely the condition can be described. The numeric reply names a security-class refusal without identifying a particular mechanism, rule, or responsible party, and it does not establish that the recipient address is invalid.","Returning a message for a security-related condition that cannot be properly expressed by another available detail code is X.7.0. The code may also be used when an applicable security policy prevents the condition from being described more precisely. In the concrete 5.7.0 form, the leading digit assigns the result to permanent class 5.","The leading digit 5 denotes a permanent failure of the current attempt. The code alone identifies neither a particular security mechanism, policy rule, nor responsible party, and it does not establish that the recipient address is invalid.","Operational guidance: stop automatic and manual retries of the same unchanged send. Consider a new send only after establishing the cause from the full context and confirming a relevant change in the condition or configuration.","Operational guidance: do not automatically suppress the address based on general code 5.7.0 alone. Inspect the full response, security context, delivery history, and other permanent signals; make the suppression decision only according to the established cause and applicable policy.","[""A permanent security-related condition caused the message to be returned, but the reporting system could not describe it with a more specific available code."",""An applicable security policy may have prevented the system from disclosing a more precise description of the condition.""]","[""Correlate the response with the intended message, attempt time, transaction stage, and system that returned the code; retain the full response text and available security context because the code itself is general."",""Inspect available logs to determine whether the system recorded a more specific X.7.x condition or limited detail under its security policy; do not assign a specific cause from 5.7.0 alone."",""Stop unchanged retries; before any new send, confirm a relevant change and check suppression state again.""]","{""sender"":[""Confirm that the send was intended and that the recipient should still receive the message; give the sender administrator the attempt time and complete available context without manually retrying the unchanged send."",""Do not change credentials or security settings based on the code alone; follow only a confirmed administrator instruction.""],""sender_admin"":[""Give the collected context to the recipient administrator or provider if the cause remains unclear; permit a new send only after a relevant change has been confirmed and suppression has been checked again.""],""recipient_admin"":[""If the code came from a recipient system you manage, inspect its security and policy logs for the specified time and attempt to identify a more precise condition when policy permits disclosure."",""Correct the confirmed condition within your control if delivery should be allowed; otherwise provide the permitted context and, when safe, return a more specific status code.""],""provider"":[""If you operate a system involved in the attempt, inspect managed-service logs and the security rules applied at the specified time; do not assign a particular cause from the code alone."",""Correct the confirmed problem in the managed layer or preserve the intended policy rule; when policy permits, return a more specific X.7.x code instead of general 5.7.0.""]}","[""2.7.0"",""4.7.0"",""5.7.1"",""5.7.2""]","esc-5-7-0","permanent","policy_block","unverified","do_not_retry","no_recommendation","low","true"69"email-error-5-7-1","5.7.1","X.7.1","5-7-1","https://blazalek.com/en/email-errors/5-7-1","security-authentication-policy","permanent_failure","do_not_retry","check_context","[""sender"",""sender_admin"",""recipient_admin"",""provider""]","5.7.1 — Delivery not authorized, message refused","The system permanently refused the message because the sender was not authorized to send to the destination. Per-host or per-recipient filtering may produce this decision. Do not retry the same unchanged attempt.","Permanent refusal because the sender was not authorized for that destination: host or recipient filtering may apply. Fix identity, sending path, or policy before any new attempt. Unresolved authorization issues can hurt sender reputation and deliverability. Do not retry the unchanged attempt.","Sender authorization to deliver to the named destination was refused as a policy or security decision; that is what code 5.7.1 states under pattern X.7.1. In the enhanced status register this authorization detail is permanent, and the status-code list defines X.7.1 for that permanent form only. Per-host or per-recipient filtering can yield the same reply, yet the code alone never names the rule or system that applied it, and it does not establish the recipient address is invalid.","Unauthorized sending to the destination, with the message refused, is the meaning of X.7.1; per-host or per-recipient filtering may produce this result. The status-code list description says this detail is useful only as a permanent error, and concrete code 5.7.1 applies it in class 5.","The leading digit 5 denotes a permanent failure of the current attempt. The code alone does not identify the specific rule or system that applied it, and it does not establish that the recipient address is invalid.","Operational guidance: stop automatic and manual retries of the same unchanged attempt. Consider a new send only after a confirm change to the sender identity or authorization, the applicable rule, or the sending path; check suppression again before the attempt.","Operational guidance: do not automatically add an address or domain to a suppression list based on 5.7.1 alone. Inspect the complete response, authorization and filtering context, event history, and applicable policy, then make the suppression decision in that context.","[""The reporting system determined that the sender was not authorized to send to the destination, for example because of per-host or per-recipient filtering.""]","[""Correlate the event with the intended message, attempt time, sender identity and host, destination, transaction stage, and system that returned the code; identify the specific rule from available logs instead of inferring it from the code alone."",""Stop unchanged retries; before a controlled new send, confirm a material correction and reassess suppression.""]","{""sender"":[""Do not resend the same unchanged message; confirm the intended sender identity and destination, then give the administrator the complete response."",""Correct only a confirmed error in the sender, recipient, or required sending path, without treating the address as invalid from this code alone.""],""sender_admin"":[""Retain the complete response and attempt context, then inspect the sender identity, host, authentication, and sending-path configuration used for the specific refusal."",""Stop unchanged retries; after a confirm correction, make a controlled new attempt and reassess suppression.""],""recipient_admin"":[""If the code came from a recipient system you manage, inspect authorization rules and host- or recipient-level filters for the specified attempt, including the applicable domain policy or authentication requirement."",""If the confirmed rule does not match the intended policy, correct it within your authority and confirm the result of a new, controlled attempt.""],""provider"":[""For the specified attempt, inspect managed-service logs and the applied rule, then give the administrator exact, safe context for the refusal."",""Correct a confirmed problem in the managed layer or identify the owner of the required correction; do not trigger automatic suppression from 5.7.1 alone.""]}","[""4.7.1"",""5.7.0"",""5.7.2"",""5.7.4""]","esc-5-7-1","permanent","policy_block","unverified","retry_after_correction","no_recommendation","medium","true"70"email-error-5-7-10","5.7.10","X.7.10","5-7-10","https://blazalek.com/en/email-errors/5-7-10","security-authentication-policy","permanent_failure","do_not_retry","check_context","[""sender"",""sender_admin"",""recipient_admin"",""provider""]","5.7.10 — Encryption needed","The server permanently refused the attempt to use the selected authentication mechanism because it requires an external strong privacy layer. Do not retry the unchanged attempt.","Permanent AUTH refusal: the mechanism needs TLS or another strong privacy layer first. Enable encryption or pick a stronger mechanism before retrying. A transport setup gap, not a recipient bounce; fix it to restore sending and protect reputation. Do not retry unchanged.","Clear-text AUTH that must wait for an external strong privacy layer such as TLS falls under status-code list pattern X.7.10, and code 5.7.10 carries that detail into the SMTP reply. The status is a transport confidentiality precondition for the requested mechanism. Permanent class 5 refuses the current attempt. It does not establish invalid credentials, a bad recipient address, or the exact TLS configuration the server will accept.","Before the requested authentication mechanism may be used, an external strong privacy layer is required under X.7.10. The detail is intended primarily for clear-text authentication; the client may activate a security layer such as TLS first, or choose a stronger mechanism instead. Code 5.7.10 applies this detail in class 5.","The leading digit 5 denotes a permanent failure of the current attempt. Repeating the attempt without changing the privacy layer or mechanism does not resolve the stated condition; the code alone identifies neither a supported TLS configuration nor a stronger mechanism and does not establish that the credentials or recipient address are invalid.","Operational guidance: stop automatic and manual retries of the same unchanged attempt. Make a new, controlled attempt only after confirming that the required privacy layer, such as TLS, is active or configuring a stronger mechanism allowed by the server; check suppression again first.","Operational guidance: do not automatically add the address or domain to a suppression list based on code 5.7.10 alone. Inspect the complete response, connection-security state, selected mechanism, server policy, and event history, then make the decision according to the confirmed cause and applicable policy.","[""The client attempted to use an authentication mechanism that requires an external strong privacy layer before such a layer was active.""]","[""Correlate the response with the attempt time, client, server endpoint, selected mechanism, and connection privacy-layer state; inspect available logs for TLS negotiation and authentication policy instead of inferring the required configuration from the code alone."",""Stop unchanged retries; before a new, controlled attempt, confirm activation of the required privacy layer or selection of an allowed stronger mechanism, check suppression again, and compare the result.""]","{""sender"":[""Do not make further manual attempts without a change; give the administrator the complete response, attempt time, and account used without disclosing credentials.""],""sender_admin"":[""Retain the complete response and inspect the client configuration, TLS or other privacy-layer state, selected mechanism, and server endpoint for the specified attempt."",""Configure a confirmed security layer or stronger mechanism that complies with server policy, check suppression again, and make one controlled attempt instead of repeating the unchanged authentication.""],""recipient_admin"":[""If you manage the server that returned the code, inspect its logs, privacy-layer availability, and authentication policy applied to the specified attempt."",""Correct the configuration only if it does not match the intended policy; otherwise give the sender administrator safe information needed to establish the required layer or select an allowed mechanism.""],""provider"":[""If you operate a service involved in authentication or secure-connection establishment, inspect its logs and policy for the specified time, endpoint, and mechanism."",""Correct a confirmed problem in the managed layer or identify the supported way to establish the required protection or use a stronger mechanism; do not trigger automatic suppression from the code alone.""]}","[""5.7.0"",""5.7.1"",""5.7.2"",""5.7.4""]","esc-5-7-10","permanent","authentication_failure","unverified","retry_after_correction","no_recommendation","high","false"71"email-error-5-7-11","5.7.11","X.7.11","5-7-11","https://blazalek.com/en/email-errors/5-7-11","security-authentication-policy","permanent_failure","do_not_retry","check_context","[""sender"",""sender_admin"",""recipient_admin"",""provider""]","5.7.11 — Authentication mechanism requires an encrypted connection","The server permanently refused the AUTH attempt because the selected authentication mechanism may be used only over an encrypted SMTP connection. Do not retry the same unchanged attempt.","Permanent AUTH refusal: the selected mechanism is allowed only over an encrypted SMTP connection. Establish sufficient TLS before retrying AUTH. A transport configuration issue that can block submission and indirectly hurt deliverability. Do not retry unchanged.","Historically, AUTH could answer with X.7.11; code 5.7.11 keeps that status-code list meaning under class 5. The chosen mechanism may run only while the underlying SMTP session already carries a sufficiently strong encryption layer. Modern practice should not advertise such a mechanism unless that protection is active. Permanent refusal here signals an encryption requirement for the mechanism, not wrong credentials, an invalid mailbox, or the precise cipher policy the server enforces.","As a historical AUTH response, X.7.11 states that the selected authentication mechanism may be used only when the underlying SMTP connection is protected by an encryption layer of sufficient strength. A modern implementation should not advertise such a mechanism without an active, sufficient encryption layer. Code 5.7.11 applies this detail in class 5.","The leading digit 5 denotes a permanent failure of the current attempt. Repeating AUTH with the connection in the same state does not remove the stated obstacle; the code alone does not specify the required encryption configuration or establish that the credentials or recipient address are invalid.","Operational guidance: stop automatic and manual retries of the same unchanged attempt. Consider a new, controlled attempt only after confirming sufficient connection encryption or selecting a mechanism permitted in the current state; check suppression again before the attempt.","Operational guidance: do not automatically add an address or domain to a suppression list based on 5.7.11 alone. Inspect the complete response, encryption state, AUTH mechanism, event history, and applicable policy, then make the suppression decision in that context.","[""The client selected an AUTH mechanism that requires encryption while the underlying SMTP connection lacked a sufficient encryption layer."",""The server advertised a mechanism that was not permitted in the current encryption state, although modern implementations should not do so.""]","[""Correlate the response with the attempt time, client, server endpoint, selected AUTH mechanism, and the state and strength of the encryption layer; determine these details from configuration and safe logs instead of inferring them from the code alone."",""Stop unchanged retries; before a controlled new attempt, confirm sufficient encryption or a permitted mechanism, check suppression again, and compare the result.""]","{""sender"":[""Do not manually repeat the same attempt; give the administrator the complete response, attempt time, and account used without disclosing credentials.""],""sender_admin"":[""Inspect the client configuration, endpoint, AUTH mechanism, and the encryption state and strength for the specified attempt."",""After a confirm correction to encryption or the mechanism, check suppression again and make one controlled attempt instead of repeating the unchanged AUTH request.""],""recipient_admin"":[""If you manage the server that returned the code, inspect its logs, AUTH policy, and the mechanisms advertised in the encryption state applicable to the specified attempt."",""Correct a confirmed mismatch between advertised mechanisms and encryption policy, or give the sender administrator safe information about the required connection method.""],""provider"":[""If you operate a service involved in the attempt, inspect its encryption and AUTH logs and give the administrator safe context needed to identify the required correction."",""Correct a confirmed problem in managed configuration or identify the owner of the correction; do not trigger automatic suppression from the code alone.""]}","[""5.7.0"",""5.7.1"",""5.7.2"",""5.7.4""]","esc-5-7-11","permanent","authentication_failure","unverified","retry_after_correction","no_recommendation","high","false"72"email-error-5-7-13","5.7.13","X.7.13","5-7-13","https://blazalek.com/en/email-errors/5-7-13","security-authentication-policy","permanent_failure","do_not_retry","check_context","[""sender"",""sender_admin"",""recipient_admin"",""provider""]","5.7.13 — User account disabled","Authentication succeeded, but the account is disabled, so the server permanently refused the attempt. Do not retry the same unchanged attempt.","Permanent block after successful AUTH: the account is disabled administratively. Re-enable the account before retrying; repeating the same login will not help. Not an address bounce: suppression needs context, not automatic removal. Do not retry unchanged.","Successful authentication can still land on code 5.7.13 under status-code list pattern X.7.13 when the authenticated user account remains disabled by an administrator. Class 5 reports a permanent refusal even though the passphrase was valid. The status separates account-state blocking from a generic AUTH failure or a recipient-address bounce. The code alone does not reveal why the account was disabled or confirm that re-enabling it will restore service.","Successful client authentication paired with an administrator-disabled user account is the X.7.13 case. Code 5.7.13 applies this detail in class 5 and indicates that the failure remains permanent until the user contacts the system administrator to have the account re-enabled for further use.","The leading digit 5 denotes a permanent failure of the current attempt. This is not a generic authentication failure: the credentials were accepted, but the account state blocks further operation, so entering the same passphrase again does not remove the cause.","Operational guidance: stop automatic and manual retries of the same unchanged attempt. Make a new, controlled attempt only after confirming that the correct account has been re-enabled or that another confirm correction to its state was made; check suppression again first.","Operational guidance: do not automatically add the recipient address or domain to a suppression list based on code 5.7.13 alone. Inspect the complete response, the account used for authentication, the system that returned the code, event history, and applicable policy, then make the suppression decision in that context.","[""An administrator disabled the account for an administrative or security reason, such as nonpayment, abuse, or context of an attempted break-in.""]","[""Correlate the response with the attempt time, client, authenticated account, and system that returned the code; use safe logs to confirm that authentication succeeded and the account was disabled instead of treating the event as a passphrase error."",""Stop unchanged retries; before one controlled attempt, confirm that the correct account has been re-enabled or that another material correction to its state was made, and check suppression again.""]","{""sender"":[""Do not repeat the same attempt or re-enter the same credentials; contact the system administrator and provide the complete response and event time without disclosing secrets.""],""sender_admin"":[""Identify the account and endpoint used in the attempt, then confirm successful authentication and the account's disabled state in safe logs."",""Resolve the confirm administrative or security cause and re-enable the account only under the applicable policy; then check suppression and permit one controlled attempt.""],""recipient_admin"":[""If you manage the system that returned the code, inspect authentication logs and the specified account's status for the attempt time."",""Re-enable the account only after confirming that administrative and security conditions have been met, or give the sender administrator safe context needed to resolve the matter.""],""provider"":[""If you operate a service involved in authentication, confirm the account state and give the appropriate administrator safe context and a re-enablement path; do not trigger automatic suppression from the code alone.""]}","[""5.7.0"",""5.7.1"",""5.7.2"",""5.7.4""]","esc-5-7-13","permanent","authentication_failure","unverified","retry_after_correction","no_recommendation","medium","true"73"email-error-5-7-14","5.7.14","X.7.14","5-7-14","https://blazalek.com/en/email-errors/5-7-14","security-authentication-policy","permanent_failure","do_not_retry","check_context","[""sender"",""sender_admin"",""recipient_admin"",""provider""]","5.7.14 — Trust relationship required","The submission server permanently refused the attempt because access to the message content requires a configured trust relationship with a third-party server. Do not retry the same unchanged attempt.","Permanent submission refusal: a trust relationship with a third-party server is missing for message content access. Configure the relationship before retrying. An infrastructure or policy gap, not routine list hygiene. Do not retry unchanged.","status-code list pattern X.7.14, carried as code 5.7.14 in enhanced status class 5, replaces the earlier X.7.8 mapping for this condition. The submission server refuses content inspection while the partner-system trust configuration it needs for third-party access remains unset. That missing linkage yields a permanent refusal. The status points to infrastructure trust setup, not list hygiene, invalid recipient addressing, or authentication credentials. The numeric reply does not identify which partner host, which trust parameters, or which operator must correct the gap.","Submission servers that need a configured trust relationship with a third-party server before accessing message content use X.7.14 for that condition. The pattern replaces the prior use of X.7.8 for the same case; code 5.7.14 applies this detail in class 5.","The leading digit 5 denotes a permanent failure of the current attempt. An unchanged retry will not establish the required trust relationship; the code alone identifies neither the third-party server, the required configuration, nor the owner of the fault.","Operational guidance: stop automatic and manual retries of the same unchanged attempt. Consider a new, controlled attempt only after confirming the proper trust relationship or correcting its configuration; check suppression again first.","Operational guidance: do not automatically suppress the address or domain based on 5.7.14 alone. Inspect the complete response, the systems involved in the attempt, their configuration, and the event history, then make the suppression decision according to the confirmed cause and applicable policy.","[""The trust relationship required between the submission server and the third-party server for access to the message content was not configured.""]","[""Correlate the response with the attempt time, submission server, and third-party server used to access the content; inspect safe logs and the trust-relationship configuration instead of inferring those details from the code alone."",""Stop unchanged retries; before one controlled attempt, confirm that the required relationship was established or corrected, check suppression again, and compare the result.""]","{""sender"":[""Do not manually retry the same attempt; give the administrator the complete response and event time without exposing message content or secrets.""],""sender_admin"":[""Use logs and configuration to identify the submission server, third-party server, and required trust relationship, then coordinate the correction with the owner of the relevant system."",""After a confirm correction, check suppression again and make one controlled attempt instead of repeating the unchanged submission.""],""recipient_admin"":[""If you manage a server involved in content access, inspect its logs and trust-relationship configuration for the specified attempt, then correct only a confirmed problem.""],""provider"":[""If you operate the submission server or third-party server, inspect the expected trust relationship and safely identify a confirmed gap or configuration requirement for the administrators; do not trigger automatic suppression from the code alone.""]}","[""5.7.0"",""5.7.1"",""5.7.2"",""5.7.4""]","esc-5-7-14","permanent","infrastructure","unverified","retry_after_correction","no_recommendation","medium","true"74"email-error-5-7-15","5.7.15","X.7.15","5-7-15","https://blazalek.com/en/email-errors/5-7-15","security-authentication-policy","permanent_failure","do_not_retry","check_context","[""sender"",""sender_admin"",""recipient_admin"",""provider""]","5.7.15 — Priority level is too low","The receiving SMTP server permanently refused the attempt because the message's specified priority was below the lowest level the server accepts. Do not retry the same unchanged attempt.","Permanent refusal: the message priority is below what the receiving server accepts. Raise priority or confirm server conditions changed before retrying. A policy threshold issue with limited direct reputation impact unless sent at scale by mistake. Do not retry unchanged.","Priority declared on a message can sit below the minimum the recipient SMTP system will honor for transfer; status-code list pattern X.7.15 then surfaces as code 5.7.15 in the security and policy subfamily. The first digit classifies the outcome as permanent in the enhanced status register, even though the standard notes the threshold may reflect a temporary operating mode that favors higher-priority traffic. The status names a priority-policy mismatch; it does not establish invalid addressing or an authentication failure. It also omits the accepted floor, the reason the rule is active, and any duration for a restricted mode.","When the specified priority level is below the lowest priority acceptable to the receiving SMTP server, X.7.15 applies. The standard allows that the cause may be a temporary server mode in which only higher-priority messages are accepted for transfer and delivery while lower-priority messages are rejected, but code 5.7.15 reports the result in the permanent class.","The leading digit 5 denotes a permanent failure of the current attempt. The code does not state the accepted threshold, why it applies, or how long the server mode will last, so those details must not be inferred from the code alone.","Operational guidance: stop automatic and manual retries of the same unchanged attempt. Consider a new, controlled attempt only after a confirmed correction to the intended priority or after the recipient or provider confirms that acceptance conditions changed; check suppression again first.","Operational guidance: do not automatically suppress the recipient address based on 5.7.15 alone. Inspect the complete response, priority used, configuration, and event history, then make the suppression decision only from the confirmed cause and applicable policy.","[""The priority level specified for the message was below the lowest level accepted by the receiving SMTP server."",""The receiving server was operating in a mode that accepts only higher-priority messages while rejecting lower-priority messages.""]","[""Correlate the response with the intended message, attempt time and stage, receiving endpoint, and priority level specified for that message."",""Use available configuration and logs to check the intended priority, accepted threshold, and server operating mode; do not assume those values from the code alone."",""Stop unchanged retries; after a confirmed correction or change in conditions, check suppression again and compare the outcome of one controlled attempt.""]","{""sender"":[""Confirm the message's intended priority and give the administrator the attempt time and complete response without repeatedly retrying it manually.""],""sender_admin"":[""Check the priority set by the sending system, retain the attempt context, and coordinate confirmation of the accepted threshold; make a new attempt only after a confirmed correction or change in conditions.""],""recipient_admin"":[""If you manage the server that returned the code, inspect its priority threshold, operating mode, and logs for the attempt, then correct a confirmed problem or safely state the applicable requirement.""],""provider"":[""If you operate a service involved in the attempt, inspect managed logs and configuration for that attempt, confirm the threshold and server mode, and correct only a problem in the managed layer.""]}","[""4.7.15"",""5.7.0"",""5.7.1"",""5.7.2""]","esc-5-7-15","permanent","policy_block","unverified","retry_after_correction","no_recommendation","medium","true"75"email-error-5-7-16","5.7.16","X.7.16","5-7-16","https://blazalek.com/en/email-errors/5-7-16","security-authentication-policy","permanent_failure","do_not_retry","check_context","[""sender"",""sender_admin"",""recipient_admin"",""provider""]","5.7.16 — Message too big for the specified priority","The server permanently rejected the message because it is too big for the specified priority. Do not retry the same attempt unchanged.","Permanent refusal: the message exceeds the size limit for its priority level. Reduce size, raise priority, or confirm server limits before retrying. A policy constraint, not a hard address bounce. Do not retry unchanged.","A message larger than the receiving server's size limit for the stated priority maps to status-code list pattern X.7.16 as code 5.7.16, a permanent security-policy outcome. In the enhanced status register, class 5 treats this attempt as permanently failed, even when the standard describes the size cap as part of a mode that may later accept larger traffic at higher priority. The code reports a size-versus-priority constraint, not context that the recipient address is invalid. It does not include the message size, priority value, or enforced limit from the response alone.","Message size beyond what the specified priority allows is the X.7.16 meaning. The standard says the condition may be temporary, for example when the server is operating in a mode that accepts only higher-priority messages below a defined size limit. Code 5.7.16 still places the result in the permanent class via its leading digit.","The leading digit 5 denotes a permanent failure of the current attempt. Regardless of a possible later change in server mode, handle 5.7.16 as permanent and do not retry the attempt unchanged. The code alone gives neither the message size, the priority value, nor the applied limit.","Operational recommendation: stop automatic and manual retries of the same unchanged message. Consider a new, controlled attempt only after a justified reduction in message size, a valid priority change, or a confirmed change to the server limit; check suppression again first.","Operational recommendation: do not automatically add an address or domain to a suppression list based on 5.7.16 alone. Inspect the full response, message size and priority, server constraints, and other delivery events, then make the suppression decision according to the confirmed cause and applicable policy.","[""The message size exceeds the limit applied by the server to the specified priority."",""The server is operating in a mode that accepts only higher-priority messages below a defined size limit.""]","[""Correlate the response with the intended message, attempt time and stage, server that returned the code, message size, and specified priority; do not infer missing values from the code alone."",""Use available server logs and policy to check the size limit for that priority and the active operating mode. Stop unchanged attempts, check suppression, and make a new controlled attempt only after a confirmed change.""]","{""sender"":[""Do not resend the same message manually; confirm that its content, attachments, and priority are intended, and give the sender administrator the full response."",""Reduce the message or change its priority only when justified by the content and confirmed by an administrator; report the result of the new, controlled attempt.""],""sender_admin"":[""Retain the full response, message size, priority, time, and server that returned the code, stop unchanged retries, and check suppression."",""Use logs and policy to establish the applicable limit and server mode, coordinate a confirmed correction with the recipient administrator or provider, and only then make one controlled attempt.""],""recipient_admin"":[""If you manage the server that returned the code, inspect its logs, active operating mode, and size limits for the specified priority at the attempt time."",""Correct the confirmed configuration problem within your control, or give the sender a safe, precise description of the applicable constraints, and confirm the new attempt.""],""provider"":[""If you operate a system involved in the attempt, inspect managed-service logs and the size and priority limits applied at the specified time."",""Correct the confirmed problem in the managed layer, or give the appropriate administrators the precise context needed to resolve it; do not trigger suppression based on the code alone.""]}","[""4.7.16"",""5.7.0"",""5.7.1"",""5.7.2""]","esc-5-7-16","permanent","policy_block","unverified","retry_after_correction","no_recommendation","medium","true"76"email-error-5-7-17","5.7.17","X.7.17","5-7-17","https://blazalek.com/en/email-errors/5-7-17","security-authentication-policy","permanent_failure","do_not_retry","check_context","[""sender"",""sender_admin"",""recipient_admin"",""provider""]","5.7.17 — Mailbox 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.","Permanent RRVS failure: the mailbox has not stayed continuously owned by the intended recipient since the stamped time. confirm recipient identity and RRVS data before retrying. A security signal about address ownership, not routine list hygiene. Do not retry unchanged.","Mailbox continuity that broke after the stamped date-time is the RRVS finding behind code 5.7.17, from status-code list 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 confirmation 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.","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.","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.","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.","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.","[""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.""]","[""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 confirm 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.""]","{""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_admin"":[""Retain the complete response, address, and RRVS timestamp, stop unchanged retries, and confirm the recipient, account, and mailbox relationship; correct only confirmed stale data or an RRVS parameter, then check suppression before a controlled attempt.""],""recipient_admin"":[""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.""]}","[""5.7.0"",""5.7.1"",""5.7.2"",""5.7.4""]","esc-5-7-17","permanent","recipient_invalid","unverified","do_not_retry","no_recommendation","medium","true"77"email-error-5-7-18","5.7.18","X.7.18","5-7-18","https://blazalek.com/en/email-errors/5-7-18","security-authentication-policy","permanent_failure","do_not_retry","check_context","[""sender"",""sender_admin"",""recipient_admin"",""provider""]","5.7.18 — Domain owner has changed","The receiving system permanently rejected the message and indicated that the owner of the recipient's domain had changed since the time supplied through RRVS. Do not retry the same unchanged attempt.","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.","When domain ownership shifted after the RRVS timestamp, code 5.7.18 records that disclosure under status-code list 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.","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.","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.","Operational guidance: stop automatic and manual retries of the same unchanged attempt. Consider a new, controlled attempt only after confirm the recipient, domain, and RRVS context and confirming a material correction; check suppression again first.","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.","[""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.""]","[""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.""]","{""sender"":[""Do not resend the same unchanged message; confirm the intended recipient and domain, then give the sender administrator the complete response.""],""sender_admin"":[""Retain the complete response and attempt context, confirm the recipient domain and RRVS time used, stop unchanged retries, and coordinate a confirmed correction with the recipient administrator or provider.""],""recipient_admin"":[""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.""]}","[""5.7.0"",""5.7.1"",""5.7.2"",""5.7.4""]","esc-5-7-18","permanent","policy_block","unverified","do_not_retry","no_recommendation","medium","true"78"email-error-5-7-19","5.7.19","X.7.19","5-7-19","https://blazalek.com/en/email-errors/5-7-19","security-authentication-policy","permanent_failure","do_not_retry","check_context","[""sender"",""sender_admin"",""recipient_admin"",""provider""]","5.7.19 — RRVS test cannot be completed","The receiving system permanently rejected the message because it could not complete the RRVS evaluation: the required timestamp had not been recorded. Do not retry the same attempt unchanged.","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.","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 status-code list 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.","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.","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.","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.","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.","[""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.""]","[""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.""]","{""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_admin"":[""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_admin"":[""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.""]}","[""5.7.0"",""5.7.1"",""5.7.2"",""5.7.4""]","esc-5-7-19","permanent","policy_block","unverified","retry_after_correction","no_recommendation","medium","false"79"email-error-5-7-2","5.7.2","X.7.2","5-7-2","https://blazalek.com/en/email-errors/5-7-2","security-authentication-policy","permanent_failure","do_not_retry","check_context","[""sender"",""sender_admin"",""recipient_admin"",""provider""]","5.7.2 — Mailing list expansion prohibited","The system permanently refused the message because the sender was not authorized to send to the intended mailing list. Do not retry the same unchanged attempt.","Permanent rejection: the sender cannot post to the intended mailing list. Coordinate list permissions with the list administrator before resending. Usually an authorization issue, not list hygiene, but repeated blocks warrant a policy review. Do not retry unchanged.","Posting to the intended mailing list is unauthorized for this sender, so list expansion for that submission is prohibited; status-code list pattern X.7.2 appears as code 5.7.2 for that refusal. In the enhanced status register this list-authorization detail is permanent, and the standard assigns X.7.2 exclusively to that permanent form. The numeric reply describes a mailing-list posting refusal, not a broader mailbox or routing fault, and by itself it neither names the posting rule nor establish the list address is invalid.","Unauthorized sending of a message to the intended mailing list is what X.7.2 covers. The standard says this detail is useful only as a permanent error, and code 5.7.2 applies it in class 5.","The leading digit 5 denotes a permanent failure of the current attempt. The code describes an authorization refusal for a list, but by itself it does not identify the specific rule or establish that the list address is invalid.","Operational guidance: stop automatic and manual retries of the same unchanged attempt. Consider a new send only after a confirm change to the sender identity, its authorization, or the applicable list rule; check suppression again before the attempt.","Operational guidance: do not automatically add the list address or domain to a suppression list based on 5.7.2 alone. Inspect the complete response, list-authorization context, event history, and applicable policy, then make the suppression decision in that context.","[""The system serving the intended mailing list determined that the sender was not authorized to send a message to it.""]","[""Correlate the event with the intended message, attempt time, sender identity used, intended list, transaction stage, and system that returned the code; identify the applied rule from available logs instead of inferring it from the code alone."",""Stop unchanged retries; before a controlled new send, confirm a material change to authorization, identity, or the list rule and check suppression again.""]","{""sender"":[""Do not resend the same unchanged message; confirm the intended sender identity and list, then give the administrator the complete response.""],""sender_admin"":[""Retain the complete response and attempt context, inspect the sender identity and sending-path configuration used, and coordinate with the list administrator to identify the authorization that requires correction.""],""recipient_admin"":[""If you manage the list, inspect the posting rules and sender authorization applied to the specified attempt; correct them only if they do not match the intended policy.""],""provider"":[""If you operate a system involved in the attempt, inspect managed-service logs and the applied rule, then give the administrators safe context needed to confirm the appropriate correction.""]}","[""5.7.0"",""5.7.1"",""5.7.4"",""5.7.8""]","esc-5-7-2","permanent","policy_block","unverified","retry_after_correction","no_recommendation","high","false"80"email-error-5-7-20","5.7.20","X.7.20","5-7-20","https://blazalek.com/en/email-errors/5-7-20","security-authentication-policy","permanent_failure","do_not_retry","check_context","[""sender"",""sender_admin"",""recipient_admin"",""provider""]","5.7.20 — No passing DKIM signature found","The receiving system permanently rejected the message because it contained no DKIM signature that passed confirm. Do not retry the same unchanged attempt.","Permanent authentication-policy rejection: no DKIM signature passed confirm. Fix signing on the sending path before retrying. Missing or failing DKIM hurts domain reputation and inbox deliverability. Do not retry unchanged.","No DKIM signature on the message passes cryptographic confirm at evaluation time; that condition is status-code list pattern X.7.20, returned as code 5.7.20. The first digit places the outcome in class 5 permanent failures under the enhanced status register. This security-family detail signals missing or failing DKIM coverage relative to SMTP specification Section 6.1 advice. The code alone does not distinguish absent DKIM-Signature headers from signatures that were present but invalid, nor does it identify which layer on the signing or confirm path caused the result.","Absence of any passing DKIM signature is the X.7.20 condition; by definition that outcome violates the advice in Section 6.1 of SMTP specification. Code 5.7.20 applies this detail in the permanent-failure class.","The leading digit 5 denotes a permanent failure of the current attempt. The code alone does not distinguish between a missing DKIM signature and failure of every signature present, nor does it identify which layer caused that result.","Operational guidance: stop automatic and manual retries of the same unchanged attempt because they will not change the DKIM result. Consider a new, controlled attempt only after a confirmed correction and confirm that at least one DKIM signature passes; check suppression again first.","Operational guidance: do not automatically suppress the recipient address or domain based on 5.7.20 alone. Inspect the complete response, DKIM result, configuration of the systems involved, and event history, then make the suppression decision according to the confirmed cause and applicable policy.","[""The message contained no DKIM signature at the point where it was evaluated."",""The message contained at least one DKIM signature, but none passed confirm.""]","[""Correlate the response with the intended message, attempt time and stage, and system that returned the code. In the message copy from the evaluation point, inspect DKIM-Signature headers and available confirm results or logs to distinguish an absent signature from failure of every signature."",""Inspect logs and configuration across the signing, transport, and confirm path and establish the confirmed cause; do not assign it to the sender, recipient, or provider from the code alone."",""Stop unchanged retries. After a confirmed correction, demonstrate that at least one DKIM signature passes confirm, check suppression again, and make one controlled attempt.""]","{""sender"":[""Do not repeatedly send the same unchanged message; give the administrator the complete response and attempt time without exposing message content or secrets.""],""sender_admin"":[""Inspect the sent-message copy and signing and transport logs and configuration; establish whether the signature was absent or every signature present failed confirm, then correct only the confirmed cause."",""After the correction, confirm that at least one DKIM signature passes, check suppression again, and make one controlled attempt instead of retrying the unchanged message.""],""recipient_admin"":[""If you manage the system that returned the code, inspect its DKIM confirm logs and configuration for the specified attempt; correct a confirmed receiving-side problem or safely give the sender the result needed for remediation.""],""provider"":[""If you operate a managed signing, transport, or confirm layer, inspect its logs and configuration for the attempt, correct a confirmed problem in that layer, and do not trigger suppression from the code alone.""]}","[""5.7.0"",""5.7.1"",""5.7.2"",""5.7.4""]","esc-5-7-20","permanent","authentication_failure","unverified","retry_after_correction","no_recommendation","high","false"81"email-error-5-7-21","5.7.21","X.7.21","5-7-21","https://blazalek.com/en/email-errors/5-7-21","security-authentication-policy","permanent_failure","do_not_retry","check_context","[""sender"",""sender_admin"",""recipient_admin"",""provider""]","5.7.21 — No acceptable DKIM signature found","The receiving system permanently rejected the message: at least one DKIM signature passed confirm, but none was considered acceptable. Do not retry the attempt unchanged.","Permanent rejection: DKIM confirm but no signature met the receiver acceptance rules. Align selector, domain, and policy before retrying. Authentication gaps can damage sender reputation and deliverability. Do not retry unchanged.","One or more DKIM signatures can pass cryptographic confirm and still fail local acceptance; status-code list pattern X.7.21 then surfaces as code 5.7.21. Class 5 marks a permanent security-policy refusal for this attempt. confirm succeeded for at least one signature, but local acceptance rules rejected every passing option. The status does not explain which rule failed, whether selector, signing domain, or receiver policy is at fault, or which party owns the gap. By definition this violates the guidance in SMTP specification Section 6.1.","Passing DKIM confirm without any of those signatures meeting the receiving system's acceptance criteria is the X.7.21 case. By definition that outcome violates the advice in Section 6.1 of SMTP specification. Code 5.7.21 applies this detail in the permanent-failure class.","The leading digit 5 denotes a permanent failure of the current attempt. The code confirms that at least one DKIM signature passed confirm, but it does not explain why none was accepted or identify which party is responsible for the result.","Operational guidance: stop automatic and manual retries of the same unchanged attempt. Consider a new, controlled attempt only after establishing the cause and making a confirmed change that allows at least one passing signature to be accepted; check suppression again first.","Operational guidance: do not automatically suppress the recipient address or domain based on 5.7.21 alone. Inspect the complete response, DKIM results, configuration of the systems involved, and event history, then make the suppression decision according to the confirmed cause and applicable policy.","[""The direct reason for rejection was that at least one DKIM signature passed confirm, but the receiving system did not consider any passing signature acceptable.""]","[""Correlate the response with the intended message, attempt time and stage, and system that returned the code. In the message copy from the evaluation point, inspect DKIM-Signature headers and available confirm results to confirm that at least one signature passed."",""Inspect logs and configuration across signing, transport, and the receiving DKIM evaluation to establish why no passing signature was accepted; do not assign responsibility from the code alone."",""Stop unchanged retries. After a confirmed correction, confirm that at least one passing signature is accepted, check suppression again, and make one controlled attempt.""]","{""sender"":[""Do not repeatedly send the same unchanged message; give the administrator the complete response and attempt time without exposing message content or secrets.""],""sender_admin"":[""Inspect the sent-message copy and signing and transport logs and configuration; confirm which DKIM signatures passed confirm and coordinate diagnosis of why none was accepted."",""After the correction, confirm that at least one passing signature is accepted, check suppression again, and make one controlled attempt instead of retrying the unchanged message.""],""recipient_admin"":[""If you manage the system that returned the code, inspect its DKIM evaluation logs and configuration for the specified attempt; establish why no passing signature was acceptable and correct a confirmed problem or safely give the sender the result needed for remediation.""],""provider"":[""If you operate a managed signing, transport, or DKIM evaluation layer, inspect its logs and configuration for the attempt, correct a confirmed problem in that layer, and do not trigger suppression from the code alone.""]}","[""5.7.0"",""5.7.1"",""5.7.2"",""5.7.4""]","esc-5-7-21","permanent","authentication_failure","unverified","retry_after_correction","no_recommendation","high","false"82"email-error-5-7-22","5.7.22","X.7.22","5-7-22","https://blazalek.com/en/email-errors/5-7-22","security-authentication-policy","permanent_failure","do_not_retry","check_context","[""sender"",""sender_admin"",""recipient_admin"",""provider""]","5.7.22 — No valid author-matched DKIM signature found","The receiving system permanently rejected the message: at least one DKIM signature passed confirm, but none had an identifier matching an author address in the From field. Do not retry the same unchanged attempt.","Permanent rejection: confirm DKIM exists but none matches a From author address. Align From identity with a valid signing domain before retrying. A From/DKIM mismatch is a reputation and anti-spoofing policy risk. Do not retry unchanged.","Author alignment drives code 5.7.22 under status-code list pattern X.7.22: at least one DKIM signature passes confirm, yet no passing signature identifier matches any address in the From header field. Class 5 assigns a permanent failure in the enhanced status register. The detail targets anti-spoofing identity checks rather than general DKIM validity. It confirms confirm success paired with an author mismatch, without showing whether From, the signing domain, or a relay that altered headers caused the gap.","At least one passing DKIM signature is present under X.7.22, but no passing DKIM signature has an identifier that matches any author address found in the From header field. This is a special case of X.7.21 and, by definition, violates the advice in Section 6.1 of SMTP specification. Code 5.7.22 applies that detail in the permanent-failure class.","The leading digit 5 denotes a permanent failure of the current attempt. The code confirms that at least one DKIM signature passed confirm; the problem is that its identifier does not match an author in the From field, not that every DKIM signature is invalid. The code alone does not identify the layer where the mismatch arose.","Operational guidance: stop automatic and manual retries of the same unchanged attempt because they will not change the match between the DKIM identity and the author. Consider a new, controlled attempt only after a confirmed correction and confirm that at least one DKIM signature both passes and is author-matched; check suppression again first.","Operational guidance: do not automatically suppress the recipient address or domain based on 5.7.22 alone. Inspect the complete response, From field, DKIM results, configuration of the systems involved, and event history, then make the suppression decision according to the confirmed cause and applicable policy.","[""The message contained at least one passing DKIM signature, but no passing DKIM signature had an identifier matching any author address in the From field.""]","[""Correlate the response with the intended message, attempt time and stage, and system that returned the code. In the message copy from the evaluation point, inspect the From field, DKIM-Signature headers, and available confirm results or logs, and confirm that at least one signature passed."",""Compare the identifiers of every passing signature with the author address or addresses in the From field. Inspect signing, transport, and confirm logs and configuration to establish where the mismatch arose, without assigning responsibility from the code alone."",""Stop unchanged retries. After a confirmed correction, demonstrate that at least one DKIM signature passes and is author-matched, check suppression again, and make one controlled attempt.""]","{""sender"":[""Do not repeatedly send the same unchanged message; give the administrator the complete response and attempt time without exposing message content or secrets.""],""sender_admin"":[""Inspect the From field in the sent message and the signing and transport logs and configuration; establish why no passing DKIM signature was author-matched, then correct only the confirmed cause."",""After the correction, confirm that at least one DKIM signature passes and is author-matched, check suppression again, and make one controlled attempt instead of retrying the unchanged message.""],""recipient_admin"":[""If you manage the system that returned the code, inspect its DKIM confirm and author-matching logs and configuration for the specified attempt; correct a confirmed receiving-side problem or safely give the sender the result needed for remediation.""],""provider"":[""If you operate a managed signing, transport, or confirm layer, inspect its logs and configuration for the attempt, correct a confirmed problem in that layer, and do not trigger suppression from the code alone.""]}","[""5.7.0"",""5.7.1"",""5.7.2"",""5.7.4""]","esc-5-7-22","permanent","authentication_failure","unverified","retry_after_correction","no_recommendation","high","false"83"email-error-5-7-23","5.7.23","X.7.23","5-7-23","https://blazalek.com/en/email-errors/5-7-23","security-authentication-policy","permanent_failure","do_not_retry","check_context","[""sender"",""sender_admin"",""recipient_admin"",""provider""]","5.7.23 — SPF validation produced a fail result","The receiving system permanently rejected the message because its SPF check produced a fail result contrary to local policy. Do not retry the same unchanged attempt.","Permanent SPF policy rejection: SPF evaluated to fail against local policy. Fix SPF records or sending infrastructure before retrying. Repeated SPF fail patterns can harm domain reputation and deliverability. Do not retry unchanged.","SPF evaluation that finishes with fail contrary to local policy is status-code list pattern X.7.23, returned as code 5.7.23. SMTP specification Section 8.4 prescribes this code instead of the broader 5.7.1 for that SPF outcome. Class 5 denotes permanent failure for the current attempt. The status confirms a completed SPF check and a fail result; it does not reveal whether fail stems from record content, an unauthorized sending IP, alignment limits, or policy thresholds. Provider-specific enforcement sits outside what the code alone establishes.","A completed SPF check that produced a fail result contrary to local policy requirements is the X.7.23 case. Under Section 8.4 of SMTP specification, operators use this enhanced status code instead of 5.7.1. Code 5.7.23 applies this detail in the permanent-failure class.","The leading digit 5 denotes a permanent failure of the current attempt. The code confirms the SPF fail result and conflict with local policy, but it does not by itself identify the cause of that result, the layer responsible, or any particular provider's policy.","Operational guidance: stop automatic and manual retries of the same unchanged attempt. Consider a new, controlled attempt only after a confirmed correction or confirmed change in policy conditions and confirm that SPF no longer produces a fail result; check suppression again first.","Operational guidance: do not automatically suppress the recipient address or domain based on 5.7.23 alone. Inspect the complete response, SPF result, event scope, configuration of the systems involved, and delivery history, then make the suppression decision according to the confirmed cause and applicable policy.","[""The message's SPF check produced a fail result that was contrary to the receiving system's local policy requirements.""]","[""Correlate the response with the intended message, attempt time and stage, evaluated sender identity, and system that returned the code."",""Use available authentication results, logs, and configuration to confirm the SPF fail result and establish its actual cause; do not assign responsibility or provider practice from the code alone."",""Stop unchanged retries. After a confirmed correction or change in conditions, confirm that SPF no longer produces a fail result, check suppression again, and make one controlled attempt.""]","{""sender"":[""Confirm that the message and sender identity used are intended, then give the sender administrator the complete response and attempt time without repeatedly retrying it manually.""],""sender_admin"":[""Retain the complete response, correlate it with the message, sender identity, and sending system, and inspect available SPF results, logs, and configuration to establish the confirmed cause of the fail result."",""After correction, confirm that SPF no longer produces a fail result, check suppression again, and make one controlled attempt instead of retrying the unchanged message.""],""recipient_admin"":[""If you manage the system that returned the code, inspect its SPF-evaluation logs and local policy for the specified attempt; correct a confirmed receiving-side problem or safely give the sender the result needed for remediation.""],""provider"":[""If you operate a managed sending, SPF-configuration, or SPF-evaluation layer, inspect its logs and configuration for the attempt, correct a confirmed problem in that layer, and do not trigger suppression from the code alone.""]}","[""5.7.0"",""5.7.1"",""5.7.2"",""5.7.4""]","esc-5-7-23","permanent","authentication_failure","unverified","retry_after_correction","no_recommendation","high","false"84"email-error-5-7-24","5.7.24","X.7.24","5-7-24","https://blazalek.com/en/email-errors/5-7-24","security-authentication-policy","permanent_failure","do_not_retry","check_context","[""sender"",""sender_admin"",""recipient_admin"",""provider""]","5.7.24 — SPF validation error","SPF evaluation for the arriving message resulted in an error, and the system returned a permanent failure. Do not retry the same attempt unchanged.","Permanent failure: SPF evaluation itself errored on the incoming message. Fix DNS, SPF configuration, or resolver issues before retrying. Authentication infrastructure faults can indirectly affect deliverability. Do not retry unchanged.","Lookup or infrastructure faults during SPF for an arriving message map to status-code list pattern X.7.24 as code 5.7.24 when evaluation ends in error rather than pass, fail, neutral, or softfail. SMTP specification Sections 8.6 and 8.7 prescribe this code instead of 4.4.3 or 5.5.2 in those cases, and class 5 assigns a permanent refusal. The detail is not an SPF policy verdict. It does not name a DNS timeout, malformed record, resolver failure, or which component failed; diagnosis still needs SPF evaluation logs and supporting service traces.","An error while SPF is evaluated for an arriving message is denoted by X.7.24. Operators use it instead of 4.4.3 or 5.5.2 in the cases described in Sections 8.6 and 8.7 of SMTP specification. Code 5.7.24 assigns the result to the permanent-failure class through its leading digit.","The leading digit 5 denotes a permanent failure of the current attempt. The code does not identify the specific cause of the SPF evaluation error or establish that the recipient address is invalid.","Operational guidance: stop automatic and manual retries of the same unchanged attempt. Consider a new, controlled attempt only after identifying the cause, making a confirmed correction, and checking suppression again.","Operational guidance: do not automatically suppress the recipient address or domain based on 5.7.24 alone. Inspect the complete response, event scope, SPF evaluation result, and other delivery signals, then base the suppression decision on the confirmed cause and applicable policy.","[""SPF evaluation for the arriving message resulted in an error; the code alone does not identify the technical condition that caused it.""]","[""Correlate the result with the intended message, attempt time and stage, identity used for SPF evaluation, and system that returned the code."",""Use available logs from the SPF-evaluating system and supporting services to establish the actual error; do not infer its cause or responsible party from the code alone."",""Stop unchanged retries. After a confirmed correction, check suppression again and make at most one controlled attempt to confirm the result.""]","{""sender"":[""Do not manually retry the same unchanged message; confirm that the message and sender identity are intended, then give the sender administrator the complete response and attempt time.""],""sender_admin"":[""Retain the complete response, correlate it with the message and SPF identity, stop unchanged retries, and inspect available sender-side logs and configuration."",""Make only a confirmed correction, check suppression again, and confirm the result with one controlled attempt.""],""recipient_admin"":[""If you manage the system that returned the code, inspect its SPF-evaluation and supporting-service logs for the specified attempt; correct a confirmed receiving-side problem or safely give the sender the result needed for remediation.""],""provider"":[""If you operate a managed layer involved in SPF evaluation, inspect its logs and configuration, correct a confirmed problem in that layer or give the appropriate administrators precise diagnostic context, and do not trigger suppression from the code alone.""]}","[""4.7.24"",""5.7.0"",""5.7.1"",""5.7.2""]","esc-5-7-24","permanent","authentication_failure","unverified","retry_after_correction","no_recommendation","medium","true"85"email-error-5-7-25","5.7.25","X.7.25","5-7-25","https://blazalek.com/en/email-errors/5-7-25","security-authentication-policy","permanent_failure","do_not_retry","check_context","[""sender"",""sender_admin"",""recipient_admin"",""provider""]","5.7.25 — Reverse DNS validation failed","The receiving system permanently rejected the message because the SMTP client's IP address failed a reverse DNS check required by local policy. Do not retry the same attempt unchanged.","Permanent policy rejection: the SMTP client IP failed required reverse DNS validation. Fix rDNS or routing before retrying. Persistent rDNS policy failures hurt sending-IP reputation and deliverability. Do not retry unchanged.","Reverse DNS validation failed for the SMTP client's IP address against the receiving system's local policy; that outcome is status-code list pattern X.7.25, returned as code 5.7.25. Permanent-failure class 5 in the enhanced status register frames the result for this attempt. The subcode names a policy-layer rDNS gap rather than a specific DNS misconfiguration on the client path. The code alone does not show whether the PTR record is missing, stale, or mismatched, nor which hop enforces the check.","Reverse DNS validation failure for an SMTP client's IP address, contrary to local policy requirements, matches X.7.25. Code 5.7.25 applies that meaning in the permanent-failure class for this check.","The leading digit 5 denotes a permanent failure of the current attempt. The code does not establish why reverse DNS validation failed, which layer needs correction, or the policy of any particular provider.","Operational guidance: stop automatic and manual retries of the same unchanged attempt. Consider a new, controlled attempt only after establishing the cause, making a confirmed correction, and checking the reverse DNS result; check suppression again first.","Operational guidance: do not automatically suppress the recipient address or domain based on 5.7.25 alone. Inspect the complete response, event scope, DNS results, available logs, and delivery history, then base the suppression decision on the confirmed cause and applicable policy.","[""The SMTP client's IP address failed the reverse DNS check required by the local policy of the system that returned the code; the code alone does not identify the exact reason validation failed.""]","[""Correlate the response with the intended message, attempt time and stage, SMTP client IP address, and system that returned the code."",""Use available logs, DNS results, and local-policy configuration to establish which reverse DNS check failed and why; do not assign a specific cause or provider practice from the code alone."",""Stop unchanged retries. After a confirmed correction, check the reverse DNS result and suppression again, then make at most one controlled attempt.""]","{""sender"":[""Do not manually retry the same unchanged message; give the sender administrator the complete response and attempt time.""],""sender_admin"":[""Retain the complete response, correlate the attempt with the SMTP client IP address used, and inspect available logs, DNS results, and managed sending-layer configuration to establish the confirmed cause."",""Make only a confirmed correction, check the reverse DNS result and suppression again, and confirm the outcome with one controlled attempt instead of retrying the unchanged message.""],""recipient_admin"":[""If you manage the system that returned the code, inspect its reverse-DNS-validation logs and local policy for the specified attempt; correct a confirmed receiving-side problem or safely give the sender the context needed for remediation.""],""provider"":[""If you operate a managed IP address, DNS, sending layer, or receiving-side validation, inspect the relevant logs and configuration, correct a confirmed problem in that layer or give the administrators precise diagnostic context, and do not trigger suppression from the code alone.""]}","[""5.7.0"",""5.7.1"",""5.7.2"",""5.7.4""]","esc-5-7-25","permanent","authentication_failure","unverified","retry_after_correction","no_recommendation","medium","false"86"email-error-5-7-26","5.7.26","X.7.26","5-7-26","https://blazalek.com/en/email-errors/5-7-26","security-authentication-policy","permanent_failure","do_not_retry","check_context","[""sender"",""sender_admin"",""recipient_admin"",""provider""]","5.7.26 — Multiple authentication checks failed","The message failed more than one authentication check required by local policy, so the system returned a permanent failure. Do not retry the same attempt unchanged.","Permanent rejection: more than one required authentication check failed under local policy. Identify which mechanisms failed and fix them before retrying. Multiple auth failures signal serious deliverability and reputation risk. Do not retry unchanged.","More than one distinct authentication check treated as mandatory by the receiver's local policy failed for the message; status-code list pattern X.7.26 surfaces that combined result as code 5.7.26 in class 5. The leading digit marks a permanent outcome in the enhanced status register. The subcode reports a multi-check auth failure, not a single SPF, DKIM, or DMARC verdict. It does not by itself identify which mechanisms failed, whether the fault is signing, DNS, or policy configuration, or which party must remediate.","A message that failed more than one authentication check, contrary to local policy requirements, matches X.7.26. The code does not specify which mechanisms failed. Code 5.7.26 assigns the result to the permanent-failure class through its leading digit.","The leading digit 5 denotes a permanent failure of the current attempt. The code confirms that multiple checks failed, but it does not identify their mechanisms, the precise cause, or the party responsible for the problem.","Operational guidance: stop automatic and manual retries of the same unchanged attempt. Consider a new, controlled attempt only after identifying the failed checks, making a confirmed correction, and checking suppression again.","Operational guidance: do not automatically suppress the recipient address or domain based on 5.7.26 alone. Inspect the complete response, event scope, authentication results, and delivery history, then base the suppression decision on the confirmed cause and applicable policy.","[""More than one message authentication check failed, contrary to local policy requirements.""]","[""Correlate the response with the intended message, attempt time and stage, identities used, and system that returned the code."",""Use available authentication results, logs, and configuration to establish which checks failed and which local-policy requirement was not met; do not derive those details from the code alone."",""Stop unchanged retries. After a confirmed correction, check authentication results and suppression again, then make at most one controlled attempt.""]","{""sender"":[""Do not manually retry the same unchanged message; confirm that the message and identities used are intended, then give the sender administrator the complete response and attempt time.""],""sender_admin"":[""Retain the complete response, correlate it with the message and identities used, and inspect available authentication results, logs, and configuration to establish which checks failed."",""Make only a confirmed correction, check authentication results and suppression again, and confirm the outcome with one controlled attempt.""],""recipient_admin"":[""If you manage the system that returned the code, inspect its authentication-check logs and local policy for the specified attempt; correct a confirmed receiving-side problem or safely give the sender the details needed for remediation.""],""provider"":[""If you operate a managed layer involved in the authentication checks, inspect its logs and configuration, correct a confirmed problem in that layer or give the appropriate administrators precise diagnostic context, and do not trigger suppression from the code alone.""]}","[""5.7.0"",""5.7.1"",""5.7.2"",""5.7.4""]","esc-5-7-26","permanent","authentication_failure","unverified","retry_after_correction","no_recommendation","high","false"87"email-error-5-7-27","5.7.27","X.7.27","5-7-27","https://blazalek.com/en/email-errors/5-7-27","security-authentication-policy","permanent_failure","do_not_retry","check_context","[""sender"",""sender_admin"",""recipient_admin"",""provider""]","5.7.27 — Sender address has a null MX","The receiving system permanently rejected the message because the associated sender address has a null MX and the receiver rejects mail from such senders—for example, when it could not return a DSN. Do not retry the same attempt unchanged.","Permanent rejection: the sender domain has a null MX and the receiver rejects such mail. Use a sendable From domain or adjust recipient policy before retrying. Null MX senders often fail deliverability and DSN expectations. Do not retry unchanged.","Null MX on the domain of the SMTP transaction's sender address, combined with a receiving SMTP server configured to reject such senders, is status-code list pattern X.7.27 returned as code 5.7.27. The leading digit denotes a permanent failure in the enhanced status register. The subcode couples sender DNS publication with receiver policy, not recipient mailbox validity. The code alone does not establish whether the null MX is deliberate, whether the From domain should change, or whether the rejection policy on the receiving side should be adjusted.","Code 5.7.27 applies that meaning in the permanent-failure class.","The leading digit 5 denotes a permanent failure of the current attempt. The code alone does not establish whether the null MX is intentional or whether the sender address, DNS, or receiving policy needs correction.","Operational guidance: stop automatic and manual retries of the same unchanged attempt. Make a new, controlled attempt only after a confirmed change to the sender address, its MX, or the receiving policy, and after checking suppression again.","Operational guidance: do not automatically suppress the recipient address or domain based on 5.7.27 alone. The code concerns the sender address and receiving-system policy, so suppression requires the complete context and a confirmed cause.","[""The sender address associated with the SMTP transaction belongs to a domain with a null MX, and the receiving system is configured to reject such senders.""]","[""Correlate the rejection with the correct attempt and identify the sender address and domain to which the code applied."",""Inspect the domain's current MX data and confirm whether the null MX is intentional; do not infer a particular provider's practice from the code alone."",""Inspect the receiving system's logs and policy. Stop unchanged retries; after a confirmed correction, check suppression again and make one controlled attempt.""]","{""sender"":[""Do not manually retry the same unchanged message; give the sender administrator the complete response, attempt time, and sender address used.""],""sender_admin"":[""Correlate the response with the sender address used, inspect its domain's MX data, and establish whether the null MX is intentional or a configuration error."",""If the null MX is erroneous, correct DNS; if it is intentional, use an appropriate sender address that can receive a DSN. Only then check suppression and make one controlled attempt.""],""recipient_admin"":[""If you manage the system that returned the code, inspect its logs and policy for rejecting senders with a null MX; correct a confirmed configuration error or give the sender the precise rejection context.""],""provider"":[""If you operate managed DNS, sending, or receiving infrastructure, inspect the relevant configuration and logs, correct a confirmed problem in that layer, or give the administrators the context needed for remediation.""]}","[""5.7.0"",""5.7.1"",""5.7.2"",""5.7.4""]","esc-5-7-27","permanent","policy_block","unverified","retry_after_correction","no_recommendation","medium","true"88"email-error-5-7-29","5.7.29","X.7.29","5-7-29","https://blazalek.com/en/email-errors/5-7-29","security-authentication-policy","permanent_failure","do_not_retry","check_context","[""sender"",""sender_admin"",""recipient_admin"",""provider""]","5.7.29 — ARC validation failure","This code may be returned when a message fails ARC validation. It denotes a permanent failure of the current attempt, so do not retry it unchanged.","Permanent rejection: ARC validation failed on the message. Fix the forwarding or sealing chain before retrying. ARC failures in intermediated mail can block deliverability for forwarded traffic. Do not retry unchanged.","ARC validation failed against the evaluating server's policy, and status-code list pattern X.7.29 can surface that outcome as code 5.7.29 in enhanced status class 5. The leading digit marks a permanent result in the register. The subcode places the failure in the ARC layer of the security family, apart from recipient-address validity and from naming any authentication check beyond ARC. Alone it does not specify which ARC set failed, whether sealing, keys, or hop order broke, or which administrator owns remediation of the chain.","Failed ARC validation is the condition under which X.7.29 may be returned. Code 5.7.29 assigns the result to the permanent-failure class through its leading digit. The code does not identify the cause of the failed validation.","The leading digit 5 denotes a permanent failure of the current attempt. The code confirms a problem with ARC validation, but it does not identify the precise condition or the party responsible for it.","Operational guidance: stop automatic and manual retries of the same unchanged attempt. Consider a new, controlled attempt only after establishing the cause, making a confirmed correction, and checking ARC validation and suppression again.","Operational guidance: do not automatically suppress the recipient address or domain based on 5.7.29 alone. Inspect the complete response, event scope, available ARC validation results, and delivery history, then base the suppression decision on the confirmed cause and applicable policy.","[""The message failed ARC validation; the code alone does not identify the precise condition that caused the failure.""]","[""Correlate the response with the intended message, attempt time and stage, and system that returned the code."",""Use available ARC validation results, logs, and configuration to establish the actual failure condition; do not infer its cause or responsible party from the code alone."",""Stop unchanged retries. After a confirmed correction, check ARC validation and suppression again, then make at most one controlled attempt.""]","{""sender"":[""Do not manually retry the same unchanged message; give the sender administrator the complete response and attempt time.""],""sender_admin"":[""Retain the complete response, correlate it with the intended message, and inspect available ARC validation results, logs, and configuration to establish the confirmed cause."",""Make only a confirmed correction, check ARC validation and suppression again, and confirm the outcome with one controlled attempt.""],""recipient_admin"":[""If you manage the system that returned the code, inspect its ARC validation logs and configuration for the specified attempt; correct a confirmed receiving-side problem or safely give the sender the context needed for remediation.""],""provider"":[""If you operate a managed layer involved in ARC validation, inspect its logs and configuration, correct a confirmed problem in that layer or give the appropriate administrators precise diagnostic context, and do not trigger suppression from the code alone.""]}","[""5.7.0"",""5.7.1"",""5.7.2"",""5.7.4""]","esc-5-7-29","permanent","authentication_failure","unverified","retry_after_correction","no_recommendation","high","false"89"email-error-5-7-30","5.7.30","X.7.30","5-7-30","https://blazalek.com/en/email-errors/5-7-30","security-authentication-policy","permanent_failure","do_not_retry","check_context","[""sender"",""sender_admin"",""recipient_admin"",""provider""]","5.7.30 — REQUIRETLS support required","The message was received with a REQUIRETLS requirement but could not be forwarded because none of the destination SMTP servers provided that support. Code 5.7.30 denotes a permanent failure of the current attempt.","Permanent relay failure: a REQUIRETLS message could not be forwarded because no next-hop server supports it. Enable REQUIRETLS on the path or change routing before retrying. TLS policy gaps block secure delivery and can hurt reputation. Do not retry unchanged.","When no eligible next-hop SMTP server advertises REQUIRETLS, a REQUIRETLS-required message cannot be relayed; status-code list pattern X.7.30 returns that break as code 5.7.30. Permanent-failure class framing comes from the leading digit in the enhanced status register. The subcode describes a TLS policy continuity break on the forwarding path, not recipient address rejection. The code alone does not identify which hop lacks REQUIRETLS support, whether routing or server configuration must change, or whether the REQUIRETLS requirement should remain on the message.","Messages received with a REQUIRETLS requirement that cannot be forwarded because none of the SMTP servers to which they should be forwarded supported REQUIRETLS match X.7.30. Code 5.7.30 assigns the result to the permanent-failure class through its leading digit.","The leading digit 5 denotes a permanent failure of the current attempt. Without a confirmed change to handling or routing, another identical attempt will encounter the same lack of REQUIRETLS support.","Operational guidance: stop automatic and manual retries of the same unchanged message and route. Consider a new, controlled attempt only after confirming that the corrected forwarding path supports REQUIRETLS and checking suppression again.","Operational guidance: do not automatically suppress the recipient address or domain based on 5.7.30 alone. Inspect the complete response, event scope, forwarding path, and delivery history, then base the suppression decision on the confirmed cause and applicable policy.","[""The message carried a REQUIRETLS requirement, and none of the SMTP servers available for forwarding it provided that support.""]","[""Correlate the response with the intended message, attempt time and stage, system that returned the code, and planned next forwarding step."",""Use logs and configuration to confirm that the message was received with a REQUIRETLS requirement and determine whether the SMTP servers available for forwarding actually support it; do not attribute a specific provider failure from the code alone."",""Stop unchanged retries. After a confirmed routing or support correction, check REQUIRETLS and suppression again, then make at most one controlled attempt.""]","{""sender"":[""Do not manually retry the same unchanged message; confirm that the protection requirement remains intended, then give the sender administrator the complete response and attempt time.""],""sender_admin"":[""Retain the complete response, trace the forwarding stage, and use available logs and configuration to confirm the REQUIRETLS requirement and support across possible next-hop servers."",""Make only a confirmed routing or support correction, check REQUIRETLS and suppression again, and confirm the result with one controlled attempt.""],""recipient_admin"":[""If you manage the system that returned the code or the receiving next hop, inspect route selection and REQUIRETLS support for the specified attempt; correct a confirmed problem or safely give the sender the context needed for remediation.""],""provider"":[""If you operate a managed forwarding layer, inspect its logs, route selection, and REQUIRETLS support, correct a confirmed problem in that layer or give the appropriate administrators precise diagnostic context, and do not trigger suppression from the code alone.""]}","[""5.7.0"",""5.7.1"",""5.7.2"",""5.7.4""]","esc-5-7-30","permanent","infrastructure","unverified","retry_after_correction","no_recommendation","high","false"90"email-error-5-7-4","5.7.4","X.7.4","5-7-4","https://blazalek.com/en/email-errors/5-7-4","security-authentication-policy","permanent_failure","do_not_retry","check_context","[""sender"",""sender_admin"",""recipient_admin"",""provider""]","5.7.4 — Security features not supported","The message was permanently rejected because it used a security feature that could not be supported on the delivery protocol. Do not retry the same unchanged attempt.","Permanent rejection because a security feature in the message could not be handled on the delivery path. Align protocol support or adjust the feature before retrying. Unresolved path gaps can affect deliverability if the same send keeps failing. Do not retry unchanged.","Security features in the message, such as secure authentication, could not be supported on the delivery protocol along the path; code 5.7.4 reports that under pattern X.7.4. In the enhanced status register this unsupported-feature detail is permanent, and the status-code list defines X.7.4 for permanent use only. The numeric reply points to a protocol or configuration gap on the delivery path, not to unauthorized sender identity or an invalid recipient address, and it alone does not name the exact feature or the system that lacked support.","A message that contained security features, such as secure authentication, that could not be supported on the delivery protocol falls under X.7.4. The status-code list description says this detail is useful only as a permanent error, and code 5.7.4 applies it in class 5.","The leading digit 5 denotes a permanent failure of the current attempt. The code alone identifies neither the exact unsupported feature nor the system on the path that could not support it, and it does not establish that the recipient address is invalid.","Operational guidance: stop automatic and manual retries of the same unchanged attempt. Consider a new send only after a confirm change to the security feature, protocol support, or delivery path; check suppression again before the attempt.","Operational guidance: do not automatically add an address or domain to a suppression list based on 5.7.4 alone. Inspect the complete response, the security features used, systems on the path, and event history, then make the suppression decision according to the established cause and applicable policy.","[""The message used a security feature, such as secure authentication, that could not be supported on the delivery protocol.""]","[""Correlate the event with the intended message, attempt time, transaction stage, and systems on the path; use available logs and configuration to identify the security feature and where it could not be supported instead of inferring those details from the code alone."",""Stop unchanged retries; before a controlled new send, confirm a material correction to the feature, configuration, or path and reassess suppression.""]","{""sender"":[""Do not resend the same unchanged message; give the administrator the complete response and attempt context."",""Do not disable or weaken a security feature based on the code alone; apply only a confirm change prepared by the appropriate administrator.""],""sender_admin"":[""Retain the complete response and attempt context, then inspect the message's security features, client configuration, and protocol support on the known path."",""Correct only a confirmed incompatibility or select a path that supports the required feature; check suppression again before a controlled new attempt.""],""recipient_admin"":[""If the code came from a recipient system you manage, inspect its logs, protocol configuration, and supported security features for the specified attempt."",""Correct the confirmed lack of support within your authority if the feature should be supported, or give the sender administrator exact, safe context for the refusal.""],""provider"":[""For the specified attempt, inspect managed-service logs and identify the security feature and protocol segment where it could not be supported."",""Correct a confirmed problem in the managed layer or identify the owner of the required correction; do not trigger automatic suppression from 5.7.4 alone.""]}","[""5.7.0"",""5.7.1"",""5.7.2"",""5.7.8""]","esc-5-7-4","permanent","infrastructure","unverified","retry_after_correction","no_recommendation","medium","true"91"email-error-5-7-7","5.7.7","X.7.7","5-7-7","https://blazalek.com/en/email-errors/5-7-7","security-authentication-policy","permanent_failure","do_not_retry","check_context","[""sender_admin"",""provider"",""recipient_admin""]","5.7.7 — Message rejected for duplicate authentication-results headers","The receiving system reports a permanent rejection under the enhanced code 5.7.7 because the message carried more than one copy of the same X-Original-Authentication-Results header. The status-code list pattern X.7.7 names a message-integrity failure; this catalog's only exact context for the concrete class-5 code comes from one relay that treats a duplicated authentication-results header as a sign of corruption or tampering and refuses the message outright.","In the one exact example this catalog has, 5.7.7 means a spam-filtering relay not attributed to any catalogued provider refused the message at the end of the DATA command because it already carried a duplicate X-Original-Authentication-Results header — a signal the relay reads as message corruption or header tampering, not a quota, address, or content-policy problem. Do not retry the identical message; fix whichever step in the sending or forwarding chain is duplicating that header, then send a clean copy.","SMTP specification defines status-code list pattern X.7.7 as ""Message integrity failure"" and states outright that the pattern can usefully appear as a permanent, transient-persistent, or successful-delivery code, depending on context. Still, this catalog's enhanced status-code status-code list mirror lists X.7.7 as unresolved for every class: neither class 4 nor class 5 has a confirmed status-code list entry here.","The pattern signals a message-integrity failure: a transport system authorized to validate a message could not, because the message was corrupted or altered. SMTP specification (Section 3.8) frames the pattern generically and notes it may serve as a permanent, transient-persistent, or successful-delivery code; it never settles which class holds a confirmed enhanced status-code status-code list entry, and in this catalog neither class does for X.7.7.","The leading digit 5 denotes a permanent failure for this specific message in the observed example: do not repeat the exact same send unchanged. This does not mean the X.7.7 pattern is inherently permanent by definition — SMTP specification itself allows it to be used as a transient-persistent or successful-delivery code too, depending on how a given system applies it. Treat class 5 here as a property of this particular relay's observed behavior in this example, not as a universal trait of the X.7.7 pattern itself.","Operational recommendation: do not retry the same unchanged message to this address — a repeat send carrying the same duplicated header will fail the same way. Find and fix whichever step in the sending or forwarding chain is adding the second copy of the X-Original-Authentication-Results header, then send a new, deduplicated message.","Do not suppress the recipient address based on code 5.7.7: this is a signal about the integrity of one specific message and header hygiene along the sending chain, not a signal about the validity or activity of the recipient address. Suppression decisions should rest on independent, durable signals about the address itself, not on a single message's header-formatting defect.","[""A forwarding step, mailing-list hop, or downstream relay in the chain re-adds an X-Original-Authentication-Results header without stripping the copy already attached at an earlier hop, so the message arrives carrying two identical copies of that header."",""The sending platform or an internal relay chain resends or re-injects a message without deduplicating headers a prior internal step already attached.""]","[""Inspect the outgoing message's raw headers for any header appearing more than once, especially X-Original-Authentication-Results, and trace which step (forwarding, a relay, resend logic) added the extra copy."",""Correlate the response with the recipient or domain and the attempt time; retain the full \""host ... said: ...\"" diagnostic line, since it names both the intermediate relay and the exact duplicated header."",""Fix the duplication at its available information (forwarding, relay, or resend logic) and send a fresh, deduplicated message rather than retrying the identical one.""]","{""sender_admin"":[""Do not resend the identical message; a repeat send carrying the same duplicated header will fail the same way."",""Trace the mail flow (forwarders, relays, internal resend or retry logic) to find which step is duplicating the header, and fix the deduplication there before sending again.""],""provider"":[""If you operate a relay, forwarder, or mailing-list step in this path, strip any X-Original-Authentication-Results header you did not add yourself before re-injecting the message, rather than appending a second copy alongside the original."",""If you operate the receiving filter, keep the diagnostic text naming the specific repeated header, since that text is what lets the sending side find and fix the actual defect.""],""recipient_admin"":[""If your organization's inbound relay applies this same duplicate-header check, confirm your own infrastructure is not the one duplicating the header before advising the sender to change anything."",""Where policy permits, share the exact response text with the sender's administrator so they can identify which specific header repeated.""]}","[""5.7.26"",""5.7.29""]","esc-5-7-7","permanent","content_block","unverified","retry_after_correction","no_recommendation","low","true"92"email-error-5-7-8","5.7.8","X.7.8","5-7-8","https://blazalek.com/en/email-errors/5-7-8","security-authentication-policy","permanent_failure","do_not_retry","check_context","[""sender"",""sender_admin"",""recipient_admin"",""provider""]","5.7.8 — Authentication credentials invalid","Authentication failed because the credentials were invalid or insufficient. Do not retry the same unchanged attempt.","Permanent AUTH failure: credentials were invalid or insufficient. Supply new credentials or fix identity configuration before retrying. Not a recipient-address bounce; repeated auth failures can reflect on sender reputation. Do not retry with the same credentials.","SMTP AUTH failed because the supplied credentials were invalid or insufficient for the attempted session; that is code 5.7.8 under pattern X.7.8. The enhanced status register treats this credential outcome as permanent for the current attempt. The standard places the detail in the security and authentication family, yet the numeric reply concerns client authentication, not recipient addressing, and by itself it does not identify which credential element failed or establish that the recipient address is invalid.","As a response to the AUTH command, X.7.8 means authentication failed because the credentials were invalid or insufficient. Code 5.7.8 applies this detail in permanent class 5; the client should ask the user to supply new credentials afterward.","The leading digit 5 denotes a permanent failure of the current attempt. The code concerns client authentication, but by itself it does not identify which credentials were invalid or insufficient, and it does not establish that the recipient address is invalid.","Operational guidance: stop automatic and manual retries with the same credentials. Consider a new AUTH attempt only after obtaining new credentials or confirming a correction to identity, authorization, or configuration; check suppression again before the attempt.","Operational guidance: do not automatically suppress the recipient address or domain based on 5.7.8 alone. Inspect the complete response, authentication context, event history, and applicable policy, then make the suppression decision in that context.","[""The credentials supplied in the AUTH attempt were invalid or insufficient.""]","[""Correlate the response with the specific AUTH attempt, time, identity used, authentication mechanism, and system that returned the code; use safe logs to determine whether the credentials were invalid or insufficient."",""Stop unchanged retries; before a controlled new attempt, confirm new credentials or a material configuration correction and check suppression again.""]","{""sender"":[""Do not retry with the same credentials; supply new credentials through an approved secure mechanism or give the administrator the complete context without exposing secrets.""],""sender_admin"":[""Stop unchanged retries, inspect the identity, AUTH mechanism, and credential available information, then permit a new attempt only after a confirm correction and another suppression check.""],""recipient_admin"":[""If you manage the authenticating system, inspect safe logs and the applicable authorization for the specified attempt, then correct only a confirmed server-side problem.""],""provider"":[""If you operate a service involved in the attempt, inspect its authentication logs and give the administrator safe context needed to distinguish invalid credentials from insufficient authorization.""]}","[""5.7.0"",""5.7.1"",""5.7.2"",""5.7.4""]","esc-5-7-8","permanent","authentication_failure","unverified","retry_after_correction","no_recommendation","high","false"93"email-error-5-7-9","5.7.9","X.7.9","5-7-9","https://blazalek.com/en/email-errors/5-7-9","security-authentication-policy","permanent_failure","do_not_retry","check_context","[""sender"",""sender_admin"",""recipient_admin"",""provider""]","5.7.9 — Authentication mechanism is too weak","The server permanently refused the AUTH attempt because the selected authentication mechanism was weaker than its policy permits for that user. Do not retry the same unchanged attempt.","Permanent AUTH refusal: the chosen mechanism is weaker than server policy allows for that user. Switch to a stronger allowed mechanism before retrying. A policy mismatch, not a deliverability collapse, but fix it before submission works again. Do not retry unchanged.","Selecting a mechanism the server rates below the strength required for that user account is what code 5.7.9 reports when AUTH returns status-code list pattern X.7.9. The enhanced status register records a permanent refusal for this session detail under class 5. The standard expects a retry with a different, stronger mechanism; the numeric reply alone does not name an allowed alternative, establish wrong credentials, or mark the recipient mailbox address as invalid.","As a response to the AUTH command, X.7.9 means the selected authentication mechanism is weaker than server policy permits for that user. The standard says the client should retry with a new mechanism; code 5.7.9 applies this detail in permanent class 5.","The leading digit 5 denotes a permanent failure of the current attempt. Repeating the attempt without changing the mechanism does not resolve the stated mismatch; the code alone does not identify an allowed mechanism, confirm incorrect credentials, or establish that the recipient address is invalid.","Operational guidance: stop automatic and manual retries with the same mechanism. Make a new, controlled attempt only after confirming and configuring another mechanism that complies with server policy; check suppression again before sending.","Operational guidance: do not automatically add an address or domain to a suppression list based on 5.7.9 alone. Inspect the complete response, account or service scope, AUTH policy, and event history, then make the suppression decision according to the confirmed cause and applicable policy.","[""The client selected an authentication mechanism for the user that was weaker than server policy permits.""]","[""Correlate the response with the attempt time, authenticating user, client, server endpoint, and selected mechanism; use available logs and policy to identify the refused mechanism and an allowed alternative instead of inferring them from the code alone."",""Stop unchanged retries; before a new, controlled attempt, confirm the configuration change and new mechanism, check suppression again, and compare the result.""]","{""sender"":[""Do not make further manual attempts without a change; give the administrator the complete response, attempt time, and account used without disclosing credentials.""],""sender_admin"":[""Retain the complete response and inspect the client configuration, selected mechanism, account, and server endpoint for the specified attempt."",""Configure only a confirmed mechanism that complies with server policy, check suppression again, and make one controlled attempt instead of repeating the unchanged AUTH request.""],""recipient_admin"":[""If you manage the server that returned the code, inspect its logs and the AUTH policy applied to the specified user and mechanism."",""Correct the policy only if it does not match the intended configuration; otherwise give the sender administrator safe information needed to select an allowed mechanism.""],""provider"":[""If you operate an authentication service involved in the attempt, inspect its logs and policy for the specified time, user, and mechanism."",""Correct a confirmed problem in the managed layer or identify the permitted corrective path without requesting disclosure of credentials; do not trigger automatic suppression from the code alone.""]}","[""5.7.0"",""5.7.1"",""5.7.2"",""5.7.4""]","esc-5-7-9","permanent","authentication_failure","unverified","retry_after_correction","no_recommendation","high","false"94