Cloud & Web Security. Administrator Quick Start Guide

Transcription

1 Administrator Quick Start Guide -

2 Index 1. Cloud Firewall Introduction 2. Licensing model 3. Initial Cloud Firewall configuration 3.1 Cloud Firewall Inbound filtering Domain configuration Mailbox configuration Manual mailbox configuration Importing mailboxes from lists Automatic user provisioning using SMTP Automatic user provisioning using LDAP (Active Directory) Platform customization Configuring the MX records in the DNS Additional security configuration (Firewall) 3.2 Cloud Firewall Outbound filtering 3.3 Configuring SPF records in the DNS 4. Additional information 5. Contact

3 Administrator Quick Start Guide 1. Cloud Firewall Introduction Cloud Firewall is a security solution for based on the concept of software as a service (SaaS). This concept lets companies focus on their core business, freeing the from the management tasks and operating costs associated with traditional security solutions. Cloud Firewall consists of a multilayer system which combines protection filters and processes using proprietary technologies (Cloud Firewall proactive, trusted lists...) and as standard technologies (IP reputation, Bayesian networks, white lists and black lists, grey lists, traffic shaping...) to ensure maximum effectiveness. By removing spam, viruses and phishing - with more than ten different filters -, it not only reduces the load on the server but also mitigates productivity problems caused by employees deleting spam. In addition connection filters, there are two filtering modes: automatic mode and guaranteed mode. Cloud Firewall has an interface which is intuitive and easy to set up, allowing administrators to rapidly start up the protection components required to ensure the company s security. Some of the funcionalities of Cloud Firewall are: Central Setup Easy Management Multilayer Antispam Incoming Backup - Users registration Manual Importing from a file LDAP callout with Alias discovery SMTP callout logs with the possibility of open s (if you choose this option when you Purchase), add senders / IP s to white list / blacklist, classify s as Valid / Spam Cluster active-active avoiding any information lost in case of incidence Administrators per domain Trusted lists by User Customized filters Notification software

4 2. Licensing model Cloud firewall is subscribed as a service and every mailbox protected by the solution will require a license from the license pool available on the service. The administrator can review the number of licenses being used and available under Administration -> Status -> State of Subscription: In order to obtain the total number of licenses needed for your organization, the following points need to be considered: Alias Domains In case the platform is protecting an existing domain (i.e. spaminatesting.com ) with users already created under that domain already consuming licenses in the system and in case you have another domain that is an alias of that existing domain (we assume that all users in the alias domain will be the same users already existing in the main domain), the alias domain can be configured as an alias of the main domain. All users present in the main domain will be implicitly configured in the alias domain and these users will not consume an extra license. - Alias accounts Each license of the solution will protect one mail mailbox and up to 5 aliases addresses associated to the main mailbox consuming the license. In order to associate the alias accounts covered by a single license in the system, it is required that alias addresses are properly configured in the system. Alias accounts can be configured manually (section ) or using LDAP Automatic Sign-up mode when enabling Alias search in the LDAP configuration. Bear in mind that alias discovery is not an available option when using SMTP automatic Sign-up mode and therefore LDAP provisioning is advised in organizations with alias addresses. In case your organization has alias mailboxes protected by the solution and in case those alias accounts are not properly configured as alias in Cloud Firewall configuration, the platform will consume a license for those alias mailboxes.

5 3. Initial Cloud Firewall configuration This quick configuration guide covers the initial steps needed to protect your domains and mailboxes for your users. All configuration steps detailed in this guide are to be performed using the enterprise management interface of Spamina s Cloud Firewall. Access to your enterprise management interface should have been provided to you along with this quick configuration guide. The enterprise management interface can be accessed from this URL: using your unique credentials provided to you. All steps described in this are mandatory in order to setup Cloud Firewall with the domains and mailboxes that will be protected by the solution. Please note that configuration covered in section 3.1 is mandatory and, in case the steps detailed in this guide are not fully completed before forwarding inbound s to the Cloud Firewall solution, both inbound and outbound s will be bounced back with a permanent error code. This will have the final effect of s never being delivered to the destination users, so we advise to read through this guide and perform all the configuration steps for domains and users to be protected. Section concerning outbound filtering (3.2) is optional in case you do not requiere Cloud Firewall to perform outbound filtering for your organization. Section covering security (3.1.6) is also optional. 3.1 Cloud Firewall Inbound Filtering The following steps should be completed to protect inbound s arriving to your organization: - Configuration of domain(s) to be protected by the platform. Configuration of mailboxes to be protected by the platform. Initial customization of Cloud Firewall, in case you want to change the look and feel of the user interface and the communication sent to mailboxes protected by the platform. DNS MX redirection to Cloud Firewall so will flow through the solution. This sectin will provide detailed instructions for each configuration step.

