Skip to content

Mail logs: what happened to a message

Someone says they never got your email. Or a message you were expecting never arrived. A mailspace keeps a delivery log of the mail its mailboxes send and receive, and the Logs page is where you look it up: what the mail server did with a message, when, and — when something went wrong — what the receiving server said about it.

This page is about reading those screens. It doesn't change anything: Logs is a read-only view, so anyone who can open the mailspace can use it.

Mailbox mail, not mail your site sends

These logs cover mailbox mail — messages to and from the mailboxes in this mailspace. They do not cover mail that a WordPress site sends: password resets, order confirmations, contact-form notifications and the like. That is a separate CloudPress feature, Transactional Email, which lives in the site's own sidebar and keeps its own log-search screen there. Two consequences worth knowing before you start hunting:

  • If you're debugging a site that can't send password-reset mail, you are on the wrong page. Go to the site, open Transactional Email, and search its logs instead.
  • Transactional Email's availability is decided platform-wide, not per workspace — if the dashboard offers it at all, it's offered on every site.

The one overlap: if your site is set up to send through one of your mailboxes over SMTP, that really is mailbox mail, and it shows up here under Outgoing like any other message sent from that mailbox. For a fuller comparison of the two features, see Mailspace: overview.

Before you start

  • A mailspace that is finished and running. The Logs page talks to the mail server, so it only opens once the mailspace has been verified and created. Until then the dashboard sends you to the domain verification screen instead — see Verifying your domain. A mailspace whose mail is on hold — by us, or by an unpaid invoice — is closed off the same way: every page of it, Logs included, is replaced by a notice explaining the hold.
  • Nothing else. Viewing logs isn't an edit action, so a member whose role can't change the workspace can still read them.
  • Realistic expectations about history. The page shows the recent delivery activity the mail server still holds, newest first — it is not a permanent archive. See How far back the logs go below.

Open the logs

  1. Open the mailspace. Choose Mailspace in the workspace sidebar, then pick the mailspace whose mail you're tracing. Its Overview opens first.

  2. Choose Logs. In the mailspace's own sidebar, click Logs.

    Two shortcuts skip a step. The overview's Delivery Log card has a View All button that opens the logs on the Incoming tab, and its Delivery Failures card has one that opens them on the Issues tab.

  3. Pick the tab that matches your question. The page header carries the mailspace's mail domain and four tabs:

    Tab What it holds
    Incoming Mail delivered to your mailboxes, newest first.
    Outgoing Mail sent from your mailboxes, newest first.
    In Queue Messages still being sent, or waiting to retry.
    Issues Deliveries that bounced, or are still failing to send.

    Direction is decided per message, so Incoming and Outgoing are genuinely different lists — with one deliberate exception. Mail from one mailbox here to another mailbox here is both, so it appears in both tabs with an Internal badge next to the recipient. That is why you sometimes see the same message twice, and it means a message to a colleague on your own domain can be found under Outgoing where you'd expect to look for it.

    Every domain in the mailspace is covered by these lists; there is no per-domain switch to set.

Read a row

Incoming and Outgoing share one table: Status, Time, From, To and Size. In Queue and Issues use Status, Time, From, Recipients and Size instead, because a queued or failing message is tracked per recipient rather than as a single delivery.

Status is a badge, each with a small mark of its own:

Badge Meaning
Delivered The message reached its destination.
Sending Still in progress — no result yet.
Retrying A recipient's server didn't accept it yet; another attempt is scheduled.
Bounced It failed for good, and a bounce notice was sent back to the sender.
Failed It failed for good; no bounce notice has gone out.

Three things about these tables regularly surprise people:

  • There are no subject lines. A delivery log records envelopes and results, not message content, so you identify a message by address, time and size — never by its subject.
  • On mail you received, the To column shows only your own addresses. One inbound message can be addressed to people at several different companies; you see the recipients on your own domains, not anyone else's. On mail you sent, every recipient is shown, external ones included.
  • A blank sender is normal on bounces. Where a message has no envelope sender — which is how bounce notifications are sent — the From cell of the queue and issue tables reads <bounce>, and the delivery tables show a dash.

Where a message has more than one recipient, the Recipients cell summarises them: the total, then how many were delivered, are retrying, or failed. With a single recipient it shows that address instead of a count. On Issues the cell counts only the recipients that are actually failing, not everyone the message was addressed to.

