If you run your own company mailserver and/or send through device-based email clients, you might find that emails sent when you're out and about suffer unexpected deliverability issues i.e. being marked as spam by receiving systems. Here's a brief guide to using a VPN (Virtual Private Network) to remedy the situation.

Sending email through a VPN

What Happens When You Send On The Move?

When you send an email from your device using an email client (e.g. Outlook, Apple Mail, Thunderbird etc.) and a standard POP3/IMAP mailbox, the email’s journey will look something like this:

Email Journey

When it’s received by the recipient’s mailserver (M2), the details of both the hop from A —> M1, and the hop from M1 —> M2 will be present in the header of the email ..and this will be scrutinised by M2’s spam-filtering system.

Let’s take a look at what those “Received: from” headers might look like, sending from a laptop in a typical office environment to a Gmail address. Note that when reading an email's headers (view headers/source in most mail programs), the route is in reverse i.e. the first hop is the first “Received: from” line, reading from the bottom-up.

A —> M1

Received: from [10.0.1.5] (mainoffice.companydomain.com [214.85.314.321]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailserver.companydomain.com (Postfix) with ESMTPSA id 3D46C41B1E for <recipient@gmail.com>; Wed, 12 Sep 2018 08:59:20 +0000 (UTC)

NOTE: I am using non-existent IP addresses in the examples throughout this article.

This laptop has been assigned the IP address 10.0.1.5 by the office internal network, and the email is being sent through the office's internet-facing dedicated IP 214.85.314.321 (provided by its ISP), which has been set to have the hostname mainoffice.companydomain.com. This hostname when looked-up resolves back to the IP 214.85.314.321, so everything checks out and there's no IP blacklisting (hopefully!).

M1 —> M2

Received: from mailserver.companydomain.com (mailserver.companydomain.com. [132.426.34.45]) by mx.google.com with ESMTPS id s20-v6si492286pgk.87.2018.09.12.01.59.23 for <recipient@gmail.com> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Sep 2018 01:59:23 -0700 (PDT)

It is received by the company mailserver which then delivers it to the Gmail receiving mailserver - all good here.

Now, what might happen to the first hop when you’re out and about:

A —> M1

Received: from [10.124.184.56] (amx-tls3.starhub.net.sg [203.116.164.13]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailserver.companydomain.com (Postfix) with ESMTPSA id 174CD415EA for <recipient@gmail.com>; Fri, 7 Sep 2018 05:39:38 +0000 (UTC)

Here, my mobile phone has been given the IP address 10.124.184.56 by the telco's 4G network, but the important one here is the telco's server amx-tls3.starhub.net.sg with IP 203.116.164.13. This is in pretty good shape since a lookup on the hostname amx-tls3.starhub.net.sg points to 203.116.164.13, and a reverse DNS lookup on the IP points to the hostname. Therefore forward-confirmed reverse DNS (FCrDNS) checks out; this is a weak but useful form of authentication which receiving mailservers use to help determine whether a sender is legitimate or not. However, the public IP 203.116.164.13 was on two major blacklists at the time of send, marring the receiving server's assessment of the legitimacy of the sender - not good.

It can get worse though..

A —> M1

Received: from [10.124.117.97] (unknown [134.215.314.24]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailserver.companydomain.com (Postfix) with ESMTPSA id 204DB144BA for <recipient@gmail.com>; Fri, 04 Sep 2018 05:39:38 +0000 (UTC)

This is an example of sending over a network with no server hostname at all, let alone a fully qualified domain name (FQDN). FCrDNS is therefore broken, the receiving server sees an unknown sender in the chain, AND the IP is on several blacklists.

This last example is actually what is often seen when sending through a regular shared-IP VPN, since anonymity can be one of the goals of VPN usage for some. Unfortunately, the anonymity provided can encourage more dodgy uses of VPNs, leading to IP blacklisting for the shared IPs.

A Word On Anonymity

Aside from security over open/unknown networks, another key reason people turn to VPNs is to provide anonymous browsing. When you browse through a regular shared-IP VPN, you can usually choose from a range of server locations with anonymous IPs to use. These IP addresses may be different every time, plus they are also likely shared by as many as tens of thousands of other users, making tracing your movements online even harder.

The below scenario removes this anonymity factor by making the IP traceable to your business by reverse IP lookup. As I have mentioned, receiving mail-systems don’t treat anonymous senders very well at all, so for business use, you would want the IP to be associated with your company. It’s the same scenario as if you were browsing from a dedicated IP at your office. Most VPNs with dedicated IP options also allow you to choose from their shared-IP server locations as an alternative should you want to dip back into anonymity - we just wouldn’t advise sending email through them!

Achieving A Reputable Sending-Infrastructure Remotely

Essentially, two things are needed:

  • Control over the reputation of your IP
  • A resolveable hostname and corresponding PTR record for the IP so that FCrDNS checks out

This is achievable by using a VPN with a dedicated IP, that also allows setting a PTR record for that IP.

The steps are as follows:

1. Get a compatible VPN (see below for known options)

It needs to be able to support the following:

  • dedicated IP
  • custom PTR record for that IP
  • port 465 or 587 open (for secure SMTP)

2. Set up an A record

Within your company DNS, set up an A record for an unused company subdomain that points to your new VPN dedicated IP.

e.g. subdomain.companydomain.com   3600   IN   A   213.312.21.52

3. Set up a PTR record

Request a PTR record be setup for that IP from the VPN provider that resolves to the subdomain above. The request would look something like:

"Please could you add a PTR record for our dedicated IP (213.312.21.52) that points to subdomain.companydomain.com".

That's it.

Once all of this is in place and resolving correctly, you should now see something like this in the first hop when you send:

A —> M1

Received: from [213.312.21.52] (subdomain.companydomain.com [213.312.21.52]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailserver.companydomain.com (Postfix) with ESMTPSA id 1B8D112C78 for <recipient@gmail.com>; Fri, 17 Aug 2018 04:53:06 +0000 (UTC)

The VPN hostname is now the custom subdomain.companydomain.com (created as an A record in the company DNS) which points to the VPN's dedicated IP (213.312.21.52). The IP also resolves back to subdomain.companydomain.com when looked up, so FCrDNS checks out. And since it is not shared with anyone else, the IP can be kept blacklist-free.

You now have a squeaky-clean, secure setup for sending high-quality email on the move.

Suggested Compatible VPNs

Not many individual/small-business VPNs offer all the necessary features for a perfect sending-infrastructure, but the following VPN providers do (at time of writing); dedicated-IPs, the ability to create a custom PTR record for the IP, and an available port for secure SMTP. Enterprise-level VPNs are not included here, since this issue should already be taken care of in a corporate networking environment. The following are aimed at individuals and small-to-medium businesses wanting to improve their mobile deliverability and security.

For individuals and small teams:

PureVPN

 

For small to medium businesses:

Perimeter 81