6 3.1.1 Domain configuration First configuration step is to configure in the platform the domain or domains that will be protected by Cloud Firewall. This configuration is done under Administration -> Domains. For each domain to be protected by the solution, we need to configure a new domain clicking on New Domain : The information required for each new domain is as follows: Select the checkbox The domain to be registered is an alias in case the domain you are configuring is an alias domain of another existing domain already configured in the platform. Enter the name of the domain to be protected under Name (ie: spaminatesting.com). A contact address is required. Notifications generated by the platform related to this domain will be sent to the specified address (such as the user synchronization process or in case the domain has reached the maximum allowed number of licenses). We recommend using an external address, as notifications stating that the mail server are unreachable will be sent to this notification address. You can limit the maximum number of licenses that will be consumed by users provisioned in this domain. You can select the default language that will be used for this domain. All end user notifications as well as the end user management interface for users created under this domain will be available in the specified language as a default. - After configuring this section, you need to configure the host or IP address where Spamina Cloud Firewall will deliver inbound s after being filtered. This hostname or IP address will be the current address whre your server hosting the mailboxes of the specified domain is located. Bear in mind that in case you have not yet redirected your DNS MX records to the Spamina filtering solution, you can fetch your current server location into the Recipient Server settings by clicking on Get SMTP. Please make sure that the Recipient Server settings are pointing to the current location of the server whre the mailboxes for the configured domain are hosted before saving the configuration.

7 The platform allows the configuration of several MX hosts and each of them can be configured with a different priority. Make sure that the Priority field is set to something different than 0 and consider that configured hosts with lower priority will be preferred when delivering inbound to your organization. Once all MX hosts have been properly configured, make sure to run the test SMTP check to ensure that the platform can contact the specified MX hosts. Please review the firewall settings at your organization in case this check fails, and make sure connectivity to the configured MX hosts on port 25 is allowed from Spamina s Cloud. The source IP address for delivery to your organization will be always performed from the following set of IP address belonging to Spamina s Cloud Firewall service: / / /24 After configuring the Recipient servers, you may now save the configuration for your protected domain or you may define a Domain Administrator at this point. A domain administrator will have the specified access credentials to the administration interface located under and will be able to change configuration settings only for the domain being configured in this section. Once all fields have been configured, save the domain configuration and proceed to the next step: Mailbox Configuration

8 3.1.2 Mailbox configuration Spamina Cloud Firewall requires that all mailboxes that will be protected by the platform are configured in the system. If you do not configure the mailboxes protected by the solution (either manually or setting up an automatic Sign-up mode), Spamina will reject inbound and outbound s with a permanent error code to/from your organization. Mailbox (also known as User) configuration can be achieved in different ways: Manual User configuration: The administrator can manually provision the mailboxes (or alias addresses) individually. The administrator can also import a list of users (TXT or CSV format). Automatic Sign-up configuration: Each domain being protected by the solution can be configured to automatically add user mailboxes using two different methods: SMTP or LDAP. Both provisioning mechanisms can coexist in the solution. The administrator may configure manually some mailboxes and have, at the same time, the automatic sign-up mode in the domain being protected Manual User configuration Mailboxes that will be protected by the solution can be added manually using the management interface under Administration -> Users. Using this screen, the administrator can create users with a main canonical address (primary delivery address) and alias addresses linked to another main delivery address already existing in the system. In order to create the main address of a user in the system, click Create User : the following minimum information required in order to provision a new user in the system is: Domain: A domain should be selected from the drop down list of already provisioned domains in the system. This will be the domain of the main address of the user to be protected. Language: IDefault language for this user. This will be the language for all the system generated notifications for the user. By default the system will select the language choosen at the time the domain of the address was configured. Full Name: This information is used for administration purposes in order to list the users by their real name and surname instead of the address being configured.

