Outbound Routing and Security Test Cases

Document created by user.oxriBaJeN4 Employee on Sep 18, 2015Last modified by user.oxriBaJeN4 Employee on Mar 27, 2017
Version 3Show Document
  • View in full screen mode

As part of the Mimecast Connect process, outbound emails from your environment are routed through Mimecast and thereafter are delivered to the external recipient. In addition, the security settings with regards to encryption and spam scanning are implemented to safeguard email transmissions to and from Mimecast.

 

The following test cases will assist you with the configuration of email routing and security elements of the Mimecast service for these outbound emails. The test cases presented are the minimum tests required in order to validate the core/base functionality of the service and are by no means exhaustive.

 

Customers and partners are encouraged to develop additional test cases to suit their specific email environment requirements.

Test Numbering Conventions:

  • MANxx = Mandatory Test Case
  • OPTxx = Optional Test Case

Tip: You can copy/paste this page to a Microsoft Word 2010 document and above to create your own editable test plan (including Titles and Tables).

Outbound Email Configuration

 

Outbound Authorized IP Addresses

 

Test #: MAN01Executed by:
DateOverseen by:
Description: The IP Addresses used by customer email servers to send email must be added to Mimecast as authorized Outbound addresses for email to be accepted for delivery.
ActionResult
  1. Obtain the Public IP Addresses of all of your internet facing MTA’s that will be sending email to Mimecast.
    1. Verify that the Public IP Addresses and CIDR (Mask) are correct:
    2. Log in to the Administration Console.
    3. Click on the Administration menu item.
    4. Click on the Gateway | Authorized Outbound menu item.
  • PASS (Expected)
  • FAIL

Corrective Action for FAIL Results:

  1. Contact Mimecast Support (support@mimecast.com) to Add/Update/Remove IP Addresses as required.

Comments and Observations:

  • Office 365 customers that have no on-premise MTA’s do not need to have authorized outbound IP addresses specified on their account.

 

Internal Domains

 

Test #: MAN02Executed by:
DateOverseen by:
Description: The SMTP Domains (in addition to the authorized IP) of the customer should be added in the Mimecast Administration Console in order for email to be accepted for inbound/outbound delivery.
ActionResult
  1. Obtain a list of your SMTP Domains
  2. Verify that the domains listed match the list you have generated:
    1. Log in to the Administration Console.
    2. Click on the Administration menu item.
    3. Click on the Directories | Internal Directories menu item.
  • PASS (Expected)
  • FAIL

Corrective Action for FAIL Results:

  1. Contact Mimecast Support (support@mimecast.com) to Add/Update/Remove domains as required.

 

Opportunistic TLS

 

Test #: MAN03Executed by:
DateOverseen by:

Description: Opportunistic TLS allows email servers to negotiated encrypted connections where supported increasing the overall security of your messaging infrastructure.

It is highly recommended that organizations implement Opportunistic TLS for all inbound/outbound connections as a default then where required implement Enforced TLS for specific domains or communications.

ActionResult

Verify that a Secure Delivery Policy exists:

  1. Log in to the Administration Console.
  2. Click on the Administration menu item.
  3. Click on the Gateway | Policies menu item
  4. Open the Secure Delivery policy.
  5. The policy values should be configured as follows:
    1. From: Everyone
    2. To: Everyone
    3. Select Option: Secure SMTP Where Possible
    4. Encryption Mode: Strict – Trust Enforced
    5. SSL Mode: Default
    6. Date Range: All Time
  • PASS (Expected)
  • FAIL

Corrective Action for FAIL Results:

  • Create a new Policy or update an existing Policy.

 

Auto Allow Policy

 

Test #: MAN04Executed by:
DateOverseen by:

Description: Auto Allow Policies allow Mimecast to learn the communications patterns and peers of our customers to differentiate between known good traffic and unknown / suspicious emails.

ActionResult

Verify that an Auto Allow Policy has been implemented:

  1. Log n to the Administration Console.
  2. Click on the Administration menu item.
  3. Click on the Gateway | Policies menu item.
  4. Open the Auto Allow policy.
  5. The policy values should be configured as follows:
    1. From: Everyone
    2. To: Everyone
    3. Auto Allow Policy: Apply Auto Allow
    4. Date Range: All Time
  • PASS (Expected)
  • FAIL

Corrective Action for FAIL Results:

  • Create a new Policy or update an existing Policy.

 

Auto Allow Creation Policy

 

