Security & Authentication

How to send emails through a VPN

Leo Hatton

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:

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 [] ( [214.85.314.321]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 3D46C41B1E for <>; 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 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 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 ( [132.426.34.45]) by with ESMTPS id s20-v6si492286pgk.87.2018. for <> (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 [] ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 174CD415EA for <>; Fri, 7 Sep 2018 05:39:38 +0000 (UTC)

Here, my mobile phone has been given the IP address by the telco's 4G network, but the important one here is the telco's server with IP This is in pretty good shape since a lookup on the hostname points to, 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 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 [] (unknown [134.215.314.24]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 204DB144BA for <>; 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.

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.

How to achieve a reputable sending infrastructure remotely

Two things are needed:

  • Control over the reputation of your IP
  • A resolvable 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.

Step 1: Get a compatible VPN

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)*

*preferably port 587, since 465 has officially been deprecated (although still largely supported)

Step 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.

For example:   3600   IN   A   213.312.21.52

Step 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".

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] ( [213.312.21.52]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 1B8D112C78 for <>; Fri, 17 Aug 2018 04:53:06 +0000 (UTC)

The VPN hostname is now the custom (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 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.

Get all of our updates directly in your inbox.
Subscribe to the newsletter.