9 User Login: This will be the address for the users being created. You only need to enter the name of the mailbox, as the domain will be selected from the Domain field. Password: The system requieres each user to have a password for accessing the End User management interface on the system. Using the previous exemple we will be provisioning the following mailbox to be protected by the platform: homer. simpson@spaminapresales.com. Once details about the user to be protected are entered in the platform, you need to save the configuration. Back in the User menu, the administrator can create an alias address linked to a main mailbox created previously by clicking on Create user alias : The following minimum information is required in order to create an alias address account bound to a main delivery address: Domain in which Alias will be created: This will be the domain hosting the alias address. It is not necessary that the domain in which the alias account is to be created is the same as the domain hosting the main delivery address. Main Domain: Domain hosting the main delivery address to which we want to link the alias address being created. Alias: Name of the alias account to be protected by the solution, without and the domain part. Main Account: The main delivery address we will be binding the alias to the main account must have been created previously on the system.

10 The following example will create the alias address bound to the main address account Once the alias details have been entered you can save the configuration Importing Mailboxes from lists Cloud Firewall allows the administrator to manually import a list of users into the system using files. This can be done from Administration -> Users -> Import : Before performing the users import, we need to prepare a file containing the name of the mail (and alias) addresses that will be protected by Cloud Firewall. The file to import could be a.csv or a.txt having the following format: Full name, address, password Full name, address The password and the comma separated list of aliases are optional. If no password is given, Spamina Cloud Firewall will auto generate one at the time the user is imported into the system. Please consider the following tips in case you want to specify the passwords for your users in the file to be imported: Lowercase and uppercase letters a to z, except ñ Numbers 0-9 Symbols allowed: _. - Minimum length of 8 characters and a maximum of 64 characters

11 The address present in the file to be imported can be specified in any the following two formats: 1. Including the domain the mailbox belogs to: In this scenario, a valid example of the contents of a file to be imported would be: Michael Perk, mperk@example.com, aras249gt Anthony Perkins, aperkins@example.com, 32kios5d Timothy Perkins, tperkins@example.com Anthony, alopes@example.com,,alopes.alias1@example.com,alopes.alias2@example.com 2. Not including the domain the mailbox belongs to: In this scenario, a valid example would be: Michael Perk, mperk, aras249gt Anthony Perkins, aperkins, 32kios5d Timothy Perkins, tperkins Anthony, alopes,,alopes.alias1,alopes.alias2 It is important to select the domain under which the users will be imported in case the address specified in the file do not specify the domain (case 2 as presented above). If the domain is present in the file to be imported, it is mandatory that you leave the Select a domain field empty in the import menu as the import process will fail otherwise. You cannot import a file which has addresses both with and without a domain. Taking the previous points into consideration when creating the file to import, select the file in using the import menu and click on import. Please bear in mind that the import process is not performed real time and it will take several mnutes to complete depending on the number of users to be imported. Cloud Firewall will notify the system administration via , sending a summary detailing the result of the import process Automatic user provisioning using SMTP Spamina Cloud Firewall can be configured to automatically sign-up users using the SMTP protocol. Using this automatic provisioning mechanism, users that are not currently present in the system will be automatically provisioned at the time the first inbound is processed for the user present in a domain being protected by the solution. Automatic SMTP provisioning of users can be configured under Administration -> Sign-up mode. SMTP automatic sign-up is configured on a per domain basis as follows:

12 Once SMTP activation mode has been selected and the configuration is saved, the system will request the administrator to enter a valid address of a user existing in the domain being configured for automatic sign-up mode. This check verifies whether the server being protected is valid for SMTP automatic provisioning. In case you enter a valid address existing in the domain being configured for SMTP sign-up provisioning and if the check fails, the server may not be suitable for SMTP automatic sign-up mode. This verification may fail in case the client server is configured to accept - at SMTP level - all addresses, event the ones for non-existing users in the organization. In Microsoft Exchange terms this is also known as Recipient Validation and, if disabled, will accept all addresses for a domain. Recipient validation must be enabled in order for Spamina s Cloud Firewall to properly provision users via the SMTP automatic sign-up mode. Please double check with your administration to ensure that your mail server is rejecting s - at SMTP level - for non existing addresses at your domain. The system will not allow you to configure SMTP Automatic Sign-up mode in case the previous check fails. Once SMTP automatic sign-up mode has been configured, the system will provision users automatically at the time s are processed by the platform for those users. This means that shortly after the SMTP automatic sign-up mode has been enabled, the administrator will not immediately see the complete set of users provisioned in the management interface (under Administration -> Users). Cloud Firewall user database will be built up progressively, as new users keep receiving s from the internet through Cloud Firewall. One essential point that must be taken into account when enabling the SMTP automatic sign-up mode is that all mail addresses for your organization, regardless whether they are main mailboxes or alias addresses, will be provisioned as a main mailbox in Spamina s Cloud Firewall, consuming a license form the system. Bear in mind that this is an important consideration when computing the license consumption by the system. In case your organization is making an extensive use of alias mailboxes, we recommend enabling the LDAP provisioning is able to discover alias addresses and therefore license consumption will be more accurate Automatic user provisioning using LDAP (Active Directory) Another auto provisioning mechanism available in the platform is the use of LDAP queries against the directory service present inside the client s network. This is the advised sign-up mechanism to be used for medium to large corporations. The main difference between both automatic sign-up modes, SMTP and LDAP, is that LDAP provisioning is capable of detecting alias addresses and binds them automatically to a main mailbox, both for management and proper license consumption purposes. LDAP sign-up mode can be enabled globally (for all domains) or on a per domain basis. We recommend configuring LDAP provisioning globally - across all domains - whenever possible, this is, when all domains being protected by the solution are governed by the same domain controller or directory server. You may configure different LDAP servers in case your organization has independent domain controllers or directory servers per domain.