Test #: MAN05Executed by:
DateOverseen by:

Description: Auto Allow lists are generated systematically based on emails sent by your organization to external recipients. These lists are then used when applying the Auto Allow Policy on inbound email traffic.

ActionResult

Verify that an Auto Allow Policy has been implemented:

  1. Log in to the Administration Console.
  2. Click on the Administration menu item.
  3. Click on the Gateway | Policies menu item.
  4. Open the Auto Allow Creation policy.
  5. The policy values should be configured as follows:
    1. From: Internal Addresses
    2. To: External Addresses
    3. Select Option: General AAL Entries
    4. Date Range: All Time
  • PASS (Expected)
  • FAIL

Corrective Action for FAIL Results:

  • Create a new Policy or update an existing Policy.

 

Domain Authentication - SPF Records

 

Test #: MAN06Executed by:
DateOverseen by:

Description: Sender Policy Framework (SPF) validates the connecting IP address by looking up the DNS record for the domain in the envelope MAIL FROM or HELO/EHLO. It can tell you whether the IP connecting to Mimecast is permitted to send mail for that domain.

Customers who implement SPF records must update these to include the Mimecast Servers as authorized senders.

ActionResult
  1. Verify that your SPF Records are correct:
    1. Open http://www.mxtoolbox.com in a web browser
    2. In the Domain Name box type spf:yourdomain.com
    3. In the record that starts with v=spf1, verify that the results returned contain the text "include:_netblocks.mimecast.com".
  • PASS (Expected)
  • FAIL

Corrective Action for FAIL Results:

  • Update SPF Record to include the Mimecast IP Ranges.

Comments and Observations:

  • Organizations that do not employ SPF records should expect this test to fail, as no such record exists – it is recommended to add SPF records, however, this is not mandatory.

 

Domain Authentication - DKIM

 

Test #: OPT01Executed by:
DateOverseen by:

Description: DomainKeys Identified Mail (DKIM) validates the contents of the message body and headers by creating a cryptographic hash (or signature), and adding it as a new header to the message.  It confirms that the message's content was sent from a specific domain by matching the signature to the DNS records by verifying the signature using the DNS record published by the sending domain.

ActionResult

Verify your DNS Authentication Definition Settings:

  1. Log in to the Administration Console.
  2. Click on the Administration menu item.
  3. Click on the Gateway | Policies menu item.
  4. Open the DNS Authentication definition.
  5. Verify that a definition has been created for each outbound SMTP domain.
  6. Verify that each definition contains the public key, domain, selector and DNS Address.
  7. Click Check DNS to ensure the address has been added to your Public DNS (if failed create the necessary record).
  • PASS (Expected)
  • FAIL

Verify your DNS Authentication Definition Policy:

  1. Log in to the Administration Console.
  2. Click on the Administration menu item.
  3. Click on the Gateway | Policies menu item.
  4. Open the DNS Authentication policy.
  5. Verify that the appropriate policy for each outbound domain is configured:
    1. From: yourdomain.com
    2. To: Everyone
    3. Select DNS Authentication: yourdomain.com definition
    4. Validity: All Time
  • PASS (Expected)
  • FAIL

Corrective Action for FAIL Results:

  • Create / Update relevant Definition, Policy and DNS Records

Comments and Observations:

  • Domain Keys (DKIM) is an optional configuration that is highly recommended to provide additional layers of identification for emails originating from your email systems.

 

 

Test #: OPT02Executed by:
DateOverseen by:

Description: Mimecast Stationery allows organizations to create HTML & TXT Stationery and Disclaimer elements that are added to outbound email at the gateway level. Organizations wishing to use this functionality should create the Stationery and Policies before they start to send outbound email.

ActionResult

Verify your Stationery Layout:

  1. Log in to the Administration Console.
  2. Click on the Administration menu item.
  3. Click on the Stationary | Layouts menu item.
  4. Check each Layout Definition against your corporate template and requirements:
    1. HMTL Layout
    2. TXT Layout
    3. Check that Unique Identification Text has been set for each Layout
  • PASS (Expected)
  • FAIL
  1. Verify that a Stationery Assignment Policy has been configured Navigate to Gateway | Policies | Stationery Assignment
  • PASS (Expected)
  • FAIL

Corrective Action for FAIL Results:

  • Update the Stationary Layout / Assignment Policy as required.

 

Verify Outbound Email Routing

 

