OZLAN Technical Services

Sender receives bounce message "554 Denied"

Description:
When sending an email to a McAfee SaaS Email Protection client, the sender is receiving the bounce back message “554 Denied.”
Cause:
The error message “554 Denied” is most commonly caused by McAfee SaaS Email Protection Clients having rejected the message as spam. This is either due to the content of the message or the reputation of the sending IP address.
Example Error:
host domain.com.inbound15.mxlogic.net[208.65.144.12] said: 554 Denied (Mode:normal) (in reply to end of DATA command)
Resolution/Workaround:
For McAfee SaaS Customers, please do one or more of the following:

  1. Place the sending domain on the User or Domain-Level allow list in the Control Console. For instructions on how to do this, please consult with the Systems Administrator of your email system.
  2. Send a copy of the message to SaaS_falsepositives@mcafeesubmissions.com. If the message was blocked, the sender can obtain a copy from their Sent Items folder. Messages to this address are not filtered for spam, and all submissions are accepted.
  3. Copy full Message Audit Details showing the 554 Denied response from the Control Console and supply this in an email with a subject of “False Positive” to SaaS_falsepositives@mcafeesubmissions.com
  4. Open a service request with McAfee SaaS Technical Support so we may investigate the cause of this issue and possibly reset the filter that is causing messages to be denied.

For senders who are not McAfee SaaS Email Protection customers, please do one or more of the following:

  1. Contact the intended recipient and ask them to add the sending address or domain to their allow list
  2. Contact the intended recipient and ask them to open a service request with McAfee SaaS Technical Support so that the message can be reviewed as a false positive
  3. Send a copy of the message with the original headers to SaaS_falsepositives@mcafeesubmissions.com.Messages to this address are not filtered for spam, and all submissions are accepted.

See also the related article titled Best Practices for Organizations Sending to McAfee SaaS Email Protection Customers for additional information.

Best Practices for Organizations Sending to McAfee SaaS Email Protection Customers

Any organization sending email should follow standard best practices to prevent their organization’s domain(s) from being blocked or blacklisted.

Even though there may be a valid business relationship with a sender, the McAfee SaaS Email Protection service will block (or quarantine depending upon service settings) any mail that scores as “probable spam” unless that sender’s domain or e-mail address is on one of the available Sender Allow Lists within the service – either domain or user-level.

In some cases email from an otherwise trusted sender may be blocked with a variation of a 554 error or quarantined.

If a sender receives a 554 error on a message that is being sent directly to a McAfee SaaS customer (not a reply or a forwarded message), it is probable that the sending domain or IP address has been “fingerprinted” based on recent sending habits.

Many times, upon investigation, it is found that someone from the sending domain has sent a recent email that met one or more of the following criteria that increased the spam score in our spam detection system.

- A percentage of messages were sent to invalid recipients generating a large number of NDRs. Typically when this is seen, it is taken as a possible directory harvest attack and the spam score elevates accordingly

- Messages sent were received by “honeypots”. Honeypots – or spam traps – are trusted servers around the world set up with dummy e-mail addresses that sit and wait for mail to hit. Mail hitting these servers is automatically classified as spam because the accounts tied to these servers have not been advertised or requested mail. Any mail sent is deemed unsolicited and therefore spam. Again, this is common with directory harvest attacks and the spam score of messages sent from that domain will be elevated accordingly

- Messages that were sent from the sending domain may have been reported by the recipient to their ISP as potential spam. These complaints are reported through various sources and aggregated in the spam score of all inbound messages through the SaaS Email Protection service and may affect the score enough to have the mail either quarantined or blocked. This typically will come about if the sender is not using opt-out links and/or not honoring opt-out links in certain types of messages being sent from their domain

Best-Practices for Senders

While there are no guarantees that any email message will be delivered, an organization can minimize the risk of having their outbound mail blocked by following a few simple guidelines. Among the steps an organization can take include:

- Maintain mailing lists and eliminate any and all invalid email addresses that exist
- Purchase mailing lists only from reputable organizations and do not use lists that may have been purchased more than 90 days prior to any mailing
- Include instructions for recipients to opt-out of future mailings
- Honor any opt-out requests from recipients
- Use third-party mass-mailers (Constant Contact, etc.) to send mass mailings as needed
- Activate and review outbound server logs periodically to ensure there are no unknown mass mailings being sent and that there is not an abnormal number of NDRs being generated


Possible Actions for SaaS Email Protection Customers

Customers using the McAfee SaaS Email Protection service can take any or all of the following steps to work around an issue should it arise:

- Attempt to add the sending domain to the domain-level sender allow list
- Report the issue to their SaaS Email Protection support provider and have the following information available:
o Email address of the sender
o Email address of the intended recipient
o Date of message (within past 7 days)
o Subject of message (not necessary but useful)
o Full bounce message if available

As a last resort, customers can ask the sender to attempt to resend their message WITHOUT their signature block. Many times, the messages are flagged or “fingerprinted” based on a static piece of information to identify messages coming from a sending domain. The most static piece of any messages domain-wide tends to be the signature block. Combining this as a TEMPORARY recommendation while the situation is being investigated further can sometimes allow critical messages to come through while the scoring is being investigated and potentially challenged.

NOTE: the above information is only for straight communication from sender to recipient and does NOT include scenarios relating to replies to existing messages inbound to a SaaS Email Protection customer or messages that were forwarded. These situations need to be investigated fully to identify where the problem may lie (recipient, sender, prior senders in the case of forwarded messages).