13 The minimum requirements needed to configure the LDAP user sign-up are as follows: Spamina s Cloud Firewall cloud servers need access to your directory servers (Active Directory / Lotus / LDAP) using any of the customer s public Ip adresses or using a fully qualified domain name that is visible on the internet. Spamina s Cloud Firewall cloud servers will query your directory servers using the LDAP or LDAPS protocols Spamina s Cloud Firewall cloud servers can do anonymous LDAP queries, although we recommend using the credentials of a specifically created user for this purpose. The IP address range of Spamina s cloud servers from which we will be querying the end customer directory server is as follows: / / /24 We require that the customer allow LDAP or LDAPS connections from the IP address ranges specified above. When configuring the LDAP user sign-up mode with Active Directory, it is required that a user is created in the Domain Controller. This user needs to belong to the Domain Users group and the system requires the credentials of that user to be configured. Please perform the following action in the primary domain controller of your organization to create this user: 1. Create a specific user belonging to the Domain Users group. 2. The password assigned to the user must contain alphanumeric characters and the _ and - symbols only. Please do not use any other characters as the password for this user. 3. When creating the user, please specify that the password does not need to be changed by the user and that the password never expires. This is essential, as most of the issues reported by customers using LDAP user sign-up mode are due to the fact that the password as configured in Spamina s Cloud Firewall is no longer valid as it expired on the customer directory service. Once this specific user has been created in your Domain Controller, you need to get the path to the Distinguished Name for that user. Just open a command line window on your Domain Controller (Start -> Run -> cmd) and run the following command: dsquery.exe user name [USER] In case the new user created was named spamina, here is the command that must be run on the domain controller and the output returned: dsquery.exe user name spamina CN=spamina,CN=Computers,DC=dctest,DC=local The user to be configured in the LDAP sign-up mode management interface will be the path as returned by the previous command: CN=spamina,CN=Computers,DC=dctest,DC=local. Please copy that information from the command line tool. Once the user has been configured and the Distinguished name of the user obtained, the LDAP user sign-up mode can be configured under Administration -> Sign-up mode -> LDAP [Setup]

14 The following section will describe the most common configuration options used when configuring LDAP sign-up mode with Microsoft Active Directory: LDAP Server: Please select the correct directory server type used in your organization. In this guide we will be using Active Directory Connection: Host: Enter the IP address or FQDN of your LDAP server. Please note that this IP/FQDN for your directory service must be reachable from Spamina s IP address ranges Port: 389 (default) Anonymous Connection: [Unchecked] As Microsoft Active Directory does not allow anonymous connections this option must be left unchecked. Username: A valid CN path must be entered in this box. Using the previous steps, we can enter the CN path as returned by the dsquery.exe command run on the domain controller CN=spamina,CN=Computers,DC=dctest,DC=local Password: Enter the password choosen for the user created following the previous example: Once all data has been properly entered in this configuration section, the administrator can validate the current values by clicking on the check button. This test will validate that the host and port specified can be reached by Spamina s cloud servers and that the credentials provided are valid. Please double check that connectivity is allowed from Spamina s cloud servers to your infrastructure in case you get connection errors. Search Scope: DN Base: Starting point in the LDAP tree from where Spamina s Cloud Firewall look for users in your organization. It is recommended to configure a starting point as possible from your organization s tree root, so all users will be found regardless of the organizational unit they are configured on. The DN Base can be obtained from the CN of the user created in our previous example. When configuring Active Directory, the DN Base usually matches the part of the user s CN that starts with DC. In our previous example, it will be: DC=dctest,DC=local

