General Whitelisting at IT-Seal

This article is currently under revision. For more information on whitelisting IPs, see our documentation portal: Allowing the Delivery of Simulated Phishing Emails.

Please treat the contents of this article with caution.

Why do we need to be whitelisted? 

To ensure that phishing simulation notifications and training emails reach recipients and that clicks on file attachments and links are properly counted, it may be necessary to prepare your security and filtering systems for the training emails and configure them accordingly.

Whitelisting ensures that the emails are not automatically forwarded to junk or spam folders, or that sandboxes do not falsify the results to be measured.

What systems do I need to consider when whitelisting? 

Of course, this depends on your network landscape and the security systems you use, such as email, spam filters, secure gateways or proxy servers.

In order for the training emails to reach the employees, you must first identify all the security systems that are located in front of the mail server. These systems must be configured accordingly.

Simple system landscape:

Complex system landscape:

It may happen that you have to store additional information in your security systems, e.g. if you have endpoint solutions (sandboxing, client firewalls, URL filters, etc.). Here you need an additional domain or URL list. You can request these via the known support channels.

What whitelisting options exist? 

You have three options to whitelist our mail server in your security systems:

Whitelisting the IPs: 84.16.227.187 and 94.100.132.73
This is the configuration method we favor. In many systems you will find the possibility to whitelist the IP of IT-Seal. All our emails are sent via the IPs 84.16.227.187 or 94.100.132.73.

• Advantage: With this method you enable direct delivery of the training emails.
• Cons: Seems to be supported by fewer systems than thought. If their systems do not meet the requirements, they can use the options described below.

Whitelisting of the sender domain: e.g. http://help.it-security.lt-seal-index.de/
The whitelisting can be done via basic domains, for this your system must allow wildcard domains (e.g. *.lt-seal-index.de) or via a complete sender list. Both can be requested via the known support channels.

• Advantage: Each training has a list of all domains we use to send training emails. As well as a list of all links that are stored in the training emails.
• Disadvantage: For security systems without import or wildcard function it is very tedious to integrate all domains/links into the system, because depending on the training volume the lists can contain up to 5000 lines.

Header-based whitelisting: e.g. X-ITSEAL: Iamaheaderwhichissetextraforthistraining.
This form of whitelisting is not preferred by us, but is usually applicable in most security systems. For this, a header generated specifically for your training is required. It can be requested via the known support channels.

• Advantage: Can be implemented in most security systems.
• Disadvantage: Since the header string can be misused, whitelisting via headers poses a not inconsiderable security risk.