Sending and Receiving
Mail travels both ways, and the two directions have almost nothing in common beyond the account.
Where to find it
Architect Panel → Integration & Connections:
- E-mail Accounts — the accounts mail is sent and received through
Architect Panel → Integration & Connections:
- E-mail Inboxes — the receiving side
Architect Panel → Activity:
- E-mail Log — every message sent, with its result
Outgoing
The platform composes a message from a template and a design, merges in a record, and hands it to an account to send. Every send is logged.
Configuration is about the sending path: credentials, the from address, and whether your domain is set up so receiving servers trust it.
Incoming
The platform collects from a mailbox, matches each message against rules, and does something with it — creating a record, filing it against one, or handing it to extraction.
Configuration is about interpretation: which mailbox, how often, what matches what, and what happens to everything else.
One account can do both
Which is convenient and worth thinking about. If mail goes out from an address and replies come back to it, the same account serves both — and that is usually what you want, because replies land where something is watching.
Sending from an address nobody collects from produces replies that go nowhere, which is the commonest way an organisation stops hearing from its customers without realising.
Do not send from no-reply
It is a way of telling people you are not listening, and they will reply anyway — to an address that discards them. If you genuinely cannot monitor replies, say where to go instead, in the message.
Your domain must be set up for sending
Receiving servers check whether your domain authorises the sender. Without that, your mail is treated as suspicious however legitimate it is — and it is the single biggest determinant of whether your mail arrives.
That configuration lives at your domain, not in the platform, and it is worth confirming before concluding you have a mail problem.
Volume differs enormously
Most installations send far more than they receive. That shapes what you watch: outgoing is about deliverability and reputation, incoming is about not losing anything.
Failures look different
- Outgoing failure is usually visible — the log records a result and something can react.
- Incoming failure is silent. Mail arrives in a mailbox nobody collects from, or matches no rule and is discarded, and nothing anywhere records that an enquiry was lost.
That asymmetry is why the unmatched pile matters so much: it is the only visibility you have on the receiving side.
Worked example
An organisation sends from and collects at the same support address, so replies file against the case automatically. Unmatched mail goes to a queue checked each morning. When a partner changed their sending system, the resulting unmatched messages were noticed the next day rather than lost.
Recommendations
- Send from an address you collect from.
- Never use no-reply without saying where to go instead.
- Confirm your domain authorises sending.
- Watch the unmatched pile — incoming failure is silent.