Relaying Mail From Another System
A relay client lets another system send e-mail through this platform rather than configuring its own mail sending.
Where to find it
Architect Panel → Integration & Connections:
- E-mail Relay Clients — the registered clients and their keys
- E-mail Accounts — the accounts relayed mail goes out through
Architect Panel → Activity:
- E-mail Log — relayed messages, logged like any other
Why another system would want this
- One sending reputation. All your mail leaves from the same properly configured domain rather than several systems each doing their own thing badly.
- One place to configure. Authentication records, sending domains and provider credentials are set up once.
- One log. Everything sent by the organisation appears together, which makes "did we send it" answerable across systems.
- A small system need not know how to send mail — a script, a device, an internal tool.
The security position
Be clear about what you are granting: a relay client can send mail as your organisation. Anything it sends carries your domain and your reputation.
That is the whole benefit and the whole risk. A compromised relay credential is somebody able to send convincing mail from your domain — which is considerably worse than most credentials, because the damage lands on people who trust you.
Grant it narrowly
One client per system, never shared. Sharing removes your ability to tell which system sent what, and to revoke one without breaking the others.
What a client holds
- A name.
- An authentication key.
- An encryption key.
Both are credentials. Treat them as you would any other — not in a repository, not in a ticket, and rotated on a schedule you keep.
When it is not the right answer
If the other system is capable of sending its own mail and you are happy for it to, letting it do so is simpler. Relay earns its place when you want central control of sending, or when the other system genuinely cannot.
It also creates a dependency: if this platform is unavailable, that system cannot send.
Everything relayed is logged here
Which is useful and worth knowing for volume — a chatty system relaying through you fills your e-mail log with its traffic, including message bodies. Consider that when setting retention.
Watch what each client sends
A client sending far more than expected, or to unexpected recipients, is the signal that matters. Because the mail carries your domain, that is your problem regardless of whose system originated it.
Worked example
An organisation relays mail from a legacy stock system that could not be configured for modern authentication. It has its own client and keys, sends around forty messages a day, and its traffic is visible in the e-mail log alongside everything else. When the volume tripled one week, the cause — a retry loop — was visible immediately.
Recommendations
- One client per system, never shared.
- Treat the keys as credentials and rotate them.
- Watch volume per client — it is your reputation.
- Let capable systems send their own unless you want central control.