Outbound connections over port 25 blocked

Browse by products and services

  • Applies to: Grid
    • Difficulty: Easy
    • Time Needed: 10
    • Tools Required: None


We block all outgoing mail attempts that establish a direct MX connection over port 25 on the Grid platform. This is NOT intended to have any impact on your ability to send/receive email using programs like Microsoft Outlook and Apple Mail.  Grid webmail and all third-party mail clients function as normal, including on port 25, for incoming connections.

This change is targeted at scripts and applications designed specifically to override the normal path of email sending by acting as a mail transfer agent (MTA). The large majority of popular applications on the Internet do not fall under this category. In other words, 99% of our customers will remain unaffected.

Blocking this activity will reduce outgoing spam, which will in turn help our reputation with external, third-party RBLs (Real-time Blocklist) and ISPs (Internet Service Providers). Ultimately, the best way to prevent being listed is to block spam from leaving our network.


This change only blocks OUTBOUND access to port 25. Establishing an SMTP connection through an email application or script is considered an INBOUND connection. Nothing will change in that regard. Customers can continue using email just as they have been with port 25. This change only affects outbound SMTP connection attempts over this specific port.


In general, a MUA (mail user agent) connects to a relay (a single, specified mail server) which handles looking up the MX (mail exchange) record for a destination email address, and delivers the message. Most PHP/CGI scripts work as an agent and default to using the local mail server as the relay.


Many scripts are configurable, allowing you to specify what server you want to use as your relay. If your script does not specify a relay, it will default to using 'localhost.' In this case, you would be unaffected by this change. If you are using your domain name, e.g. example.com or your access domain, you also will be unaffected by this change.


In most cases, any script that you have running on your third-party applications, such as Wordpress or Drupal, will continue to work. In almost all cases, these scripts rely on using the local sendmail function. Unless you specifically made an alteration to any provided scripts, you should be fine. This would extend to almost all uses of the PHP mail() function as well. There are going to be some applications that might stray from the "norm" in this regard. In these cases, we will make a best effort to help you find a solution after this change goes into effect. Simply open a support request inside the AccountCenter and we will help you.

Mail Hosted Externally

If you have specified a relay that is not hosted on your Grid, you will be affected by this change. This may be the case if you are using Google Apps or another third-party email provider and you have specified a host name that points to that service. Most email providers will allow you to use port 587 or port 465 to relay mail. Since these ports are unaffected, making this change is the best option.

Direct to MX

This is the method we are disabling. Some scripts, typically spammer tools, try to be sneaky and take on the role of the relay. This method is referred to as "direct to mx." The script performs a DNS lookup to determine the MX for an email address, connects to that MX on port 25, and then hands the message off directly. For a more detailed explanation of this, please click here.

Direct to MX is almost exclusively used as a spammer technique. Large volumes of email can be transmitted while avoiding any kind of spam detection on the relay. Because any PHP/CGI script could be written to utilize the this method, any script of this nature could be affected by this change.


Header Check

If you are uncertain if a script is utilizing this method or not, it probably is not. However, here is a test you can try.

Send yourself an email via your script. Once you have received the message, you will need to look at the full headers. If you see a line similar to the following, then you will not be affected by this change:

Message-Id: <E1LjZft-0002sn-9o@cl15.gs01.gridserver.com>

The important part here is seeing gs01.gridserver.com. This might be slightly different depending on which cluster your Grid service resides. Currently, we have 9 clusters with the following addresses:

  • Cluster.01 - gs01.gridserver.com
  • Cluster.02 - gs02.gridserver.com
  • Cluster.03 - c03.server-system.net
  • Cluster.04 - c04.mtsvc.net
  • Cluster.05 - c05.mtsvc.net
  • Cluster.06 - c06.mtsvc.net
  • Cluster.07 - c07.mtsvc.net
  • Cluster.08 - c08.mtsvc.net
  • Cluster.09 - c09.mtsvc.net

Open a Support Request

We know there will be certain scripts/applications that might be affected by this change. However, we think it will be a very small percentage of our customers. In almost all cases, we can find a solution that will work for you. We strongly believe that blocking this activity far outweighs any minor changes we can make on your behalf. Just let us know and we will help. We also encourage participation in our User Forums. We have an ongoing thread about this policy change here.