E-mail

How E-mail Fits Together

Sending e-mail involves five things. Knowing which is which makes both configuration and troubleshooting straightforward.

Where to find it

Architect Panel → Integration & Connections:

• E-mail Accounts — the accounts mail is sent and received through

Architect Panel → Activity:

• E-mail Log — every message sent, with its result

Architect Panel → Layout & Pages:

• E-mail Designs — the wrapper
• E-mail Templates — the message

The five pieces

• Account — the mailbox and credentials mail is sent through, and its from address.
• Design — the wrapper: header, styling, footer.
• Template — the message: subject, body, merge fields.
• The send — something deciding to send, with a record to merge in.
• The log — what was actually sent and what happened to it.

They are separate on purpose

Each changes for different reasons. Credentials change when your provider does; the design changes at a rebrand; a template changes when the wording does. Keeping them apart means one change touches one thing.

Which piece is wrong?

Most e-mail problems resolve quickly once you identify the layer:

• Nothing sends at all — the account. Credentials, or the provider refusing.
• One message does not send — the log will say why; usually the recipient address.
• It sends but looks wrong — the design, or a template carrying its own layout.
• It sends but says the wrong thing — the template, or a merge field with nothing behind it.
• The wrong person got it — whatever chose the recipient, not the mail system.

Start at the log

Always. It answers whether the message was sent, to what address, with what content and with what result — which usually narrows the problem to one layer immediately.

Guessing before reading the log is how an afternoon disappears.

Sent is not delivered

The distinction to hold on to. A successful result means the platform handed the message to the account without error. Whether the recipient's server accepted it, and whether anybody read it, are different questions.

Most "we never received it" cases involve a message the log shows as sent successfully.

Mail is not guaranteed

Filtering, full mailboxes, greylisting and typos all intervene. Where something genuinely must reach somebody, do not rely on e-mail alone — and never treat a successful send as evidence they were told.

Worked example

A customer reports not receiving an invoice. The log shows it sent successfully to an address one character out; the activity log shows that address entered three weeks earlier during a call. Corrected, resent, and the cause explained — four minutes, because the log came first.

Recommendations

• Identify the layer before investigating.
• Read the log first, every time.
• Say "sent", not "received" when answering customers.
• Keep a second channel for anything that must arrive.

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.

Reading the E-mail Log

The log records every message the platform sent, what it contained and what happened.

Where to find it

Architect Panel → Activity:

• E-mail Log — every message sent, with its result

Architect Panel → Integration & Connections:

• E-mail Accounts — the accounts mail is sent and received through

Architect Panel → Security:

• Permissions — who can read the log

What an entry holds

• When it was sent, and through which account.
• Recipients, subject, body and attachments.
• The result, and the detail behind it.
• The source — what caused it.
• A tracking code.

The questions it answers

• "Did you send it?" — yes, at this time, to this address.
• "What did it say?" — the body as sent, not what the template would produce today.
• "Why did they get this?" — the source field.
• "Why four times?" — four entries, and the source tells you which process.

The source field is underused

It records what caused the message — which journey, task or action. When somebody receives something unexpected, or the same thing repeatedly, this is what identifies the mechanism.

Without it you are guessing between several processes that send similar messages.

Check the address before anything else

The commonest cause of a missing e-mail is a wrong address sent to perfectly successfully. Read the recipient carefully — transposed characters in a domain are easy to skim past — and if it is wrong, the activity log will say when and by whom it was entered.

Why the body is kept

Because "we sent you an e-mail about this" is rarely the end of the conversation. Keeping the body means you can see what customers actually received last month, not what the current template would produce — which matters after a template change.

The log is correspondence

Subjects, bodies and attachments are the content of your communications with people, which makes this one of the more sensitive stores in the platform.

Restrict access accordingly, and give it a retention period. A log kept indefinitely is an indefinite archive of everything you have ever said to anybody — and it is easy to overlook when listing what personal data you hold.

Watch the failures, not just the total

Reviewing failed sends periodically catches a decaying address list, an expiring credential and a recipient domain that has started rejecting you — all of which are cheaper to fix early.

Worked example

A customer complains of receiving the same reminder five times. The log shows five entries with the same source: a journey whose condition was re-evaluating each night. The fix is in the journey, and the log identified it in under a minute.

Recommendations

• Use the source field to identify what sent something.
• Read the recipient address carefully before investigating further.
• Set retention — this is correspondence, not metadata.
• Review failures as a routine, not after a complaint.