TL;DR
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.
What this code means
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.
Provider examples
550 5.7.0 [blocked file] - File attachment is not allowed because they can be used to exploit Winzip (G1C)550 5.7.0 [blocked file] - Your message has been rejected because it contains a banned file attachment (G1A)552 5.7.0 This message was blocked because its content presents a potential security issue. To review our message content and attachment content guidelines, go to File types blocked in Gmail. - gsmtp503 5.7.0 No identity changes permitted. For more information, go to About SMTP error messages. - gsmtp550 5.7.0 Email relay denied ip-address. Invalid credentials for relay for one of the domains in: domain-name (as obtained from HELO and (E)MAIL FROM). Email is being sent from a domain or IP address which isn't registered in your Workspace account. Please login to your Workspace account and verify that your sending device IP address has been registered within the Workspace SMTP Relay Settings. For more information, go to SMTP relay service error messages. - gsmtp550 5.7.0 Email sending denied. For more information, go to SMTP relay service error messages. - gsmtp554 5.7.0 Too many unauthenticated commands. For more information, go to About SMTP error messages. - gsmtp 552-5.7.0 Our system detected an illegal attachment on your message. Please visit http://mail.google.com/support/bin/answer.py?answer=6590 to review our attachment guidelines.smtp;550 5.7.0 Email rejected per sender's DMARC policyTechnical meaning
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.
Delivery status
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.
- Class
- Permanent failure
- Retry
- Do not retry unchanged
- Suppression
- Check the full context
Retry decision
Operational guidance: stop automatic and manual retries of the same unchanged send. Consider a new send only after establishing the cause from the full context and confirming a relevant change in the condition or configuration.
Suppression decision
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.
Common causes
- 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.
Diagnostic steps
- Inspect the raw SMTP response or delivery report and confirm that the enhanced code is exactly 5.7.0 and that the basic reply is in the 5xx class.
- 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.
Actions by owner
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 administrator
- Stop retries of the unchanged send and retain the raw response, time, transaction stage, and system that returned the code; check suppression state and available logs without assuming a specific cause.
- 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 administrator
- 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.
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.
- Common email bounce messages — Rackspace documentation of common SMTP bounce messages.
- Gmail SMTP errors and codes — Official Gmail Help table of SMTP error messages and status codes.
- SMTP Field Manual (community corpus) — Community-maintained reference of provider SMTP responses, pinned locally as evidence.
Last verified:
