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?
| Installation | Action required |
|---|---|
| Relution Cloud – Shared Hosting | No 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-Premise | The full setup process is described further down in this article. |
Feature toggle for on-premise installations (26.3)
New in 26.3In 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:
Alternatively, create the role manually:
- Navigate to Settings > User Management > Permissions in the Global organisation
- Add a new Dynamic Role
- Enable the Secure Mail Gateway (service account) permission
- Save the role
2. Create a technical user and API access key
- Create a new user in the Global organisation and assign the Dynamic Role created above
- Navigate to the user’s detail page and create a new API access key
- 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.
latest. New builds go through additional quality gates before being promoted to latest — pinning a specific version tag may result in running a build that has not yet been validated for production use. 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
smg must be on the reverse-proxy network like relution and traefik — otherwise Traefik/nginx cannot route to it.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
relution.smg.* properties were previously customised in the Relution server configuration, move them to this file unchanged — the property names are the same.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;
}
smg refers to the Docker service name and is reachable within the Docker network. For a native Linux installation replace smg:8093 with 127.0.0.1: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)
| Version | Change |
|---|---|
| 26.0.4 | Adjustment of the internal release process – no functional changes |
| 26.0.3 | Support self-signed certificates and proxy settings |
| 26.0.2 | Fix wrongly handled 404 responses |
| 26.0.1 | Expose health endpoint |
| 26.0.0 | Initial release — code migrated from Relution |