15 A Level: Select this option if all the users inside your organization are present in the DN Base. Subtree: Select this option if all the users inside your organization are present at this level and other sublevels starting from the DN Base path. This is the recommended option when a DN Base close to the root tree has been configured. Search for username: These values will be automatically filled in when selecting the correct type of directory server used in your organization (Active Directory / Open LDAP / Lotus Domino). In case you are configuring an Active Directory server, you may need to check The attribute stores the full address option: At this point, you can click on the Check button to validate the configuration entered for your LDAP server. A valid main address present in your organization will be requested (not an alias address) and the system will check whether we can retrieve the information for this user using the current configuration, validating the current settings: If the address provided during the check is not found, please double check the configuration entered in this section woth your domain administrator. The schema used at your organization may differ from the examples used here. Alias Search: This option is, by far, the option that makes LDAP automatic provisioning more appealing than SMTP provisioning. It refers to the ability to automatically discover and bound alias addresses to main addresses in your organization, both for computing the correct number of licenses that you will consume and for management purposes. We strongly recommend enabling this option whenever LDAP sign-up is being configured. Enable Alias Discovery: proxyaddresses Most Active Directory + Exchange installations will use this attribute (proxyaddresses) to specify the alias addresses of a given user.

16 LDAP Filter: (objectclass=*)) Please note that you can specify different filter option here in order to retrieve only the desired information. We will be using (objectclass=*) in this example so we will retrieve all alias addresses. Is the field multi-valued? : No This is usually the default setting from Microsoft Active Directory + Exchange. Alias separator: For Microsoft Active Directory + Exchange you should enter the : sign in this option. This will be the character that will separate different alias addresses inside the configured attribute. Is the Alias the same object as the mailing adress? Yes Microsoft Active Directory + Exchange will store alias addresses in the same objetc as the user. Once this section has been configured, the administrator can validate the settings using the Check button. A valid alias adress present in your organization is requested and the system will check that the corresponding main address of the user is correctly retrieved using the current settings: In case the check is not returning the main adress of the user with the specified alias address, please double check the values entered in this section with your domain administrator, as your corporate schema may differ from the standard one shipped with Microsoft products.

17 User Information recovery: This section specifies what attributes inside your directory schema contain the full name of the user information being retrieved. This is a covenient configuration section to have configured so the information about a user in Cloud Firewall will be displayed using the name and surname of the user. The typical configuration for Microsoft Active Directory is as follows: Attribute that contains the user s surname: displayname Stores the first name and surname together: [Checked] After filling in all the required information and performing the relevant checks on each section, the configuration must be saved. When filling in all the sections in the LDAP sign-up mode, please perform all the checks available in the interface. The previous checks should be succesful in order to consider the LDAP provisioning mode enabled correctly: Spamina s Cloud Firewall is able to connect to your directory server. Spamina s Cloud Firewall is able to locate users in your directory server (the check under the Search for username performs correctly when providing a valid main address in your organization). Spamina s Cloud Firewall is able to locate alias addresses for your users (the check under the Alias Search performs correctly when providing an existing alias address in your system and the check is able to return the associated main address for that user).en caso de activar el descubrimiento de alias, se debe realizar la verificación para comprobar que el sistema localiza las cuentas principales a partir de las direcciones de alias. In case any of the previous checks encounters an error the LDAP sign-up mode will not be correctly configured. Should this happen, please make sure to save the configuration and come back later to the relevant failing section to reconfigure the options after double checking the values with your domain administrator. The examples provided in the sectios depicted above are oriented towards a Microsoft Active Directory + Microsoft Exchange deployment. The depicted configurations may vary depending on you re the schema used in your organization or in case the default Microsoft Active Directory schema has been modified.

18 3.1.3 Platform customization Once the domain and users setup has been completed, the platform is ready to protect the users under the configured domains. The next configuration step is to customize the default platform behavior. It is recommended to complete the following basic customizations: Welcome message: In case any of the available automatic sign-up modes (SMTP or LDAP) have been configured, the platform can send a welcome message to automatically provisioned mailboxes with credentials that will grant each protected user access to the End User control panel. From this end user control panel, each protected user will have the ability to review their quarantined s and change their filtering preferences. If you want to make your users aware that this control panel exist and provide them with their unique passwords to access this service, you must enable this option (please note that the welcome message is disabled by default and therefore your end users will not be notified and will not be aware that this control panel exist).

