Short answer: A mail server log records every attempt to deliver a message, with a status for each one. To troubleshoot a missing email, search the log for the recipient address around the time of sending, follow the message through its queue identifier and read the final status: sent, deferred or bounced. The reply from the receiving server usually names the reason, and its code starts with 2, 4 or 5 to show success, a temporary problem or a permanent one.
Why logs are the best starting point
When a customer says that an email never arrived, guessing wastes time. The mail log is the one record that shows what your server actually did. It tells you whether the message left your system, which server it was sent to and what that server answered. Often the answer is already written in plain words, such as “mailbox full”, “blocked by policy” or “sender address rejected”.
The log also separates problems on your side from problems elsewhere. If the message never appears in the log, it never reached your mail system, and the fault lies in the website, the form or the settings of the application. If it appears with a successful status, your server did its job, and the next step is to look at the recipient’s spam folder or filtering. This split saves hours.
Where to find the log
The location depends on the software and on your hosting.
- Postfix on Linux usually writes to a file named
mail.logormaillogin the system log folder. - Exim keeps a main log, often called
mainlog, in its own folder. - Control panels such as cPanel, Plesk or ISPConfig provide a mail log or a message tracking tool in the interface.
- Cloud email services offer an activity or event list that shows each message and its status, with search by recipient.
- Shared hosting may not give access to the raw file, but support can search it for you if you provide the address and the time.
Log files are rotated, which means older lines are compressed or deleted after a few days or weeks. If the problem happened some time ago, ask for the archived files soon, before they disappear.
How to find your message
- Note the details. Write down the recipient address, the approximate time of sending in the server’s time zone and the subject if you have it.
- Search for the recipient address in the log. A simple text search, such as
grepon the command line or the search box of the tracking tool, finds all lines that mention it. - Find the queue identifier. Each message gets a short code in the log lines. All lines with the same code belong to one message.
- Search for that code to see the whole story, from the moment the message was accepted to the final delivery attempt.
- Read the last line. It holds the result.
Be careful with time zones. A server may log in UTC while your clock shows local time. Searching an hour that is off by a few hours is a common reason for finding nothing.
How to read the status
A typical delivery line contains the recipient, the server that received the attempt, the delay and a status word. The three results you will see most often are:
- Sent. The receiving server accepted the message. This means that it took responsibility, not that the message is in the inbox. It may still be filtered to junk.
- Deferred. The server could not deliver yet and will try again. The line shows the reason, such as a timeout, a full mailbox or a temporary refusal.
- Bounced. The delivery failed for good, and the server sends a failure notice to the sender. The line shows the reason from the other side.
Look at the delay value too. A message accepted after a few seconds is normal. One that took hours was probably deferred first, a pattern seen with the delay method described in the article on greylisting.
Understand the reply codes
The receiving server answers with a three-digit code, often followed by a longer enhanced code and a sentence. The first digit tells you how to react. A reply that starts with 2 means success. A reply that starts with 4 means a temporary problem, and your server will try again. A reply that starts with 5 means a permanent failure, and retrying will not help until something changes. The guide to email bounce codes lists the common ones.
Some typical messages and their usual meaning:
- User unknown or no such user. The address does not exist, usually because of a typing mistake or a closed account. Remove it from your list.
- Mailbox full. The recipient has no space. Try later or contact them another way.
- Message rejected as spam or blocked by policy. The receiving server did not like the sender or the content. Check authentication and reputation.
- Sender address rejected, or domain not found. The address in the envelope is invalid or the domain has no working DNS.
- Relay access denied. The server you contacted does not accept the message for that domain, often a sign of a wrong setting.
- Connection timed out. Your server could not reach the other server. The cause may be a network issue or a block on a port, as described in the article on SMTP ports.
Tracing a silent loss
Sometimes the log says sent, and the recipient still says nothing arrived. Work outward in steps. Ask the recipient to check the junk folder and any quarantine of their security gateway. Compare the time of acceptance in your log with the time they expect. Open the headers of a similar message that did arrive and read the authentication results, using the method in the guide to reading email headers. If you send to a company, its filtering service may hold the message, as explained in the article on email security gateways. A forwarding rule on the recipient’s side can also change the outcome, a topic covered in the article on forwarding, SPF, SRS and ARC.
Fix the cause and resend with care
Once you know the reason, fix it before you send again. Repeated attempts after a permanent failure only harm your reputation.
- Correct the address if it was a typing mistake, and remove dead addresses from lists.
- Check authentication. SPF, DKIM and DMARC should pass for the sending service, as described in the overview of SPF, DKIM and DMARC.
- Check blocklists. If the reply names a blocklist, follow the steps in the guide to blocklist checks and removal.
- Review the reverse DNS and the greeting name of your server, which many receivers verify.
- Send a single test message and watch the log until the final status appears.
Keep a short record of each case: the date, the cause and the fix. Patterns show up quickly, for example the same provider rejecting you every Monday after a large mailing.
If you manage mail for a business, set up a routine before problems arise. Keep logs long enough to cover a typical complaint, which is often a week or two, and make sure someone knows where they are and how to search them. Write down the queue identifier and the final status in your support notes when you investigate a case, so that the next person does not need to repeat the search. For web forms and shop notifications, send a test message after every change to the mail settings and read the log line, instead of waiting for a customer to report a problem. A few minutes of checking after each change prevents days of lost messages.
How Site AI Audit helps
Site AI Audit does not read your mail logs, because they live on your mail server. It does check the public records that many receiving servers examine before they accept a message: SPF with its lookup limit, DKIM, your DMARC policy and your MX records. The free check covers up to 50 pages and takes one to two minutes. You can run a free check of your website and see the plans for weekly monitoring and alerts when something changes.
Related reading
- Email Bounce Codes Explained: Hard vs Soft Bounces and Fixes
- How to Read Email Headers to Check SPF, DKIM and DMARC
- Greylisting Explained: Why Some Emails Arrive Late
- How to Test Email Deliverability Before You Hit Send
The bottom line
The mail log is the fastest way to turn “my email did not arrive” into a clear answer. Find the message by address and time, follow its queue identifier, read the final status and the reply code, and fix the cause before you resend. When the log says sent, move your attention to filtering on the other side.
الأسئلة الشائعة
What does deferred mean in a mail log?
It means the delivery failed for now and the server will try again later. The log line gives the reason, such as a timeout or a temporary refusal.
Does status sent mean the email reached the inbox?
No. It means the receiving server accepted the message. The recipient’s filters may still place it in junk or hold it in quarantine.
What is a queue ID?
It is a short code that the mail server gives each message. All log lines with the same code belong to the same message, so you can follow it from start to finish.
Why can I not find my message in the log?
You may be searching in the wrong time zone, in a rotated file or on the wrong server. It may also never have reached your mail system, which points to a fault in the website or application.
What do reply codes starting with 4 and 5 mean?
A code starting with 4 is a temporary problem and the server will retry. A code starting with 5 is permanent, and you should fix the cause before sending again.



