E-mail Log

Reading the E-mail Log

The e-mail log answers a question that comes up constantly: did we send it, and what did it say?

Where to find it

Architect Panel → Activity:

• E-mail Log — every message sent, with its result
• Correspondence — letters and documents, logged separately

Architect Panel → Integration & Connections:

• E-mail Accounts — the accounts messages are sent through

What an entry holds

• When it was sent.
• Account — which sending account was used.
• Recipients.
• Subject, body and attachments — the message as sent.
• Result — whether the send succeeded.
• Log — the detail behind that result.
• Source — what in the platform caused it.
• Tracking code.

Why the whole message is kept

Because "we sent you an e-mail about this" is rarely the end of the conversation. What it actually said, which address it went to, and what was attached are the things in dispute.

Keeping the body also means a template change is visible in its effects — you can see what customers received last month, not what the current template would produce.

Sent is not delivered

A successful result means the platform handed the message to the sending account without error. It does not mean the recipient's server accepted it, and it certainly does not mean anybody read it.

Most "we never received it" cases involve a message the log shows as sent successfully. That narrows the problem to the address, the recipient's filtering, or their mailbox — which is useful, but it is not the same as proof of delivery. Say "we sent it at 14:02 to this address", not "you received it".

Source is the most underused field

It tells you what caused the message — which journey, task or action. When a customer receives something unexpected, or receives the same thing four times, source is what identifies the mechanism. Without it you are guessing which of several processes sends similar messages.

Check the address, not just the result

The commonest cause of a missing e-mail is a wrong address that was 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 tell you when and by whom it was entered.

The log contains correspondence

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

Restrict access accordingly and give it a retention period. An e-mail log kept indefinitely is an indefinite archive of everything you have ever said to anybody.

Worked example

A customer says they never received an appointment confirmation. The log shows it sent successfully to an address one character out. The Activity Log shows that address was entered during a call three weeks earlier. The address is corrected, the message resent, and the agent is shown how it happened — the whole enquiry taking about four minutes.

Recommendations

• Distinguish sent from delivered when answering customers.
• Read the recipient address carefully before investigating anything else.
• Use the source field to identify what sent a message.
• Set retention and restrict access — this is correspondence.

Failed Sends and Retries

Sends fail. The useful skill is telling apart the failure that will succeed on a retry from the one that never will.

Where to find it

Architect Panel → Activity:

• E-mail Log — the result and the detail behind it

Architect Panel → Integration & Connections:

• E-mail Accounts — the sending account and its credentials
• E-mail Relay Clients — relay configuration

Read the log detail, not just the result

The result says it failed. The detail recorded alongside says why, and that determines everything about what to do next. Retrying without reading it is how an afternoon disappears.

Transient failures

A timeout, a temporary rejection, a provider having a bad ten minutes. These succeed on a retry, and the right response is to retry — once, and then look properly if it fails again.

Permanent failures

An address that does not exist, a rejected credential, a message refused for its content or size. Retrying achieves nothing and can make things worse: repeated sends to a dead address damage your sending reputation, which affects every other message you send.

These need the underlying cause fixed — the address corrected, the credential renewed, the attachment reduced.

Authentication failures are urgent

A rejected credential usually means every message is failing, not just the one you are looking at. Check whether other recent sends failed the same way before treating it as an isolated incident — an expired sending credential can silence a system's entire outbound communication without anybody noticing for a day.

Look at the pattern

Before fixing one message, ask what else failed nearby:

• Many failures to one domain — that recipient is blocking or greylisting you.
• Many failures across all domains in one window — the account, relay or provider.
• Scattered individual failures — bad addresses, which is a data quality problem.

The third is the one most often treated as a series of unrelated incidents when it is really one problem with data capture.

Resending is a decision

Check whether the recipient has since received the information another way, and whether the content is still accurate — resending a three-day-old appointment reminder for an appointment that has passed is worse than not resending it.

Tell somebody when it matters

If a failed message carried something the recipient needed — an invoice, an appointment, a decision — the failure needs a person to act, not just a fix. The log tells you what did not arrive; only somebody contacting them closes it.

Worked example

A morning check shows fourteen failures. Twelve are to one domain with a temporary rejection — that recipient is greylisting, and they succeed on retry. One is a non-existent address, corrected at source. One is an attachment over the provider's size limit, and the document is sent as a link instead. Three causes, three different responses, and none of them was "retry everything".

Recommendations

• Read the failure detail before retrying.
• Never repeatedly retry a permanent failure.
• Check the pattern before treating a failure as isolated.
• Treat authentication failures as urgent and systemic.