📋FTAPI Gateway: Functionality and Overview

What is the FTAPI Gateway?

The FTAPI Gateway is an on-premise component that integrates into a company's existing mail flow and automatically encrypts, signs, and decrypts outgoing and incoming emails based on configurable policies. Senders do not need to adjust their workflow or their email client. The encryption logic runs in the background and is centrally defined by administrators.

Technically, the gateway is based on the CipherMail engine, which consists of two layers: a Mail Transfer Agent (Postfix) and a Mail Processing Agent. The Postfix layer handles SMTP acceptance, routing, and delivery. The processing layer is responsible for cryptographic processing and policy evaluation. Above this engine, the FTAPI-specific layer provides the connection to the FTAPI Cloud platform as well as the policy engine for Intelligent Email Encryption (IEE).

Components Overview

How does the mail flow work?

The process can be divided into three steps.

1. Email is sent: An employee writes and sends an email as usual via Outlook, webmail, or another email program. A special plugin or manual selection of a security level is not required.

2. Gateway checks the policies: The email passes through the FTAPI Gateway. There, it is checked against the configured IEE policies. Based on criteria such as recipient domain, sender domain, attachment size, or subject, the gateway decides which encryption method is applied. The rules are evaluated from top to bottom; the first matching block determines the method.

3. Delivery is encrypted: Depending on the result, the email is either delivered directly to the recipient's mail server using S/MIME encryption or generated as a SecuMails delivery via the FTAPI Cloud platform. What happens if no rule matches is granularly configurable and is described in the section on Fail-Safe mode below.

The gateway only intercepts emails sent via a mail client. SecuMails created directly via the FTAPI web interface are not affected. There, senders continue to select the security level manually.

Intelligent Email Encryption (IEE)

Intelligent Email Encryption (IEE) is the central rule set on the gateway. Administrators create if-then blocks that determine the applicable security level or encryption method based on recipient domain, sender domain, presence and size of attachments, start of the subject line, and group membership. If multiple conditions apply, the first rule from the top wins.

The gateway follows a multi-level configuration model: Factory-Settings, Global-Settings, Domain-Settings, and User-Settings. Values at lower levels inherit the default values of the higher level and can be specifically overwritten. This hierarchy allows for central control with selective exceptions, for example for individual domains or specific user groups.

A detailed guide on configuration can be found in the article Intelligent Email Encryption: Creating and configuring policies.

Supported encryption methods and security levels

The gateway supports several encryption methods that can be combined and prioritized via IEE policies.

For S/MIME encryption, the recipient's public key must be present in the gateway's certificate store. The gateway does not automatically detect S/MIME capability in the recipient. The mechanisms for obtaining these keys (certificate harvesting), the MPKI connection, and the management of revocation checks are described in the article FTAPI Gateway: Certificate management and S/MIME.

Deployment scenarios

The FTAPI Gateway can be used in two basic mail flow scenarios. Which scenario fits depends on whether an upstream security gateway is already present in the mail infrastructure.

Scenario A: Mail server with upstream security gateway

In this scenario, a security gateway (e.g., Hornetsecurity, Trend Micro, Sophos, Barracuda, or FortiMail) is in use in front of the mail server. The FTAPI Gateway is integrated between the security gateway and the mail server.

Outbound: The mail server hands the email to the FTAPI Gateway. It signs and encrypts it and then hands it over to the security gateway, which sends the email to the internet.

Inbound: The security gateway accepts incoming emails from the internet and hands them over to the FTAPI Gateway for decryption before they are delivered to the mail server.

An advanced variant (A2) provides for a second scan pass: Decrypted inbound emails pass through the security gateway again after decryption to be checked according to AV, spam, and DLP rules. A prerequisite for this is effective loop protection in the security gateway. Usually, an FTAPI-specific header is set, which is recognized during second passes so that emails are not forwarded to the gateway again.

Scenario B: Standalone cloud mail server

Without a separate security gateway, for example with Exchange Online or Google Workspace directly on the internet, the FTAPI Gateway is connected as a bidirectional crypto-gateway via connectors or routing rules.

Outbound: The cloud mail server hands the email to the FTAPI Gateway, which signs and encrypts it and sends it directly to the internet.

Inbound: The cloud mail server accepts the email, forwards it to the FTAPI Gateway for decryption, and delivers it after it returns from the gateway.

For the test phase, it is recommended to activate a connector only for a test domain or based on a specific subject tag before the complete mail flow is switched over.

Fail-Safe mode: What happens if no rule matches?

If no IEE rule matches and no fallback is defined, the gateway's behavior is granularly configurable. In the recommended configuration, the gateway works in Fail-Safe mode: Unencrypted delivery never occurs unintentionally.

Queue & Retry: The email remains in the Postfix queue and is reprocessed at configurable intervals. As soon as reachability is restored, the gateway automatically processes the queue without messages being lost.

Defer with bounce: After a configurable maximum period, for example 24 hours, a bounce with a clear note to the sender is generated. The content does not leave the system unencrypted.

S/MIME-Override: If a valid S/MIME certificate for the recipient is present in the gateway keystore, an override rule can use the S/MIME path instead of the SecuMails delivery. This requires a corresponding IEE configuration.

Explicitly allowing unencrypted delivery (Fail-Open) is a separate configuration option and should be disabled in security-relevant environments. Whether the Fail-Safe mode is active can be checked and set in the IEE configuration.

Clarify with your FTAPI contact whether the Fail-Safe mode is configured for your environment. Especially in regulated industries, it must be ensured that unencrypted transmission is technically excluded.

Interaction with the FTAPI Outlook Add-In

In practice, both paths often exist in parallel: the FTAPI Outlook Add-In for conscious, explicitly chosen transmission and the FTAPI Gateway as a centrally enforced rule path. Both are not mutually exclusive but complement each other.

If a user actively selects a SecuMails security level in the Outlook Add-In, the add-in transfers the content (message and attachments) directly to the FTAPI Platform API via HTTPS. A trigger notification email remains on the mail server, which informs the recipient about the new delivery and contains the link to the cloud portal.

To ensure that this trigger email does not run through the gateway again and is erroneously converted into a SecuMails delivery a second time, the FTAPI Outlook Add-In sets the header x-ftapi-agent. A transport exception rule is defined on the mail server that does not route emails with this header to the gateway but delivers them directly to the outside.

Gateway-side detection of the x-ftapi-agent header is not yet implemented but is on the FTAPI roadmap. As soon as it is available, the mail server exception rule can be omitted. The gateway could then additionally S/MIME-sign the trigger email and thus confirm the authenticity of the notification to the recipient. This would be an effective protection against phishing attempts that imitate the layout of a SecuMails notification.

If a user sends a regular email without add-in interaction, it runs completely through the gateway rule path: If an S/MIME certificate is present, it is signed and encrypted; otherwise, the SecuMails cascade takes effect automatically.

Prerequisites

The FTAPI Gateway must be installed and configured as a component in your mail flow. Setup is carried out together with the FTAPI team. A checklist for preparation can be found in the article Checklist: Preparation for your implementation appointment.

For the configuration of IEE policies, you need administrator rights in the FTAPI web interface.

Related articles

Intelligent Email Encryption: Creating and configuring policies

The FTAPI security levels

FTAPI implementation assistant