Secure Mail Gateway

Starting with Relution 26.4.0, the Secure Mail Gateway standalone service is a mandatory component when the SMG feature is used. This article covers the setup for on-premise installations.

For configuring the Secure Mail Gateway in Relution: Secure Mail Gateway →


Migration — What Needs to Be Done?

InstallationAction required
Relution Cloud – Shared HostingNo action required. Relution handles the migration of the SMG service.
Relution Cloud – Dedicated Server (existing customers)Relution will host the SMG service. We will reach out to coordinate the migration.
Relution Cloud – Dedicated Server (new customers)The SMG service must be operated as a self-hosted on-premise component. Follow the setup guide further down in this article.
On-PremiseThe full setup process is described further down in this article.

Feature toggle for on-premise installations (26.3)

New in 26.3

In Relution 26.3, on-premise installations can already activate the new mode in advance. Add the SMG_STANDALONE feature toggle to the Relution server’s application.yml:

relution:
  featuretoggle:
    enabledPreviewFeatures:
      - SMG_STANDALONE

With version 26.4.0 the toggle is dropped — the standalone service is then active without any additional configuration.


Setup

1. Create a Dynamic Role

Download the ready-made role template and import it in the Global organisation under Settings > User Management > Permissions:

Download SMG role template →

Alternatively, create the role manually:

  1. Navigate to Settings > User Management > Permissions in the Global organisation
  2. Add a new Dynamic Role
  3. Enable the Secure Mail Gateway (service account) permission
  4. Save the role

2. Create a technical user and API access key

  1. Create a new user in the Global organisation and assign the Dynamic Role created above
  2. Navigate to the user’s detail page and create a new API access key
  3. Copy the generated key — it is only shown once

3. Deploy the service

Add the following service to the existing compose.yml. This is only needed if the Secure Mail Gateway is used.

  smg:
    image: relution/relution-smg-standalone:latest
    restart: always
    container_name: smg
    networks:
      - reverse-proxy
    volumes:
      - ./smg/application.yml:/opt/app/config/application.yml:ro
# - ./smg/ca-certs:/opt/app/ca-certs:ro   # see "Trusting a custom CA certificate" below
# environment:
# - JAVA_TOOL_OPTIONS=...                 # see "Outbound corporate proxy" below

Create smg/application.yml alongside the compose.yml:

relution:
  server:
    url: https://your-relution-server    # URL of your Relution server
    api-key: your-api-key               # API access key created above
# honor-proxy-settings: true         # see "Outbound corporate proxy" below

Start or restart the services:

docker compose up -d

Reverse proxy configuration

The SMG service exposes the /Microsoft-Server-ActiveSync endpoint on port 8093. The reverse proxy must route all requests for this path to the SMG service — the examples below show how to do this for Traefik and nginx.

Traefik

Follow the Traefik configuration → and add an extra router for the SMG path alongside the existing relution router:

http:
  routers:
    smg:
      rule: Host(`external.url`) && Path(`/Microsoft-Server-ActiveSync`)
      entryPoints:
        - websecure
      tls:
        certResolver: letsencrypt
      service: smg
  services:
    smg:
      loadBalancer:
        servers:
          - url: "http://smg:8093"

nginx Alternative to Traefik

Add the following location block to the nginx configuration:

location ~ /Microsoft-Server-ActiveSync {
    proxy_read_timeout 2100;
    proxy_pass http://smg:8093;
}

Trusting a custom CA certificate

If Exchange presents a certificate signed by an internal or self-signed CA, mount a directory of PEM-encoded certificate files into the container at exactly /opt/app/ca-certs:

    volumes:
      - ./smg/application.yml:/opt/app/config/application.yml:ro
      - ./smg/ca-certs:/opt/app/ca-certs:ro

These certificates are used when communicating with the Exchange and Relution server — there is no configuration property to set. If nothing is mounted, the feature is a no-op and outbound TLS behaves exactly as before. Adding, removing, or changing a certificate requires restarting the container; the directory is only read once, at startup.

Outbound corporate proxy

Exchange-forwarding requests honor the JVM’s standard proxy system properties. Set them via JAVA_TOOL_OPTIONS:

    environment:
      - JAVA_TOOL_OPTIONS=-Dhttp.proxyHost=proxy.example.com -Dhttp.proxyPort=3128 -Dhttps.proxyHost=proxy.example.com -Dhttps.proxyPort=3128

Add -Dhttp.nonProxyHosts (a |-separated list of host patterns, * wildcards supported) to exclude specific hosts from the proxy — typically Exchange itself, if it is reachable directly without going through the corporate proxy.

By default, calls to the Relution server are not proxied — it is normally reachable directly. If the deployment reaches Relution through the same proxy as Exchange, set honor-proxy-settings: true in smg/application.yml:

relution:
  server:
    url: https://your-relution-server
    api-key: your-api-key
    honor-proxy-settings: true   # default false; only needed if Relution is also behind the proxy

Troubleshooting

If issues occur with the SMG service — for example connecting to Exchange or starting the container — increasing the log level helps with the analysis. See Set log level → for instructions.

The easiest way is to enable the log level directly in the SMG container via its application.yml, by appending the following section at the end:

logging:
  level:
    io.relution: DEBUG

Changelog

Version currently available via latest: 26.0.4 (at 04.08.2026)

VersionChange
26.0.4Adjustment of the internal release process – no functional changes
26.0.3Support self-signed certificates and proxy settings
26.0.2Fix wrongly handled 404 responses
26.0.1Expose health endpoint
26.0.0Initial release — code migrated from Relution
Top