With the function Track delivery In cPanel, you can investigate how emails were processed by the mail server. This is especially helpful if a message did not arrive, a forwarding rule is not working as expected, or a sender receives an error message.
Instead of changing settings on suspicion, you can use it to first check whether a relevant message appears in the delivery history and what result the mail server has logged for it.
In this guide, we will show you step by step how to use the delivery tracking in CURIAWEB and how to correctly interpret the most important information.
Briefly explained: Delivery tracking is a diagnostic tool. It shows information about how emails are processed by the mail server, but it does not automatically prove that a message was read by the recipient or that it ended up in their inbox rather than their spam folder.
When should you use delivery tracking? #
The function is particularly helpful if you want to investigate a specific email problem.
Typical cases include, for example:
- An expected email has not arrived.
- A sent message does not seem to reach the recipient.
- An email forwarding is not working as expected.
- A sender receives a non-delivery report.
- You want to check how the server processed a specific message.
The more precisely you know the sender, recipient, and approximate time of dispatch, the easier it is to assign the message in question.
What shipment tracking doesn't show #
Before you begin the diagnosis, an important limitation of the function must be noted.
A successful transfer or processing does not automatically mean that the message will later appear in the recipient's visible inbox.
A downstream mail server can, for example, still filter a message or sort it into a spam folder. Rules within a mailbox can also influence where a message is ultimately displayed.
Important: „Successfully delivered“ and „seen by the recipient in the inbox“ are not technically the same thing.
1. Open Track Delivery in cPanel #
Log in to your CURIAWEB cPanel.
Scroll to the section on the homepage Email and click on Track delivery.
cPanel then opens the interface for investigating email traffic.
2. Search for a specific recipient address #
When investigating a specific message, the recipient address is a good starting point.
Enter the address in question into the designated search field.
For example:
info@deine-domain.ch
Then start the search or the report.
cPanel displays the available delivery information for this.
Practical Tip: Search as specifically as possible for a specific problem. A long list of many different messages unnecessarily complicates the diagnosis.
3. Consider shipping time #
If there are multiple messages to the same address, you must identify the correct message.
For this purpose, compare the time in particular with the information provided by the sender.
For example, if someone tells you that the message was sent around 10:30 AM, focus on entries in that time range.
Note that the time information of the sender, their email program, and the server do not have to be displayed as exactly identical in every situation.
4. Check sender and recipient #
Check for the found entry whether sender and recipient actually match the searched message.
A similar timestamp alone is not enough if multiple emails have been processed.
Check in particular the full email addresses and not just the displayed name of a sender.
5. Check delivery status #
Delivery tracking uses status information and symbols to show how a message was processed.
Depending on the result and the cPanel version, different states can be displayed, such as successful delivery, failed delivery, or other processing states.
Do not rely solely on an icon for diagnosis. Open or check the detailed information for the relevant entry as well.
Properly interpreting successful delivery #
If cPanel shows successful processing or delivery, this initially means that the email process in question has been successfully completed from the perspective of the logged delivery path.
For example, in the case of a local mailbox, the message may have been successfully handed over to the local mail delivery system.
In the case of an external delivery, an external mail server may have accepted the message.
Important: Even if an external mail server has successfully accepted a message, CURIAWEB cannot deduce in which folder the external provider will subsequently display it. The recipient should therefore check spam, junk, and filter folders, among others.
How to correctly interpret a failed delivery #
If a message is displayed as failed, the detailed information is particularly important.
There, the mail server may have logged a technical reason for the failure.
The error message is usually much more helpful for diagnosis than the general statement that the email did not arrive.
Therefore, look for the specific SMTP status or the actual server message.
Understanding SMTP Status Codes #
Mail servers use SMTP response codes to describe the outcome of a delivery attempt.
For an initial classification, the first digit and the error class are particularly helpful.
2xx generally stands for a successful SMTP action.
4xx basically indicates a temporary error. A subsequent redelivery may be possible.
5xx fundamentally designates a permanent error for the delivery attempt in question or the requested action.
Briefly explained: A
4xx-error simply means „currently not possible,“ while a5xx- indicates that the error is generally a permanent rejection or an error that is unlikely to disappear simply by waiting, without any changes.
Read the complete error text #
The numerical code alone is often not sufficient for an accurate diagnosis.
A 550-Errors can have various causes, for example. The corresponding text from the mail server is therefore also crucial.
There may be hints there such as:
unknown user
mailbox unavailable
Message rejected
or other concrete information.
The exact wording depends on the mail server involved.
Basic rule: In the event of an email error, always consider the complete SMTP code along with the full error message. A single word or just the first number is not sufficient for a reliable diagnosis.
Error „User unknown“ or unknown recipient #
If the message indicates that the recipient is unknown, you should first check the full recipient address.
Check, for example:
info@deine-domain.ch
for typos.
For a locally hosted address, you should also check whether the email account in question or a suitable forwarding address actually exists.
We show you how to check email accounts at Manage or delete email account in cPanel.
Mailbox full error #
A delivery can fail if a mailbox has reached its allowable storage limit or if there is not enough storage available in the involved environment.
If the error message contains indications of a full mailbox, quota, or missing storage space, you should therefore check the storage usage.
We show how this works at Check and clean up email storage in cPanel.
Transient errors with 4xx #
An error from the 4xx-Class generally indicates a temporary problem.
Depending on its configuration, the sending mail server may attempt to deliver the message again later.
The exact cause can vary greatly. Therefore, you should read the complete error text here as well.
A temporary error does not automatically mean that you have to manually resend the email immediately.
Persistent errors with 5xx #
A 5xx-Status generally indicates a permanent error or a permanent rejection of the SMTP action in question.
A renewed attempt with unchanged conditions will often not solve the underlying problem.
Depending on the message, typical causes can be a non-existent address, rejection by the destination server, or another faulty or unacceptable mail configuration.
The actual cause in turn arises from the complete error text.
What does an external server response mean? #
When sending a message to an external recipient, the CURIAWEB mail server communicates with the mail server of the destination domain.
If this external server rejects a message, its response may appear in the delivery information.
This is diagnostically very valuable because it shows that the message was supposed to leave the CURIAWEB mail server, but the target system did not accept it.
Important: A rejection by the destination server does not automatically mean that the CURIAWEB mail server is defective. The deciding factor is the reason the receiving server gives for the rejection.
What does local delivery mean? #
If the recipient's mailbox is on the same mail server or in the local mail environment, the message can be processed locally.
In this case, no external destination mail server is required for the actual delivery of the local mailbox.
As a result, shipment tracking may show a different transport or routing path than for an external address.
Router and Transport in Detail #
In the detailed message information, technical details regarding the used Router and Transport appear.
These details provide a simplified description of how the mail server decided where a message belongs and through which mechanism it was further processed or delivered.
For normal users, it is not necessary to know all internal designations by heart.
However, for troubleshooting, this information can help determine whether a message was processed locally or forwarded to an external destination, for example.
Share routing and delivery tracking #
If your website is hosted by CURIAWEB, but your domain's emails run through an external provider, the mail route actually being used is of particular interest.
An incorrect routing setting can cause locally generated messages to be processed differently than expected.
We show how to control the routing configuration at How to properly set up email routing in cPanel.
Check forwarding with delivery tracking #
If email forwarding doesn't seem to be working, you should first check whether the original message was processed at all and what delivery information is available for it.
Depending on the mail flow, information regarding the forwarding or the further destination may become visible.
Carefully compare the displayed destination address with the actual desired redirection.
We explain how to set up a redirection at Set up email forwarding in cPanel.
Forwarding was processed, but the message is missing at the external destination #
When a message is forwarded to an external mailbox, an additional mail server enters the delivery path.
The external provider can review and process the forwarded message according to its own rules.
That is why you should determine whether the message was already rejected during the forwarding attempt or whether the external system accepted it.
If it was accepted by the destination server, the recipient side should then be checked for spam filters, mailbox rules, and other local causes.
Message does not appear in delivery tracking #
If you can't find an expected message, you shouldn't immediately assume that it has been deleted.
Check first:
- whether you are looking for the correct recipient address
- whether the specified shipping date is correct
- whether a different spelling or address was used
- whether you consider the relevant time period available for the surface
If the sender sent the message to a misspelled domain, it may not have reached your mail server at all, for example.
A message can be lost before it reaches your server #
Delivery tracking can only display operations for which the server has corresponding information.
If a message already fails at the sender's end or on a previous system and never reaches your CURIAWEB mail server, local delivery tracking cannot fully document this process.
Important: „No entry found does not automatically mean that CURIAWEB has lost the message. It can also mean that the message in question never reached the server or was not found within the available data.
Ask the sender for the non-delivery report #
If an external sender claims that a message cannot be delivered, the complete non-delivery report is very helpful.
If possible, please ask the sender not only for a screenshot with the phrase „Mail could not be delivered“, but for the complete technical error message.
Of particular importance are:
- Recipient address
- Time
- SMTP status code
- full error text
This allows the problem to be investigated in a much more targeted manner.
„Delivered does not mean read“ #
Delivery tracking is not a read receipt.
When a message has been successfully delivered, it does not mean the recipient has opened or read it.
Likewise, it cannot be reliably deduced from this whether a person has consciously ignored the message.
Briefly explained: Mail servers can log technical delivery. You cannot deduce from this whether a human actually read the message.
„For external recipients, “delivered" does not necessarily mean inbox delivery. #
The placement in the inbox is also a secondary question.
For example, an external provider can convert an accepted message into:
Spam
Junk
or sort them into a folder set up by the user.
Since the message was accepted by the external system, you should therefore continue the search on the recipient side.
Differentiate between spam and deliverability issues #
When messages are technically delivered, but regularly end up in the spam folder, that is a different problem than a failed SMTP delivery.
In this case, among other things, you should check the email authentication and deliverability of your domain.
We cover the corresponding cPanel function under Check email deliverability in cPanel.
Check filters for disappeared messages #
If a message was successfully processed locally but does not appear where you expect it to, email filters may also play a role.
A filter can, for example, move messages to another folder or process them in other ways.
Therefore, check the rules of the affected account under Create and manage email filters in cPanel.
Additionally, you should check whether a global email filter could be applied to the message.
Check default address for unknown recipients #
If messages to a non-existent address on your domain are unexpectedly delivered, forwarded, or rejected, you should check the catch-all address.
It determines how the mail server handles unknown recipients.
We explain the configuration at Default Address in cPanel: Catch-All and Unknown Recipients.
Diagnostic example: Message to local mailbox missing #
Assuming a customer has sent a message to:
info@deine-domain.ch
sent, but you can't find them.
Proceed systematically:
- Search in Track delivery after
info@deine-domain.ch. - Compare the time and sender with the customer's information.
- Check the delivery status.
- Open the detailed information if necessary.
- If the message was successfully delivered locally, then check webmail, the spam folder, and filters.
- If it was rejected, read the full SMTP error.
This narrows down the cause step by step instead of changing settings at random.
Diagnostic example: Message to external recipient not delivered #
For example, you send from:
info@deine-domain.ch
an
kunde@externe-domain.ch
and the customer cannot find the message.
Search for the recipient in question and check the delivery history.
If the message was rejected by the external mail server with an error, examine the displayed response.
Once it has been accepted by the target system, further processing lies outside the original SMTP transfer step. The recipient should then check, among other things, their spam folder and custom filters.
Diagnostic example: Contact form to own external mail platform #
A common special case arises when a website is hosted on CURIAWEB, but the email accounts for the same domain are operated via Microsoft 365 or Google Workspace, for example.
For example, the contact form sends to:
info@deine-domain.ch
External senders can reach this address without any problems, but messages from the web server are missing.
In this case, in addition to the shipment tracking, you should in particular Email Routing in cPanel check.
The hosting server needs to know that the email domain is processed externally.
Do not change any settings on a hunch #
A common mistake with email issues is changing MX records, routing, SPF entries, filters, and forwarding all at the same time.
Afterwards, it is barely traceable which change caused or solved the problem.
Practical Tip: First investigate the delivery method and error message, then fix the specific cause. Diagnosis is faster and safer than making multiple changes on guesswork.
When should you contact support? #
If you cannot assign the error yourself, as specific information as possible is helpful for further analysis.
If possible, have the following information ready:
- complete sender address
- complete recipient address
- approximate date and time
- whether it is about sending or receiving
- complete error message or SMTP response
- whether the problem occurs with all or only certain senders or recipients
This information is much more helpful than a general description like „My emails are not working“.
Do not send passwords along #
For the description of a delivery problem, you should never write your email password or cPanel password in a normal support ticket.
For an analysis of the mail route, sender, recipient, time, and error message are much more important.
Safety: Do not share passwords as part of a normal error description. An SMTP error cannot be better diagnosed by sending your mailbox password along with it.
A systematic sequence for troubleshooting #
For delivery issues, the following sequence has proven effective:
- Check sender and recipient carefully.
- Determine approximate shipping time.
- Message in Track delivery search.
- Read status and full detail message.
- Determine whether the issue is local or occurs at an external destination.
- Only after that, check the affected configuration.
- Test again with a unique test message after making a change.
This allows the cause to be narrowed down much more precisely.
Summary #
The function Track delivery can you find in your CURIAWEB cPanel under Email → Track delivery.
For a specific problem, find the relevant recipient address and compare the sender and timestamp with the message in question. Then check the delivery status and, if there are problems, the complete detailed information.
SMTP responses from the 4xx-classes generally indicate temporary errors, while 5xx- Answers generally indicate permanent errors or rejections. However, the complete error text is always decisive for the actual cause.
A successful handover to an external mail server does not automatically mean that the message will appear in the inbox or be read by the recipient. In this case, spam filters and rules on the recipient's side may need to be checked.
Therefore, use the delivery tracking as a primary diagnostic point before making speculative changes to routing, filters, forwarding, or DNS settings.
