Knowledgebase
Best Practices for Organizations Sending to McAfee SaaS Email Protection Customers
Posted by on 09 June 2014 12:05 PM
Best Practices for Organizations Sending to McAfee SaaS Email Protection Customers
Question:

Best Practices for Organizations Sending to McAfee SaaS Email Protection Customers
Answer:

 

 

Info

 

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 Excelmicro support  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).



Additional Information

For information on the CAN SPAM Act see the following:
http://business.ftc.gov/documents/bus61-can-spam-act-compliance-guide-business

 


ERROR: This domain name does not match domain registered in the license key file (cms.orlinpilot.com), allowed domains: support.excelmicro.com, please change the product path to match the domain under Admin CP > Settings > General Settings
This product will not work properly unless untill that value is changed.

For more information please contact Kayako support at https://my.kayako.com