Email Send Log

Email send log

Every email FreeITSM tries to send is recorded, whether it succeeded or not. You'll find it under Tickets → Settings → Mailboxes, on the clock icon beside a mailbox, in the Outbound tab.

The developer companion is Email send log — Developer Guide.

---

Why it exists

FreeITSM has always logged mail arriving: what came in, what became a ticket, what was rejected and why. There was nothing for mail going out.

That left a blind spot. A successful send showed up in the ticket, so you could see it. A failed send showed up nowhere at all, except as a line in a file on the server that nobody reads until they already suspect a problem — and the whole difficulty with a silent send failure is that nothing makes you suspect one.

Issue #67 is what it looks like in practice. A mailbox in app-only mode could not send anything. The workflow failures were at least visible in the workflow run history, but the ticket acknowledgement template was failing on the same call, every single time, and said so only here:

[15-Aug-2026 13:30:51] Template email error (ticket_assigned, ticket 611):
Graph API send failed: /me request is only valid with delegated authentication flow.

Three failures over half an hour, invisible from the UI. If the fault had affected only templates and not workflows, the first sign of it would have been a customer saying they never got a reply.

---

What you see

Column	What it tells you
Date/time	When the attempt was made, in your own timezone
To	The recipient, and a link to the ticket if there was one
Subject	The subject line, and the error text underneath when it failed
Sent by	Which part of FreeITSM asked for the send — the eight routes below
Result	Sent, Failed, or Not sent

Not sent means FreeITSM decided not to send at all, and says why underneath — at present that is an automatic email whose templates are all limited to particular senders, none of which covered this one. It is not a failure and does not count towards the red badge: nothing went wrong, and nothing arrived either, which is exactly the combination that is otherwise impossible to find out about.

A red number on the Outbound tab is the count of failures for that mailbox. It loads as soon as you open the activity view, so you don't have to click into the tab to discover something is wrong.

Use Failures only in the dropdown to strip out the successes, and the search box to find a particular recipient, subject, or error message.

---

The eight routes

"Sent by" tells you which part of FreeITSM asked for the email. This matters more than it might sound: most sending faults affect every route at once, and knowing that only one route is failing narrows the problem enormously.

1. Analyst reply

What it is: a reply or forward sent by an analyst from the ticket screen. The highest-volume route on most service desks, and the only one a person is watching in real time.

When it fails: the analyst is told immediately, so this is the one route where a failure was already visible. It's logged anyway, because "did that reply actually go?" is a question worth being able to answer a week later, and because a pattern of failures across a day is invisible when each one is only a transient error message on somebody's screen.

2. Ticket template

What it is: the automatic acknowledgements configured under Tickets → Settings → Templates — new ticket raised, ticket assigned, ticket closed.

When it fails: silently. Nobody is watching, the ticket carries on regardless, and the requester simply never hears anything. This is the route that made issue #67 so hard to spot, and the strongest single argument for this log existing.

3. Workflow action

What it is: a Send email action in a workflow.

When it fails: the workflow run is marked failed, and the error is visible in the workflow history. So this route had a log already — but only if you knew to look in the Workflows module for what is fundamentally an email problem. It appears here too, alongside every other send, so you can see at a glance whether one route is failing or all of them.

4. SLA alert

What it is: breach and approaching-breach warnings, sent to whoever the SLA rules escalate to.

When it fails: silently, and expensively. The entire point of an SLA alert is to interrupt somebody before a target is missed. An alert that never arrives is worse than having no alerts at all, because the team has been trained to rely on being told.

Each recipient is logged separately. One bad address in an escalation list shouldn't read as the whole alert having failed, and a whole alert failing shouldn't look like one address being wrong.

5. Portal / system

What it is: self-service portal emails that aren't attached to a ticket — chiefly account verification, where somebody registering has to confirm their address.

When it fails: the person cannot finish registering and has no way to tell you, because the thing that's broken is the channel they'd use. They just go away.

This route also logs a failure when no mailbox could be found to send from at all, which is recorded with no mailbox against it. See "Sends with no mailbox" below.

6. Password reset

What it is: the reset link sent when an analyst uses Forgot password.

When it fails: the analyst is locked out and quite likely believes the fault is their password rather than the email. The screen deliberately gives the same reassuring message whether or not the account exists — that's an anti-enumeration measure, and correct — but it does mean a genuine send failure is indistinguishable from a mistyped username at the point of use. This log is where the difference shows.

7. Knowledge article shared

What it is: an article sent to somebody from the Knowledge module, optionally with a PDF attached.

When it fails: the sender is told, so it isn't invisible. It's logged because the Knowledge share screen can send through its own SMTP settings rather than a configured mailbox, which makes it a genuinely separate path that can break on its own while everything else is fine.

8. Change record shared

What it is: the same thing from the Change Management module.

When it fails: as above. It's a separate route from the knowledge share, despite being nearly identical code, so the log can tell you which of the two is broken rather than making you guess.

---

Sends with no mailbox

Some failures happen before FreeITSM has even chosen a mailbox to send from — no mailbox is configured, none is authenticated, or the only one is set up in a way that can't send.

Those are recorded with no mailbox against them, which means they can't appear under any particular mailbox's Outbound tab. That's deliberate rather than a gap: they aren't a fault of any one mailbox, they're a fault of the configuration as a whole.

They're reachable through the API with mailbox_id=0, and it's worth knowing they exist, because "no mailbox could send this" is exactly the failure a mailbox-by-mailbox view would hide.

---

What it does not record

• Whether the email was delivered. The log records what happened when FreeITSM handed the message to Microsoft, Google or your SMTP server. A message accepted and then bounced, greylisted or filed as spam counts as Sent here, because that is genuinely what FreeITSM knows. Delivery is your mail provider's log, not this one.
• The body of the message. Recipient and subject only. The ticket itself already holds what was said, and duplicating message bodies into a log would put a second copy of potentially sensitive content somewhere nobody expects it.
• Anything older than the log itself. It starts recording from the version that introduced it; it can't tell you about last month.

---

Related pages

• Why app-only mailboxes could not send email — the bug that prompted this
• Mailbox authentication — setting up sending, and the troubleshooting table
• Email send log — Developer Guide — the table, the helper, and how to add a route