Email Accepted for Delivery by Mimecast

 

Test #: MAN07Executed by:
DateOverseen by:

Description: Email submitted to Mimecast by our internet facing SMTP servers is accepted for delivery by Mimecast.

ActionResult
  1. Configure your SMTP Servers to route email for a specific email address or domain (we recommend using recipient address/domain) to be routed via Mimecast.
  2. Send an email from an internal address to the External Address / Domain with the static Outbound route configured to use Mimecast
  3. Verify that the email was accepted by Mimecast:
    1. Log in to the Administration Console.
    2. Click on the Administration menu item.
    3. Click on the Gateway | Accepted Email menu item.
    4. Check to see if email appears in the list
  • PASS (Expected)
  • FAIL
Corrective Action for FAIL Results:
  • Create / Update relevant Definition, Policy and DNS Records

Corrective Action for FAIL Results:

  1. Check that the message has left your MTA
  2. Check that the message was passed to Mimecast from your MTA using the Delivery Route configured
  3. Use the Connection Viewer, Rejection Viewer and Bounce Viewer under the Monitoring menu in the Mimecast Administration Console to determine if Mimecast did not accept the message
  4. Determine reason for rejection (usually in NDR) and troubleshoot

 

Email Delivered by Mimecast to External Recipient

 

Test #: MAN08Executed by:
DateOverseen by:

Description: Ensure that once Mimecast has accepted the email, it is processed and delivered to the destination MTA / Mailbox.

ActionResult
  1. Verify that Mimecast delivered the email:
    1. Log in to the Administration Console.
    2. Click on the Administration menu item.
    3. Click on the Gateway | Accepted Email menu item.
    4. Click on the message sent to the external domain.
    5. Click View | Transmission Data.
    6. Confirm the 250 SMTP Code against Receipt Acknowledgement.
  2. Verify that the message has been received:
    1. Log in to the recipient mailbox.
  • PASS (Expected)
  • FAIL

Corrective Action for FAIL Results:

  1. Troubleshoot delivery issues using the Delivery Queue and Bounce Viewer under the Monitoring menu in the Mimecast Administration Console.
  2. Check the Spam/Hold Queues in the recipient mailbox.
  3. Check the NDR received in the sender mailbox.

 

Verify Outbound Security

 

Auto Allow List Creation

 

Test #: MAN09Executed by:
DateOverseen by:

Description: Email Addresses of external recipients with whom users communicate should be automatically added to the auto allow list so that responses will not accidentally be held as spam or rejected.

ActionResult
  1. Send an email from an internal address to the External Address / Domain with the static outbound route configured to use Mimecast.
  2. Verify the Managed Senders Policy:
    1. Log in to the Administration Console.
    2. Click on the Administration menu item.
    3. Click on the Gateway | Managed Senders menu item.
    4. The Sender / Recipient should be listed with a Policy Type of Auto.
  • PASS (Expected)
  • FAIL

Corrective Action for FAIL Results:

  • Check your Auto Allow Creation Policy

 

TLS Encryption on email sent to Mimecast

 

Test #: MAN10Executed by:
DateOverseen by:

Description: Ensure that email sent from our MTA to Mimecast negotiates TLS.

ActionResult
  1. Configure your SMTP Servers to route email for a specific email address or domain (recommend using recipient address/domain) to be routed via Mimecast
  2. Send an email from an internal address to the External Address / Domain with the static outbound route configured to use Mimecast
  3. Confirm receipt:
    1. Log in to the Administration Console.
    2. Click on the Administration menu item.
    3. Click on the Gateway | Accepted Email menu item.
    4. Check to see if email appears in the list.
    5. Check the Receipt Information for confirmation of TLS as the transport.
  4. Repeat test for each sending domain.
  • PASS (Expected)
  • FAIL

Corrective Action for FAIL Results:

  1. Check that your MTA supports TLS Handshakes with remote systems.
  2. Check your opportunistic TLS policies.

 

TLS Encryption on Email Delivered by Mimecast

 

Test #: MAN11Executed by:
DateOverseen by:

Description: Ensure that Mimecast encrypts communication with external MTA’s that support TLS.

ActionResult
  1. Send an email from an internal address to the External Address / Domain with the static outbound route configured to use Mimecast
  2. Verify the Delivery information:
    1. Log in to the Administration Console.
    2. Click on the Administration menu item.
    3. Click on the Gateway | Accepted Email menu item.
    4. Check to see if email appears in the list.
    5. Check the Delivery Information for confirmation of TLS as the transport.
  3. Repeat test for each sending domain.
  • PASS (Expected)
  • FAIL

