Deploying the Serverless Email Gateway for AWS (Inbound)

Our Serverless Email Gateway (SEG) allow you to integrate SendSafely directly with your Gmail or Exchange mail server for policy-based email encryption. It is commonly used to keep unwanted PII out of your service desk, in conjunction with our ticketing platform integrations such as Zendesk, Freshdesk, or Salesforce.

This article assumes a working knowledge of Amazon Web Services, and Google Workspace or Exchange 365 email administration. Setting up Inbound SEG requires a SendSafely Enterprise plan, and a configuration session with one of our SEG experts. To book this session, please reach out directly to your account representative. 

In advance of this session, you'll want to:

1. Complete the preconfig steps in stage 1.
2. Deploy the CloudFormation template following the instructions in stage 2.
3. Make the configurations in your Google Workspace or Exchange 365 environment detailed in stage 3.

Stage 1: Preconfig Steps

You'll need to perform these steps in advance of our session to configure the SEG for protecting inbound messages:

1. The SEG will need to use static IP addresses for its outbound connectivity. We recommend creating two private VPC subnets within different availability zones that are each behind a NAT Gateway using an Elastic IP (you can use existing subnets if you already have them). You can then update the existing SEG Lambda function to run inside of those two subnets.

NOTE: The VPC must be located in the us-east-1 (N. Virginia) region of AWS. Please take note of the Availability Zone within us-east-1 that each of the above two subnets were placed into.

2. The SEG will need to use a dedicated subdomain for relaying inbound emails. We recommend sendsafely.companyxyz.com. You'll need to set up an A record and reverse DNS entry for each of the NAT Gateway Elastic IPs that map to a hostname within that subdomain (i.e., seg1.sendsafely.companyxyz.com, seg2.sendsafely.companyxyz.com).

• Create an A record for each IP with your DNS provider
• Add a reverse DNS to that hostname from the Elastic IP section of the AWS console

Ensure that the subdomain from this step is listed as a verified domain in the “Verified Identities” section of the AWS Simple Email Service (SES) console. The verified identity must be a domain-level identity (not an individual email address) and must be in the us-east-1 region of AWS. If the subdomain from this step is not already verified, do so now by adding it within the console using these instructions: https://docs.aws.amazon.com/ses/latest/dg/creating-identities.html#verify-domain-procedure

3. The Lambda function will need outbound connectivity over port 25, which is blocked by default in AWS. You will need to submit a request to AWS to remove email sending limitations (unblocks outbound access to port 25) from the two NAT Gateway IP addresses. The form to make the request is here: https://console.aws.amazon.com/support/contacts?#/rdns-limits

Note that the request for AWS to remove SMTP restrictions could take up to 24-48 hours for AWS to process. You'll need to provide the following justification when completing this form:

• Clear/detailed use-case for sending mail from EC2.

Suggested Response:

We are requesting outbound connectivity from our NAT gateway (IP XXXX) in order to use SendSafely's Serverless Email Gateway to protect inbound emails directed at one of our group inboxes. More information on the Serverless Email Gateway and how it works can be found here:

https://blog.sendsafely.com/sendsafely-gateway-protect-inbound-attachments

• Technical explanation of your spam prevention mechanisms, including details regarding your infrastructure and security measures.

Suggested Response:

All of the messages being processed by the gateway will first be routed through AWS SES (inbound-smtp.us-east-1.amazonaws.com). The gateway will drop any messages that appear to be spam or contain a virus by using spamVerdict and virusVerdict attributes passed from SES. The gateway will connect to a very limited set of upstream mail servers that are associated with the group inbox we are protecting.

4. Generate and publish a DKIM key for the subdomain used by the SEG (i.e., sendsafely.companyxyz.com). DKIM keys can be generated using any method you choose. An example of how to generate a DKIM key pair for testing can be found here: https://www.socketlabs.com/domainkey-dkim-generation-wizard/

• Use domain key selector “sendsafely”
• Publish the public key record to DNS and hold on to the private key record; we will need to put it into secrets manager when we do the setup.

Stage 2: CloudFormation Template

Download the YAML file from this URL: https://go.sendsafely.com/seg-inbound-us-east-1

Log into your AWS account and navigate to AWS CloudFormation. Click Create stack. 

Click Upload a template file. Upload the YAML file you've just downloaded. Click Next.

Configure the Gateway Routing Addresses:

• Inbound Email Address. This is the SMTP envelope address that redirected inbound messages will be routed to. This address does not need to be a valid email address but does need to be within a validated email domain (i.e., [e-mail])
• Default Sender Email. This is the email address that will be used to deliver error notifications to users. This address does not need to be a valid email address but does need to be within a validated email domain. We recommend [e-mail].
• Support Email. This is the email address that internal users will be told to contact in the event of an error. This address will also receive an email alert any time the gateway encounters an error that includes the full error details. This address must be a valid address that is monitored. We recommend using your internal IT help desk. 

Below the Gateway Routing Addresses is the Advanced Parameters section. We recommend leaving these to their default values unless you are a Cloud Formation expert and wish to customize the resource names created by the template.

Note: The "Stack Name" will be prepended to all created resources to ensure that they are uniquely named. 

Stage 3: Inbound SEG Setup Steps

Depending on whether your mail server is Exchange or Google, you'll want to follow one of the below sets of instructions for Inbound SEG setup:

Google Workspace Configuration (Mail Routing & Content Compliance)

Step 1 – Set up SMTP Host Entry for Routing

Host: inbound-smtp.us-east-1.amazonaws.com:25

Step 2 – Create a Content Compliance Rule

This is the rule that defines under what conditions email will be routed to SendSafely for protection.

Exchange 365 Configuration (Connector & Mail Flow Rule)

Step 1 – Set up SMTP Connector for Routing (Exchange Admin > Mail Flow > Connectors)

Use the following options when configuring the connector:

• Name: Route Email to SendSafely Gateway
• From: Office 365
• To: Your organization’s email server
• Use: Only when I have a transport rule set up that redirects messages to this connector

• Security Restrictions: Always use Transport Layer Security (TLS) and connect only if the

  recipient’s email server certificate is issued by a trusted certificate authority (CA).

• Smart Host Address:
  • For US Hosted customers, use inbound-smtp.us-east-1.amazonaws.com
  • For EU Hosted customers, use inbound-smtp.eu-west-1.amazonaws.com
• Validation email Address: [e-mail]

Step 2 – Create a Mail Flow Rule (Exchange Admin > Mail Flow > Rules)

Use the following options when configuring the mail flow rule:

• Apply this rule if..
  • Here you will specify the criteria that determines which messages get routed to SendSafely. You have a large degree of flexibility over defining what criteria to use when protecting messages.

• Do the following...
  • Redirect the message to:
    • For inbound (receiving) rules, use [e-mail]

...and...

• Use the Following Connector: Route Email to SendSafely Gateway