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 [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)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.
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:
subdomain.companydomain.com 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 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.