Corrective Action for FAIL Results:

  1. Confirm that the remote MTA supports TLS and has a valid certificate installed (e.g. Gmail.com supports TLS, Outlook.com does not).
  2. Check the opportunistic TLS policies.

 

Validate SPF Pass

 

Test #: MAN12Executed by:
DateOverseen by:

Description: Ensure that recipient email systems designate Mimecast as an authoritative server for your SMTP domain based on successful SPF validation.

ActionResult
  1. Send an email from an internal address to the External Address / Domain with the static outbound route configured to use Mimecast
  2. Verify the result:
    1. Log in to the recipient Mailbox and open the Message.
    2. Open the Message Headers of the email on the recipient mailbox.
    3. Look for a the results of the SPF check in the message headers, they should specifically mention SPF Pass or Pass next to the SPF Check.
  3. Repeat test for each sending domain.
  • PASS (Expected)
  • FAIL

Corrective Action for FAIL Results:

  1. Ensure that your SPF Record is registered.
  2. Ensure that your SPF Record contains the relevant Mimecast Servers entry.
  3. Ensure that your SPF is correctly constructed.
  4. Ensure that you have allowed sufficient time for DNS Propagation (min 3 hours but can take as long as 48 hours).

Comments and Observations:

  • Assumes organization is making use of SPF Records

 

Validate DKIM Signing

 

Test #: MAN13Executed by:
DateOverseen by:

Description: Ensure that outbound emails are signed with the unique private key matching the public key in DNS to authenticate the email as originating from a trusted source.

ActionResult
  1. Send an email from an internal address to the External Address / Domain with the static outbound route configured to use Mimecast
  2. Verify the result:
    1. Log in to the recipient Mailbox and open the Message.
    2. Open the Message Headers of the email on the recipient mailbox.
    3. Look for a the results of the DKIM check in the message headers, they should specifically mention DKIM Pass or Pass next to the DKIM Check. You should also be able to see the DKIM Signature (Public Key) in the headers.
  3. Repeat test for each sending domain.
  • PASS (Expected)
  • FAIL

Corrective Action for FAIL Results:

  1. Ensure that your DKIM Definition exists.
  2. Ensure that your DKIM Policy has been defined and applied.
  3. Ensure that the DNS Record for your DKIM Public Key has been created.
  4. Ensure that you have allowed sufficient time for DNS Propagation (min 3 hours but can take as long as 48 hours).

Comments and Observations:

  • Assumes organization is making use of Domain Keys

 

Verify Signatures / Disclaimers

 

Validate Signature / Disclaimer Application

 

Test #: MAN14Executed by:
DateOverseen by:

Description: Ensure that the appropriate signature and disclaimer is being appended to email on the outbound route.

ActionResult
  1. Send an email from an internal address to the External Address / Domain with the static outbound route configured to use Mimecast
  2. Verify the result:
    1. Log in to the recipient Mailbox and Open the Message.
    2. Check the signature / disclaimer text to ensure it appears as expected.
  3. Repeat test for each sending domain.
  4. Repeat test using HTML, Rich Text and TXT formatted Emails.
  • PASS (Expected)
  • FAIL

Corrective Action for FAIL Results:

  1. Check the Stationery Assignment policy.
  2. Check the Stationery Layout.

 

Avoid Signature / Disclaimer repetition

 

Test #: MAN15Executed by:
DateOverseen by:

Description: Ensure that the signature / disclaimer is applied only once to an email, i.e. chains of responses do not continuously add redundant elements.

ActionResult
  1. Send an email from an internal address to the External Address / Domain with the static outbound route configured to use Mimecast
  2. Verify the results and then reply:
    1. Log in to the recipient Mailbox and open the Message.
    2. Open the Message check the signature and disclaimer have been added.
    3. Send a reply to the sender.
  3. Reply to the received response:
    1. Log in to the originating mailbox, reply to the message.
    2. Return to the recipient mailbox and check to see that YOUR disclaimer and signature have not been doubled up.
  4. Repeat test for each sending domain.
  • PASS (Expected)
  • FAIL

Corrective Action for FAIL Results:

  • Check the Stationary Layout’s Unique Identification Text is populated with a unique element of your Stationary/disclaimer

Attachments

    Outcomes