E-mail Relay Clients

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.

Setting Up a Relay Client

Setting up a relay client is short. The care is in what you hand over and what you check afterwards.

Where to find it

Architect Panel → Integration & Connections:

• E-mail Relay Clients — clients and their keys
• E-mail Accounts — the sending account used

Architect Panel → Activity:

• E-mail Log — confirming what the client actually sends

Registering one

Create the client with a name identifying the system it is for, and it is issued its authentication and encryption keys. Those go into the other system's configuration.

Name it after the system, not the person

"Stock system relay", not "Dave's script". Systems outlive the people who set them up, and when a key needs rotating you need to know what will break.

Getting the keys there safely

They are credentials, so they should not travel by e-mail — which is a particular irony here. Use whatever secure channel you would use for any other secret.

If a key has been sent insecurely, rotate it rather than hoping. That takes minutes and removes the question.

Test with a real send

Send one message through the relay and confirm three things: it arrives, it appears in the e-mail log attributed to that client, and the sender address is what you intended.

The third is the one people skip and the one that matters — a relay sending from an address you did not expect is your domain being used in a way you have not sanctioned.

Check the volume after a week

Against what the other system's owner said it would send. A meaningful difference is worth understanding, and it is easiest to notice early before it becomes the normal reading.

Rotate on a schedule, and on departure

Keys should be rotated periodically and immediately when somebody who had access to them leaves. Because a relay key sends mail as your organisation, that is a higher bar than for most credentials.

Have a way to switch it off

Know how you would stop a relay client immediately, and make sure somebody other than you knows too. If a system starts sending something it should not — a loop, a compromise, a bad deployment — the response has to be quick.

Document the arrangement

Which system, who owns it, what it sends, roughly how much, and when the keys were last rotated. Relay clients are set up once and then forgotten, and the person who eventually needs to deal with one will not be you.

Worked example

A relay client is created for a monitoring system, keys handed over through a password manager rather than e-mail. A test alert confirms delivery, correct log attribution and the expected sender address. Volume is checked after a week against the stated fifteen alerts a day, and the arrangement is recorded with the system owner named.

Recommendations

• Name it after the system.
• Never send keys by e-mail; rotate if you did.
• Check the sender address on the first real send.
• Know how to switch it off, and make sure somebody else does.