19 Blocked report: Spamina s Cloud Firewall can be configured to send a summary to your end users containing information about the quarantined s in the system. Using the digest , your end users can unblock the s classified as spam and add the sender to the user s whitelist in order to avoid blocking further s coming from the same sender. The delivery frequency of the blocked reports can be changed from Personalization -> Blocked report: Logo: The company administrator can upload a personalized logo that will be included in all system notifications to users being protected by the solution (welcome message, blocked reports, etc) as well as in the end user management interface. The logo can be changed under Personalization -> Logo: Note that the customizations can be performed globally (for all domains configured in the platform) or on a per domain basis. The level at which the customization is being applied can be selected using the Settings for scroll down menu at the top of the page.

20 3.1.4 Configuring the MX records in the DNS After all previous steps have been completed the platform is ready to protect inbound s destined to your organization. In order to complete the deployment of Cloud Firewall into your organization s delivery flow, you need to change the MX records for the protected domains and point them to the following service hosts: mx01cef.spamina.com mx02cef.spamina.com We recommend setting the MX records of the protected domains to both service hosts with the same priority (for instance 10 ) in order to achieve load balancing inside Spamina s Cloud Firewall platform. Please note that Spamina does not have access to the DNS settings, nor does Spamina have the ability to change the MX records of the domains being protected on behalf of our customers. This is a task that must be performed by the end client, as the DNS register belongs to the end client. oplease check this point with your DNS service provider or with your network administrator in order to obtain more information on how to perform modifications to your DNS settings. Once the MX records for the domains to be protected by Spamina have been changed to our service hosts, Spamina s Cloud Firewall will start processing inbound s and the platform will retain Spam s and will only deliver valid s to the protected mail servers of your organization Additional security configuration (Firewall) Once the MX records of the domains being protected by the solution have been changed and are pointing to Spamina s Cloud Firewall, our customers may want to restrict inbound delivery to the servers being protected by allowing only inbound coming from Spamina s Cloud IP address ranges. Our IP address range is as follows: / / /24 You may want to restrict inbound destined to your corporate mail servers only from these IP addresses. The restriction should be applied to TCP traffic with destination port 25 only allowing delivery from Spamina s Cloud Firewall IP address ranges. 3.2 Cloud Firewall Outbound Filtering Once inbound protection has been configured following all steps described in section 3.1, Cloud Firewall can be configured to filter outbound flowing out of your organization to the internet. Outbound filtering is independent from inbound filtering; in fact some customers may not want to filter outbound s being delivered to the internet. However, outbound filtering requires that inbound filtering is properly configured, as it is required that both domains and users are correctly setup in Cloud Firewall. In order to configure outbound filtering with Cloud Firewall, you need to define a Smart Host in your corporate mail server so all outbound s will be delivered to Spamina s Cloud. Spamina s Cloud Firewall will filter your outbound s. In case the outbound is valid, we will proceed to the delivery to the remote server the should be delivered to. Please check the available documentation of your mail server in order to obtain more information on how to configure a Smart Host.

21 When configuring the Smart Host, you need to use the following service hostname: smtpcef.spamina.com The SMTP session to our Smart Host needs to be configured as an SMTP Authenticated session. The credentials used to validate the SMTP session will be the same credentials as used to login into the administration interface located at Configuring SPF records in the DNS Spamina recommends that our customers include Spamina s Cloud IP address range in the SPF records of the DNS regardless whether the customer is processing only inbound s for those protected domains. In case the customer is processing outbound traffic through Spamina s Cloud Firewall, this configuration is a must in order to avoid remote Spam systems classifying s being delivered by Spamina as Spam. The following IP address ranges need to be added to your SPF records: ip4: /24 ip4: /25 ip4: /24 An example of an SPF record for a domain being protected by Spamina s Cloud Firewall would be as follows: "v=spf1 ip4: /24 ip4: /25 ip4: /24 ip4:[otras DIREC- CIONES DE SUS SERVIDORES] ~all" We recommend that the customer keep their current IP or hostname in the SPF records and they add Spamina s ipv4 addresses to the existing ones. 4. Additional information You can find addtional information regarding available configuration and filtering options for Spamina s Cloud Firewall in the following online documents: Cloud Firewall Administrator s manual: Cloud Firewall User s manual: 5. Contact In case you require additional support, you can reach our technical presales team at: presales@spamina.com