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.