Email Filtering

Our email systems are exposed to vast amounts of spam, viruses, phishing attacks, etc. on a daily basis. Accordingly, in order to offer our email services to customers, we must utilize email filtering techniques to block unwanted emails. While we strive to make these filters as accurate as possible, errors can and do happen. Typically, when an error does occur, it is either illegitimate email getting past our filters or legitimate email getting blocked. It is important to note that our mail servers implement a form of greylisting to help combat spam. Greylisting can and will result in temporarily delayed delivery of email - more about how greylisting is implemented can be found below. Below we further describe our email filtering systems to help inform customers and/or other interested 3rd parties on what we are doing to combat spam, viruses, phishing, etc. while still offering customers email service.

Frequently Asked Questions About Our Email Filtering

  • Can I disable filtering on my domains and/or specific addresses?
    Short answer: no. Long answer: In order to offer email forwarding, the mail servers we are delivering mail to must accept messages from us. If we become known as running mail servers which send spam/viruses/phishing/etc., our servers get a poor reputation and final destination mail servers will stop accepting email from us - if that happens our email forwarding service stops being useful to customers. Therefore, we take the below filtering precautions in order to not propagate spam/viruses/phishing/etc.
  • How will I know if a legitimate email has been blocked?
    Any email that is blocked outright due to filtering will receive a fatal delivery error during the delivery attempt. This means that the sender, assuming their MTA is configured correctly, will receive a bounce message indicating the email was not delivered; therefore, the sender should be aware that the message did not go through.
  • Why is an email taking so long to be delivered?
    We employ greylisting to help reduce spam. This can result in temporary delivery delays. Please see below under greylisting for more information.
  • Will your email forwarding work with SPF records?
    It is true that SPF, as used today, breaks email forwarding. We recognize SPF's benefits and have therefore implemented an email forwarding system that uses SRS as a means to both promote the usage of SPF and to allow email forwarding in a world where SPF becomes more heavily relied on. The SRS source hostname utilized is ""; therefore, you may see this hostname referenced in message headers, bounce messages, etc. - this is normal. Technically speaking, this means we are rewriting the envelope sender on all messages received for forwarding purposes.

Phases of Email Filtering

Our mail filtering occurs at two phases:

  • Connection Filtering
    In this first phase, inbound connections attempting to deliver mail are examined for traits indicative of an illegitimate sender.
  • Content Filtering
    During the second phase, after the connection has passed through connection filters, the email content is examined for traits indicative of illegitimate message content.

Emails must pass all filters in both phases before we attempt delivery. More details as to the specific filtering methodologies can be found below.

Connection Filtering

During connection level filtering, we use a multitude of techniques to determine which connections should be ignored. Some of these techniques include:

  • DNSBL Checks
    For each incoming connection, we query several DNSBLs as a means to determine the sender's reputation. If the connecting IP address appears in some DNSBLs and we determine it has a bad reputation based on tallying the scores of several DNSBLs, we will reject the delivery attempt.
  • Protocol Checks
    As a means to combat the current zombie problem, we utilize some SMTP protocol tests to make sure that the connecting MTA can correctly handle a valid SMTP conversation. If the sender fails to pass these tests, we will reject the delivery attempt.
  • Rate Limting
    We analyze multiple connections from the same sender to determine which senders are potentially attempting to send spam. For example, if one sender repeatedly attempts delivery to non-existent addresses, that can be a sign of a bad sender address.
  • Whitelists
    As we check DNSBLs for senders with bad reputations, we also check for ones that have good reputations. If the sender address is whitelisted, that address is allowed to bypass both greylisting and protocol-level checks.
  • SPF Checks
    We lookup SPF records for all messages during attempted delivery. If the SPF lookup results in a hard fail result, we reject the delivery attempt. If the SPF lookup results in a soft fail result, the message will be subjected to additional scrutiny via lowering spam scoring thresholds.
  • Greylisting
    If a connection passes all of the above tests, and it is not already on one of our delivery whitelists, we subject the delivery to greylisting. This involves telling the sender MTA that we will not accept the delivery at this time, but that they should try again soon. Then if the sender attempts delivery of the message again after 10 minutes, we will accept the delivery and record the sender address as not requiring greylisting on subsequent delivery attempts. The idea here is that many spammers do not bother retrying deliveries like a real MTA would and this therefore cuts down on spam. We are very sensitive to the fact that this does involve removing the real-time aspect of email; we attempt to compensate for this with automated whitelisting. Overtime, as our whitelists improve, this should become less and less of an issue. However, this will involve delivery delays; typically delays should be around 10-20 minutes, but we do not control how long this takes since it is up to the sending MTA to determine the delivery retry interval. This can be very inconvenient when you need an email before you can complete a particular action (i.e. a forgot my login email) and we do apologize. Please understand that around 19 out of 20 delivery attempts made to our mail servers are spam. We have to stop as much spam as possible in order to offer email service; therefore, we are forced to use such techniques. We are working toward improving whitelisting in an effort to minimize this inconvenience.

Content Filtering

Once an email delivery has passed all above connection level filters, we then examine the message itself to determine if that message should be discarded. Some of the techniques employed include:

  • Blocking Potentially Dangerous Attachments
    We block messages which contain files considered dangerous by Microsoft (referred to as "Level 1" file types). These types of files are listed here. If you need to send one of these kinds of files, an easy workaround is to zip the file prior to attaching it to the email. This method has the advantage of being able to filter out unknown viruses.
  • Scan Attachments for Known Viruses
    All attachments under a certain file size are decoded and scanned for viruses. Any messages containing a file that matches a known virus signature are rejected.
  • Phishing and Malware Link Detection
    We use two methods to filter out phishing attacks. First, we apply heuristics to attempt to determine suspicious hyperlinks which may represent phishing attacks. Next, we run all hyperlinks contained in emails through Google's safe browsing system to help find links which target known phishing and/or malware sites. If we determine a message contains links which have a high probability of linking to malware or are involved in a phishing attack, we reject the message.
  • URIBLs
    All links in an email message are looked up in well known URIBLs. These lists are specifically designed to list domains/links that have been found in email messages received by spamtraps. If a message contains links in trusted URIBLs, and our system determines it is spam based on scoring URIBL hits, the message will be rejected.
  • Attachment Size
    Any emails with attachment(s) over 20mb will not be delivered and a bounce will be issued.