Enabling collaboration for health and social care
Information and Guidance for the Email Gateway Service for N3 Organisations
The Email Gateway Service provided by NHSmail offers:
- The Relay service for inbound/outbound spam and antivirus scanning for N3/HCSN hosted *.nhs.uk email domains. N3 is now known as the Transition Network. Further information can be found on the NHS Digital HSCN pages: https://digital.nhs.uk/health-social-care-network
- Inbound/outbound spam and antivirus scanning for the NHSmail service
This guidance page offers information about the Email Gateway Service as well as configuration details. If you have been referred to this page, please review the guidance below, to address your query.
The use of static IP addresses is not supported by the Email Gateway for NHSmail. All configuration should be done based on N3/HSCN DNS pointing to relay.nhs.uk (see how I configure my Organisation). It is possible that organisations can point directly to the end points of 'relay.nhs.uk', but these may change with little or no notice, and therefore availability of any/all IP’s cannot be guaranteed. It is equally important that the Email Gateway should not directly be restricted by connecting IP, connecting IP's may change over the service lifetime.
As the Email Gateway services multiple interfaces (N3/HSCN, NHSmail and internet), the Email Gateway does not provide corresponding helo/ehlo responses to N3/HSCN DNS. Therefore, N3/HSCN organisations should not use the helo/ehlo response as a form of validation against the Email Gateway.
Yes, the Email Gateway supports opportunistic TLS, meaning, if an organisation’s MTA attempts to connect to the Email Gateway using TLS then it will use it. But, TLS is not enforced or required for a connection. This means that there is no end to end guarantee of encryption as your sending MTA may use TLS but when the relay service attempts to connect to the next hop to deliver the message after scanning that system may not support or use TLS.
The Email Gateway only supports message transfer on port 25 meaning all traffic (TLS or otherwise) should be directed to the Email Gateway over port 25 only.
The Email Gateway supports only a modern set of cipher suites. In order to successfully use TLS, a corresponding cipher suite must be used with the Email Gateway otherwise the connection will fail to be established. The following is a list of supported ciphers by the Email Gateway.
Note 1: It should also be noted that a number of these cipher suites do not meet UK Government or NHS security requirements.
Note 2: Although no longer supported for use, it has been found that Windows 2003 servers require a patch to match the cipher settings supported by the Email Gateway. The following Microsoft patch for Windows 2003 has successfully been deployed to alleviate default incompatibility (https://support.microsoft.com/en-us/kb/948963). This stated fix cannot be guaranteed in every circumstance.
To use the Email Gateway, local organisations must ensure inbound/outbound connectivity to the following IP addresses is available from the organisation’s sending/receiving Message Transfer Agents (MTAs):
To test the connection to the Email Gateway IP’s, logon to the local MTA, and run the command ‘telnet <IP> 25’. The response should come back with: 220 SMTP-S or 220 SMTP-H. Below is an example of the successful output:
# telnet 22.214.171.124 25
Connected to 126.96.36.199.
Escape character is '^]'.
When configuring a connection to the Email Gateway by MTAs or applications, a hardcoded IP address is not recommended or supported. DNS should be used as it allows for dynamic service resiliency and failover.
What if testing fails?
1. Ensure the test is being executed from your MTA on N3/HSCN, and an appropriate PTR record exists.
2. Confirm your organisation's firewalls contain the following full IP ranges used for NHSmail (not just the IP addresses listed) which are: 188.8.131.52/26 and 10.222.62.0/24
If testing still fail contact the NHSmail support, as listed in the Where can I get help? section.
The NHSmail service has protective DNS records using Sender Policy Framework (or SPF). SPF can be used to assist with anti-spoofing as well as overall assist with IP ratings related to blacklisting. If a local organisation wishes to implement SPF for their own MX record, they can create a single record referencing the domain nhs.net.
To have an entry for your organisations *.nhs.uk domain you submit a request to the NHS Digital DNS team to update your DNS record (firstname.lastname@example.org) with a new DNS record of type “TXT” with the following information:
v=spf1 include:_spf.nhs.net ~all
or, more specifically, v=spf1 include:_spf.nhs.net ip4:<IP1> ip4:<IP2> -all (where, IP1 and IP2 are a local organisations MTAs).
The above TXT record will inherit the configuration from the master nhs.net SPF record (which would be updated with any changes to IP for the Email Gateway service). For other information and guidance regarding SPF please refer to the Open SPF Project.
The decision to use an SPF record for your organisations *.nhs.uk domain is highly recommended and encouraged.
~all is a softfail SPF record, typically this setting allows messages to be delivered.
-all is a restrictive SPF record, it would be recommended to use softfail as a test before implementing restrictive SPF.
The most important thing for SPF, is to get the record correct when creating it, otherwise sending/receiving email can be restricted. There are several SPF testing tools (such as MX Toolbox - mxtoolbox) for testing SPF records. Ensure testing is done before and after implementation confirming mailflow is not impacted by new SPF records.
See the public SPF project for more details on SPF: Open SPF Project.
Note once set other systems such as internet based marketing services that pretend to send from your system will get email rejected if they set the from address to be that of your nhs.uk domain.
Domain-based Messages Authentication Reporting and Conformance (DMARC) builds upon SPF and DKIM, and adds a reporting functionality. DMARC is an additional TXT DNS record, and can take a variety of options. The managed domain of nhs.net has DMARC enabled.
A *.nhs.uk organisation can set up a DMARC record by creating an internet facing DNS TXT record in a format similar to the following:
_dmarc.<organisation>.nhs.uk TXT v=DMARC1; p=reject; rua=mailto:<feedbackemailaddress>
As there are various flags/options around DMARC, please review DMARC.org ( https://dmarc.org/) for options for specific configuration.
For the domain nhs.uk, the Email Gateway support up to 3 levels of sub-domains for email transfer. No subdomains should be used to send or receive emails greater than 3 subdomains deep. The below example will illustrate the sub-level support of the email gateway for the domain *.nhs.uk:
Top Level and 1st Sub-Domain
Example domain: x.nhs.uk
Example email: email@example.com
2nd Level Sub-Domain
Example Domain: x.x.nhs.uk
Example Email: firstname.lastname@example.org
3rd Level Sub-Domain
Example Domain: x.x.x.nhs.uk
Example Email: email@example.com
Any sub-levels greater that 3 (as illustrated above), are not supported and may be rejected by the Email Gateway service.
The Email Gateway tracks SPAM and malicious files from N3/HSCN based organisations. If these organisations send large volumes of SPAM or malicious files to the Email Gateway, the Email Gateway will block the offending organisation at the internet protocol (IP) level from sending any mail for up to four hours. This block is done to protect the greater base of N3/HSCN *.nhs.uk organisations who rely on the Email Gateway.
The Email Gateway monitors the volume of email sent from all accounts. This monitoring is in place to protect against the potential of compromised accounts, compromised systems and ultimately the blacklisting of the Email Gateway. If there is an account designated to send high volumes of email, please contact the Email Gateway
firstname.lastname@example.org for the account to be added to a high-sender whitelist.
As a Local Email Administrator, you should set a transport rule so that any junk / spam emails received are delivered to the end user’s junk email folder by default. Any junk / spam emails that pass through the NHSmail or the Relay service always have the following header information – “X-SPAM-JUNK-FOLDER: TRUE".
End User Queries
Why the users receive the following stamp at the begining of the email "This message was sent from an email address external to NHSmail but...." when I sent email from my nhs.net account?
This is NHS spoofed stamp which means that that when the system examines the headers of the emails it detected it as not originating directly from an nhs.net account. This usually happens when the sending server is not part of NHS.NET environment but is configured to send emails as nhs.net in the FROM field.
In order to prevent this the local administrator needs to change the sending domain to something different than NHS.NET
Why do I receive the following response from Email2SMS "1 033 ERROR – the request is not authenticated" while sending SMSs from my NHS.NET account?
This error message indicates that the NHS.NET user is not whitelisted on Soprano. User needs to contact their local administrator who in turn would need to contact Soprano (email@example.com) and request them for the NHS.NET address to be whitelisted.