> ## Documentation Index
> Fetch the complete documentation index at: https://docs.protodesk.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Test and troubleshoot email delivery

> Test real inbound and outbound email, read delivery states, and investigate forwarding, recipient, and attachment failures.

Check inbound forwarding and outbound delivery separately. A working forwarding route does not prove that a reply reached the customer's mailbox, and a saved reply is not the same as a delivered email.

Owners and Admins can manage **Settings → Email**. Teammates with reply permission can inspect the relevant conversation and its message state.

## Run a controlled delivery test

1. In **Settings → Email**, check the support address, **Forwarding verified**, **DNS verified**, and **Email is active**.
2. Select **Send test email**. This sends to the signed-in administrator's email address; check that mailbox, including spam or quarantine.
3. From a separate account you control, send a new message to your support address with a recognizable test subject.
4. Find the message in **Threads**, reply by email, and confirm receipt at the original sender's mailbox.

Use an actual email conversation for this test. **Add test thread** conversations explicitly keep replies inside Protodesk and do not test external delivery. The setup forwarding probe is also not a normal customer thread.

## If incoming mail is missing

* Confirm that the message reached your support mailbox.
* Compare the provider's forwarding destination with the exact address under **Receiving emails**.
* Check that the rule is enabled, not merely approved as a destination.
* Check provider filters, forwarding restrictions, spam handling, and whether the rule covers the tested alias.
* Use the forwarding verification process; complete sending-domain setup first if the probe itself cannot be sent.

Do not keep recreating the same conversation or changing the primary support address while diagnosing the route.

## If a reply does not arrive

Open the conversation and inspect the individual reply before retrying. A queued message may still be processing; a scheduled message is waiting for its scheduled time. If the UI reports a failure, correct the stated problem and use the available retry control rather than immediately composing duplicate replies.

Check the email setup and the recipient address. Ask the recipient to check spam or quarantine when appropriate. If attachments are involved, confirm that they finished uploading and try a smaller controlled test; the encoded email includes both the body and attachments, not just the raw file sizes.

## Read outbound delivery metrics

**Settings → Email → Outbound delivery metrics** offers **7d**, **14d**, and **30d** windows.

* **Queued:** delivery is pending.
* **Sent:** the message was handed off to the sending provider.
* **Delivered:** the receiving system accepted it; this does not prove it was read or placed in the inbox.
* **Bounced:** the receiving system rejected it.
* **Failed:** delivery could not be completed.

The aggregate counts are not a substitute for checking the specific reply. An empty period also does not prove that a setup-test message failed; setup probes are separate from ordinary conversation replies.

If the failure continues, contact support with the workspace, conversation link, approximate time and timezone, channel, visible status, and non-secret error text. Share only the sender or recipient details needed to investigate. Never send credentials.

Related: [email setup](/guides/set-up-your-support-email), [forwarding](/guides/forward-email-to-protodesk), and [DNS verification](/guides/verify-your-email-sending-domain).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.