Open a row for the full story

Click the chevron at the right of a row to expand it. On Incoming and Outgoing a row with no recorded delivery trace has no chevron — there's nothing to open. In Queue and Issues always show one.

On Incoming, Outgoing and Issues the expanded panel shows, as they apply:

  • Result — the outcome plus the receiving server's response code. It's only shown when something went wrong; for a delivered message the row's own badge already says so.
  • Server — the receiving mail server we talked to. Local deliveries between your own mailboxes have none to show.
  • Next retry — for a message that is still retrying, when the next attempt is due. This one appears on Issues only.
  • Timing — how long the delivery took end to end.
  • Reason — why it failed, usually in the receiving server's own words.
  • SMTP log — the conversation itself, step by step, each step timestamped and labelled, with the offset from the first step. This is the part to copy into a support ticket: it is the actual evidence of what the two servers said to each other.

In Queue expands differently. Instead of that panel you get one block per recipient: a status mark, the address, a plain-English line about what is holding it up, and small key=value chips carrying the technical detail — type, code, host, and a retry chip with the time of the next attempt and, in brackets, how many tries there have been.

Filter carefully — it only searches what is loaded

Each card has a filter box, and it does exactly one thing: it hides rows that don't match, in the browser. It does not go back and ask the mail server for more. Whatever the page loaded when you opened it is all the filter can ever find, so an empty result means "not among the entries on this page", not "this message doesn't exist".

Two useful details:

  • It matches addresses and statuses, as the box's own placeholder says: Filter by address or status…. Type a status word such as bounced to pull out just those, or part of an address to follow one correspondent. There is no subject to search.
  • It follows you across tabs. Type in any one filter box and the term is mirrored into the others, so switching tabs keeps the same filter applied rather than silently resetting it. When a table has nothing left to show, it says No entries match and repeats your term.

If the message you want isn't there, filtering harder won't surface it. Check the other direction's tab, then treat the message as older than the window the page loaded.

When a delivery failed

Start on the Issues tab, or on the overview's Delivery Failures card, which lists the most recent failures with Recipient, Error, Retry and Date columns. The Retry column is where the distinction that matters lives:

  • Permanent — the receiving server refused the message outright and there will be no further attempts. The address is wrong, the domain doesn't exist, the mailbox is full, or the far end rejected the mail. Nothing you do here will make it deliver: fix the address, or take up the rejection with the recipient's side, and send again.
  • Temporary (shown as "Temporary" with the number of tries so far) — the far end didn't take it yet, and the mail server will keep trying. Greylisting does this routinely, and so does a receiving server having a bad afternoon. Expand the row on Issues to see the Next retry time; on In Queue the same thing appears as a retry chip against the recipient. Usually the right action is to wait.

Which wording you get depends on the tab, and it surprises people. The plain-language sentences — The recipient's domain doesn't exist., The recipient's mailbox is full., The message was rejected by the receiving server., The receiving server asked us to wait (greylisting). — are what In Queue shows against each recipient. On Issues, and in the delivery tables, the Reason is the receiving server's own words instead, and a plain sentence only stands in when the server gave us nothing to quote. That is why the same failure can read plainly on one tab and technically on another.

A message that shows as Delivered on Incoming but that the recipient can't find was delivered and then filed somewhere. Check that mailbox's rules and its out-of-office setup on Mail rules and out-of-office replies, and check the mailbox isn't out of room on Storage and retention.

How far back the logs go

The Logs page shows what the mail server still holds, newest first, up to a fixed number of entries. Incoming and Outgoing are two views of one fetch and share a single budget between them, so a busy day in one direction leaves less room for the other; In Queue and Issues each get a budget of their own. It is not configurable: there is no retention setting for delivery logs anywhere in the mailspace screens, and no way to extend the window or export the history. Old activity ages out of the server's own records and simply stops appearing.

So treat these screens as a live troubleshooting tool, not as evidence you can come back to next quarter. If a delivery matters — a disputed invoice, a legal notice — copy the expanded row's SMTP log out while it's still there.

The overview's Delivery Log card is deliberately shorter still: it shows only the handful of most recent entries as a glance-check, with Status, From, To and Date. Use View All for the real list.

Next steps