If a customer says "I never got your email," don't guess. Open cPanel → Email → Track Delivery and search for the address. It logs every message that touched your mail server, with a status for each attempt: delivered, deferred, bounced, or rejected before it ever left. That status tells you in seconds whether the problem is on your end, the recipient's end, or somewhere in between, before you write a single word to support.
Finding the message
Track Delivery is a cPanel tool, reached through the portal's one-click login (Services → your hosting → cPanel). Once inside, search by sender address, recipient address, or a date range. Each row is one delivery attempt, and a single email can generate more than one row if the server retried it. Click a row to expand the full transport log for that attempt, which shows the exact response the receiving server sent back.
Reading the statuses
Four statuses cover almost everything you'll see:
- Delivered - the message reached the destination mail server and was accepted. If the recipient still says it's missing, the problem is downstream of delivery: their spam folder, a filter rule, or a full mailbox on their side. This is a receiving problem, not a sending one.
- Deferred - a temporary failure. The receiving server said "try again later," usually because it's rate-limiting unfamiliar senders or is temporarily unreachable. Deferred messages retry automatically for a period before either delivering or bouncing. One or two deferrals aren't unusual; a long run of them on a new domain often means the domain hasn't built sending reputation yet, which is exactly what warming up a new sending domain addresses.
- Bounced - a permanent failure. The receiving server rejected the message outright and won't retry. The expanded log shows the numeric code and reason text from the receiving server, and that's where the real diagnosis happens.
- Rejected before sending / virus or spam - the message never left your server at all. It was stopped locally, usually by a spam or malware filter on the outbound side, before it reached the recipient's mail server.
Turning a bounce into a fix
The expanded log entry for a bounced message includes the receiving server's response verbatim. That response is the fastest way to know what to fix. A code like 550 or 554, plus the text after it, tells you whether the address doesn't exist, the mailbox is full, or the message got filtered as spam. The full breakdown of what each code means and how to act on it is in email bounce messages decoded.
If the bounce text mentions authentication, a blocklist, or "unable to verify," check your domain's SPF and DKIM setup first. Hosted domains get both configured automatically, but if you've recently changed mail providers or added a new sending service, an outdated or missing record is a common cause of these bounces.
When delivery looks fine but mail still lands in spam
Track Delivery only tells you what happened at the transport layer, accepted or rejected. It doesn't know what the recipient's spam filter did after that. If a message shows Delivered but the customer can't find it, the next step is DMARC. Without a DMARC policy, receiving servers have no instruction for what to do with mail that fails alignment checks, and some filter it to spam quietly rather than bouncing it. DMARC setup, policies, and the Gmail/Yahoo rules covers adding the record and reading the reports that show you exactly which sources are sending as your domain.
For a deeper trace than Track Delivery provides, including exact hop-by-hop timing, pull the full headers from the actual message the recipient received (if they can forward it to you) and read the Received chain from bottom to top. How to read email headers to trace delivery problems walks through that process and where to find the header view in each mail client.
When to open a ticket
Most delivery issues resolve once you match the bounce code to a cause. Open a ticket through Support → New ticket in the portal if Track Delivery shows repeated deferrals or bounces you can't explain from the response text, if a message shows Delivered but you suspect it's being blocked at the server level rather than filtered to spam, or if you need someone to check server-side mail logs beyond what Track Delivery surfaces. Include the exact timestamp and recipient address from the Track Delivery entry. That log reference lets support jump straight to the relevant transport record instead of starting from scratch.