TL;DR
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.
What this code means
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.
Provider examples
235 2.7.0 Authentication successfulTechnical meaning
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.
Delivery status
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.
- Class
- Success
- Retry
- Do not retry unchanged
- Suppression
- Check the full context
Retry decision
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.
Suppression decision
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.
Common causes
- 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.
Diagnostic steps
- Inspect the raw SMTP response or DSN, confirm the exact code 2.7.0, and correlate the event with the intended message and send attempt.
- If the code accompanies an SMTP reply, confirm that the basic reply is in the 2xx class and agrees with the enhanced 2.x.x class.
- 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.
Actions by owner
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 administrator
- Classify 2.7.0 as success; do not trigger an automatic retry or suppression solely because of this code.
- Retain the raw response and transaction context, and correct event mapping if the code was routed into rejection handling.
Recipient administrator
- 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.
Sources
These sources define what this enhanced status code means, mainly through the IANA registry and related RFCs. When provider examples appear on the page, they come from that provider's published documentation. Follow the links to read the original wording in context.
- SMTP Enhanced Status Codes — IANA registry of enhanced mail system status codes.
- RFC 5248 — A Registry for SMTP Enhanced Mail System Status Codes — Creates and governs the IANA enhanced status code registry.
- RFC 2034 — SMTP Service Extension for Returning Enhanced Error Codes — Defines how SMTP returns enhanced status codes to clients.
- RFC 3463 — Enhanced Mail System Status Codes — Defines the class/subject/detail model for enhanced status codes.
- Yahoo Sender Hub documentation — Yahoo sender developer documentation, including SMTP protocol examples.
Last verified:
