Missing inbound email - delivery shown in logs

Issues
1

Issue Description

I’ve been consistently (for months) had issues receiving MFA codes from Action 1: they show up in the logs, but never appear in the mailbox.

I’ve checked all folders (junk etc.) and done a broad search, using multiple different IMAP clients which are set to sync all folders with unlimited storage.

The strange thing is, I can even see the DMARC aggregate reports that Stalwart generates for the sender - and the messages show in the logs as delivered.

Could Stalwart be doing something else with these messages instead of delivering them? How can I trace where these are going?

Expected Behavior

The email should be accepted and delivered to the recipient’s inbox (or if categorized as junk, then into the junk mail folder).

Actual Behavior

Nothing appears in any folders in the mailbox. Other emails appear fine.

Reproduction Steps

Try to login to Action 1 which generates an MFA code email, check inbox: no code, check junk mail: no code, check Stalwart logs: delivery shows and the DMARC aggregate report also generates.

Relevant Log Output

stalwart.log.2026-07-27:243:2026-07-27T14:07:37Z INFO SMTP MAIL FROM command (smtp.mail-from) listenerId = "smtp", localPort = 25, remoteIp = 54.240.27.195, remotePort = 42201, from = "0101019fa3e70976-b2ce3eb1-5d60-4d97-912d-2b594ba1ccb7-000000@mail.na-2.action1.com"
stalwart.log.2026-07-27:245:2026-07-27T14:07:38Z INFO DKIM verification passed (smtp.dkim-pass) listenerId = "smtp", localPort = 25, remoteIp = 54.240.27.195, remotePort = 42201, strict = false, result = [DKIM verification passed (dkim.pass) { domain = "na-2.action1.com" }, DKIM verification passed (dkim.pass) { domain = "amazonses.com" }], elapsed = 113ms
stalwart.log.2026-07-27:247:2026-07-27T14:07:38Z INFO DMARC check passed (smtp.dmarc-pass) listenerId = "smtp", localPort = 25, remoteIp = 54.240.27.195, remotePort = 42201, strict = false, domain = "na-2.action1.com", policy = "reject", result = DMARC check passed (dmarc.pass), elapsed = 53ms
stalwart.log.2026-07-27:248:2026-07-27T14:07:42Z INFO Queued message for delivery (queue.queue-message) listenerId = "smtp", localPort = 25, remoteIp = 54.240.27.195, remotePort = 42201, queueId = 320615236174384269, from = "0101019fa3e70976-b2ce3eb1-5d60-4d97-912d-2b594ba1ccb7-000000@mail.na-2.action1.com", to = ["[redacted]"], size = 53505, nextRetry = 2026-07-27T14:07:42Z, nextDsn = 2026-07-28T14:07:42Z, expires = 2026-07-30T14:07:42Z
stalwart.log.2026-07-27:249:2026-07-27T14:07:42Z INFO Delivery attempt started (delivery.attempt-start) queueId = 320615236174384269, queueName = "local", from = "0101019fa3e70976-b2ce3eb1-5d60-4d97-912d-2b594ba1ccb7-000000@mail.na-2.action1.com", to = ["[redacted]"], size = 53505, total = 1
stalwart.log.2026-07-27:250:2026-07-27T14:07:42Z INFO New delivery attempt for domain (delivery.domain-delivery-start) queueId = 320615236174384269, queueName = "local", from = "0101019fa3e70976-b2ce3eb1-5d60-4d97-912d-2b594ba1ccb7-000000@mail.na-2.action1.com", to = ["[redacted]"], size = 53505, total = 1, domain = "[redacted.com]"
stalwart.log.2026-07-27:251:2026-07-27T14:07:42Z INFO Message ingested (message-ingest.ham) queueId = 320615236174384269, queueName = "local", from = "0101019fa3e70976-b2ce3eb1-5d60-4d97-912d-2b594ba1ccb7-000000@mail.na-2.action1.com", to = ["[redacted]"], size = 53505, total = 1, accountId = 13, documentId = 6087, mailboxId = [0], blobId = "400637f11c332dab28a95f145a92f313eaa838ec6885897b36eb525a718c9c40", changeId = 6504, messageId = "0101019fa3e70976-b2ce3eb1-5d60-4d97-912d-2b594ba1ccb7-000000@us-west-2.amazonses.com", size = 53542, elapsed = 0ms
stalwart.log.2026-07-27:252:2026-07-27T14:07:42Z INFO DSN success notification (delivery.dsn-success) queueId = 320615236174384269, queueName = "local", from = "0101019fa3e70976-b2ce3eb1-5d60-4d97-912d-2b594ba1ccb7-000000@mail.na-2.action1.com", to = ["[redacted]"], size = 53505, total = 1, to = "[redacted]", hostname = "localhost", code = 250, details = "OK"
stalwart.log.2026-07-27:253:2026-07-27T14:07:42Z INFO Delivery completed (delivery.completed) queueId = 320615236174384269, queueName = "local", from = "0101019fa3e70976-b2ce3eb1-5d60-4d97-912d-2b594ba1ccb7-000000@mail.na-2.action1.com", to = ["[redacted]"], size = 53505, total = 1, elapsed = 0ms
stalwart.log.2026-07-27:254:2026-07-27T14:07:42Z INFO Delivery attempt ended (delivery.attempt-end) queueId = 320615236174384269, queueName = "local", from = "0101019fa3e70976-b2ce3eb1-5d60-4d97-912d-2b594ba1ccb7-000000@mail.na-2.action1.com", to = ["[redacted]"], size = 53505, total = 1, elapsed = 1ms
stalwart.log.2026-07-27:545:2026-07-28T00:00:00Z INFO DMARC aggregate is being prepared (outgoing-report.dmarc-aggregate-report) reportId = 1785110400, domain = "na-2.action1.com", rangeFrom = 2026-07-27T00:00:00Z, rangeTo = 2026-07-28T00:00:00Z```

### Stalwart Version
v0.14.x

### Installation Method
Binary (Linux)

### Database Backend
RocksDB

### Blob Storage
RocksDB

### Search Engine
Internal

### Directory Backend
Internal

### Additional Context
- Hardly any changes from default config
- Thunderbird Desktop & Thunderbird Mobile as email clients
- No client-side filters or processing
- Other emails arriving fine

### I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.
on

### I have searched this support forum (open and closed topics) and confirm this is not a duplicate.
on

### I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I'd prefer a human-only reply, I'll add the no-ai tag to my topic.
on
2

mailboxId = [0] is INBOX, and that event is only emitted once the write has succeeded, so the message really is in account 13’s INBOX with an IMAP UID assigned. Nothing discarded it or filed it elsewhere, and it was not suppressed as a duplicate (that path logs a different event). So it is in the store and your client is not showing it.

You are on 0.14.x, which is the first thing to address here: 0.16.6 fixed an IMAP bug where UID FETCH N:* could miss messages appended to a mailbox the client currently has selected. That matches your symptom closely, since Thunderbird sits in IDLE on INBOX while the delivery arrives on a different connection, and once the client’s UIDNEXT has moved past the missed UID it never goes back for it. It would also explain why every client you tried shows the same thing, if they all synced from the same point onward.

To check this without depending on any client’s cached state, query the server directly:

openssl s_client -connect yourserver:993 -crlf
a LOGIN user pass
b SELECT INBOX
c UID SEARCH HEADER MESSAGE-ID "0101019fa3e70976-b2ce3eb1-5d60-4d97-912d-2b594ba1ccb7-000000@us-west-2.amazonses.com"

A hit means the message is visible to IMAP and it is the client-side sync that is stale, which adding the account to a fresh profile will confirm. If it still reproduces on a current 0.16.x, that is worth a new report with the trace.