When an SMTP connection is received, each command is given a three digit SMTP response code which is used by the mail servers to indicate a response. For further details on SMTP codes and severities, see RFC-5321 section 4.2.1. There are several types of SMTP response codes, but the ones you are most likely to see when interacting with Mail Assure are:
- Positive SMTP Response
- 2XX - Successful acceptance of the command
- 3XX - Positive response requesting more information from the sending mail server
- Negative SMTP Response
- 4XX - Temporary failure of the command, but the action could be completed if tried again
- 5XX - Permanent failure of the command
Typically, SMTP error codes will be followed by a further three digits called the SMTP enhanced status code. This provides more detail on what caused the response.
e.g. 554 5.3.4 - Message size exceeds fixed maximum message size or 250 2.6.0 - Queued mail for delivery
For further details on enhanced status codes, see RFC-3463
SMTP response codes can be found within mail server logs and within delivery status notifications (DSN) or non-delivery report messages (NDR's).
This is not a definitive list, more error codes exist than these. The below SMTP response codes are examples only.
Positive SMTP Responses
Accepted (2XX)
Connections that display the 'Accepted' response have been accepted for delivery but the message may have not necessarily been delivered to the recipients mailbox.
- 220 - The SMTP server is ready
- 250 - The requested connection action was completed successfully
Accepted More Information Needed (3XX)
The command has been accepted, but the requested action requires further information from the sending server in the form of another command containing the required information.
- 354 - The SMTP server is waiting for the message content to be transmitted, for example: "enter message, ending with "." on a line by itself"
Negative SMTP Responses
If immediate delivery of the message fails, it will be retried automatically by most compliant servers. If the destination mail server permanently rejects the command, a rejection ('bounce'/NDR) is sent to the sender by the senders server.
Temporary Rejection (4XX)
Commands which have been temporarily rejected, causes the message to stay stored on the sending mail server. Legitimate mail servers always automatically retry delivery of such messages. Depending on the reason of the temporary reject, the message could get accepted at a subsequent delivery attempt.
- 421 - The SMTP service was unavailable, try again later
- 450 - The requested action was not taken because the users mailbox was not available
- 451 - The requested action was aborted due to a local error in processing. Message was not sent.
- 452 - The command was aborted because of a lack of storage on the server
- 454 - TLS not available due to a temporary reason. Encryption is required for requested authentication mechanism
- 455 - The server cannot deal with the command at this time for an unspecified reason
It's always possible to Allow list the sender to disable any checks and to ensure that the message will get accepted as soon as it's retried by the sending server.
Greylisted
A message was temporarily rejected due to greylisting. This technology is only applied to new IP addresses which do not have a good reputation yet in our global systems. We do not apply "classical greylisting" so this will not cause any delays on your legitimate traffic.
You have been denied authentication
This means that you have used incorrect outgoing authentication details too often in a short period of time. To resolve this, use the correct authentication details and wait a few moments and try again. This is to protect against brute-force attacks on your SMTP credentials.
Unable to verify destination address
The destination server is unreachable or temporarily rejecting email traffic. You will have to check the destination route set to ensure delivery is attempted to the correct server. The logs on the destination server should show why it is not accepting the delivery attempts.
Unable to verify sender address
The system was unable to verify the sender using a sender callout. You will have to check the sending mail-server to verify why such callouts could not be done. When the sender verification option is used in the outgoing user settings, then each specific sender address must be verifiable like this.
Internal error
An internal error occurred within the filter, this should automatically resolve itself upon reattempt at delivery. If not, and you continue to see issues please contact support .
Per-minute connection limit exceeded
The sending server has exceeded their per-minute limit of connections made.
Too Many Connections
The sending server has exceeded their limit of connections made.
Too Many Concurrent SMTP Connections
There is a hard-coded limit of 10 concurrent SMTP connections per IP to protect the systems against attack.
Ensure that the sending mail server only opens up a maximum of 10 concurrent connections to avoid hitting this limit.
Too many messages. Please wait for a while and try again.
This indicates that the outgoing user/authentication method has exceeded the maximum amount of messages that can be sent within a given time frame as configured in the Manage Authentication page at Admin level or Manage Users page at Domain level. In cases where the limits need to be amended or disabled, please see the Edit an Outgoing User/Authentication method page.
Mail for this domain cannot be accepted right now; please retry (Unable to handle in active connection.)
Within a single SMTP connection, it is possible to deliver a message to different recipients. The SMTP protocol only allows you to either "accept" OR "reject" the email, without distinguishing between the different recipients. When one of the recipients has different filtering settings, we cannot "accept" or "reject" the message as the classification may differ per-recipient. In such cases we return a temporary rejection, so that the sending server can retry delivery individually for the recipients allowing the filter to classify each message separately.
Most SMTP servers retry immediately, and hence there will be no delivery delay. If all recipients are sharing the same filter settings, the message will be immediately accepted (or rejected) for all recipients without this temporary reject. If a delay is experienced, the sender can instead configure their server to either immediately retry (to prevent such delay), or to open a separate delivery connection for each recipient.
Permanent Rejection (5XX)
Messages which have been permanently rejected are blocked by the system. Generally these messages can be reviewed in the Spam Quarantine page. If the message is reviewed and deemed not spam by a user, they can be released from the quarantine on this page.
- 500 - A syntax error was encountered and the command could not be recognized
- 501 - A syntax error was encountered in the command parameters or arguments
- 502 - The supplied command is not implemented
- 503 - The server has encountered a bad sequence of commands
- 510 - The message could not be delivered, check the recipient address
- 512 - The recipient domain cannot be found
- 515 - destination mailbox address is invalid
- 521 - The recipient domain does not accept mail
- 523 - Server limit exceeded. The message was too large
- 541 - No response from host
- 542 - Bad connection
- 550 - The requested command failed because the user's mailbox was unavailable, or the recipient server rejected the message due to high probability of spam, or the message was classified as spam and may not be delivered
- 551 - The intended recipient mailbox was not available on the recipient server
- 552 - The message was not sent because the recipient mailbox does not have adequate storage space
- 554 - The transaction failed. No other information given.
It's always possible to Allow list the sender to disable any checks and to ensure that the message will get accepted as soon as it's retried by the sender.
There are many reasons behind messages receiving a 5XX SMTP response:
File name exceeds maximum length
This occurs when attachments in the message have a file name longer that 255 characters. In order to sort this issue, please make sure you keep the file name under 255 characters. Most operating systems cannot handle more than this number.
Lines in message were longer than user maximum
This means that a line within the email is longer than the set maximum. The RFC 5322 (SMTP 5321) specifies a maximum line length of 998. Normal email clients always enforce this limit to avoid delivery problems. The problem should be resolved at the sender side, or the check can be disabled.
Message had more parts than the user maximum (Too many MIME parts)
This refers to the amount of MIME parts that a message contains. The default limit is set to 100. This can be de-passed and triggered with excessive amounts of attachments or other MIME parts.
Sending server used an invalid greeting
The sender has used an invalid HELO/EHLO. This could be either because an IP address is used for the HELO, or because the HELO contains an invalid character, for example: underscore (_).
The RFC states that a FDQN (Fully Qualified Domain Name) MUST be used.
SPF failure
The SPF (Sender Policy Framework) has been broken. If this is legitimate mail, then this could be due to a forwarding construction. Please see our Set up SPF page for more information. Please note, releasing and training large amounts failed SPF messages, can result in the sending domain being skipped from further SPF checks.
Sending server is missing DNS records
The sending server is missing MX records or A records. Please note that any DNS changes only take effect after the initially set TTL has expired, so messages sent before the TTL has expired will likely encounter the same problem.
Destination address does not exist
The destination server is rejecting the connection with a 5xx permanent failure. The logs on the destination server will show why the message was rejected. You'll have to resolve the problem on the destination server to ensure it accepts the email.
Recipient address rejected by destination
The destination server is rejecting the recipient callout with a 5xx permanent failure. The logs on the destination server will show why the message was rejected. You'll have to resolve the problem on the destination server to ensure that recipient callouts can be used.
Date header far in the past or future
This means that the date in the header of the email is more than the default 7 days in the past or future. Releasing this will only deliver the message to the recipient. This is something the sender will need to resolve.
Bad header count (Message badly formed)
Emails should never contain duplicate headers such as "Subject" or "To". In cases where duplicate headers are found, the message will be rejected until the underlying bug is fixed in the email sending software.
Subject contains invalid characters
When a message is rejected with "550 - Subject contains invalid characters" the email subject will contain non-ASCII characters, which are not allowed by the RFC. To include non-ASCII characters in subjects, the subject is required to be properly encoded, for example with UTF-8. Any normal mail client will automatically handle that for you, so it's likely a bug in a custom written script that generated the invalid subject. The evidence header for this classification will show "Badly formed Subject header".
Heuristics.LinkChecks
In cases where your message was rejected with Heuristics.LinkChecks.ProbableMalware and Heuristics.LinkChecks.ProbablePhish in the rejection message, it means it has been (recently) listed by Google as hosting malicious files.
Header is too long
Mail Assure by default will reject emails with excessively large header values, as this is a common indicator for illegitimate emails.
Restricted characters in address
If your message has been rejected with "550 - restricted characters in address" in the rejection message, it means that the recipient address contains a character that is not accepted by the system, for example: "&". You can control which characters are allowed for a domain on the Configure Domain Settings page.
Relay not permitted
When a message has been rejected with "550 - Relay not permitted", it means that delivery was attempted to the incoming filtering service on port 25 to a domain which has not yet been added to the filtering solution. To resolve this, add the domain to the incoming filtering service.
If you're trying to use the outgoing filtering service, ensure to use the outgoing filtering service port 587 instead.
Message submission is for authorised users only!
This indicates you are attempting delivery via our outgoing email filter on port 465/587 (default). If you're receiving this response to an incoming email delivery attempt, your mail server is wrongly set up (and likely a misconfigured version of Lotus Domino). If you're trying to send outgoing email, please ensure to provide a valid username/password to authenticate.
Legitimate bounces are never sent to more than one recipient
When the message is rejected with "Legitimate bounces are never sent to more than one recipient" in the rejection message, it means that the mail server was trying to deliver an email to multiple recipients with an empty "MAIL FROM:<>" (return-path). The SMTP RFC 5.3.2.1 indicates that null sender emails (bounces) can never be sent to multiple recipients, so there may be a misconfiguration on the mail server.
We do not accept message/partial messages here
Before people had a permanent internet connection, sending larger emails was time-consuming and often failed. Therefore older email clients sometimes still break up large emails into separate parts for delivery. This old email feature is not used anymore nowadays, and imposes a severe risk as it makes detection of viruses impossible (as viruses would be split over separate emails before being assembled again by the destination email client).