10-11-2026, 12:27 PM
A message in Sent confirms client submission, not final delivery. Check the mail service, queue and recipient-specific log entry to find where delivery stopped.
Tested Ubuntu lab: aaPanel Free Edition 8.0.6, Mail Server 7.4.1. Postfix and Dovecot were active, /var/log/mail.log existed, and postqueue -p reported Mail queue is empty. Earlier forwarding tests recorded the original alias and successful local delivery. We did not create a deliberate external rejection for this guide.
1. Record the failing message
Write down the sending account, complete recipient address, send time and timezone, unique subject, and exact client error. Determine whether Send failed immediately or the message appeared in Sent. Use a single controlled test, rather than repeatedly sending the same message.
2. Check service status in aaPanel
Open Mail Server → Other Settings → Common settings and find Service Status. Our screen showed Dovecot, Rspamd and Postfix Running. Postfix handles SMTP transport; Dovecot provides mailbox access and can handle local delivery. A Running label does not establish that every message reached a remote inbox.
The same table contains Stop, Restart, Repair and Config controls. Read the error first. Repeated restarts can interrupt clients without fixing DNS, blocked outbound traffic or recipient rejection.
3. Read the queue on Ubuntu
In an authorized server terminal, run this read-only command:
An empty queue means no mail is currently queued in this Postfix instance. It does not prove that every earlier message was delivered: an earlier message could have bounced, been removed or already left the queue.
When entries exist, identify the queue ID, recipient and displayed delay reason. A deferred message is pending for retry. Preserve the reason before changing anything. Do not empty the entire queue to troubleshoot one message.
4. Follow the matching log entry
For our Ubuntu installation:
The file path was verified in this lab. Other operating systems or logging configurations may use a different location. If a command returns no useful entries, check the logging configuration and time window; do not invent a successful result.
Search for the recipient and queue ID. One message can create several lines. Follow the same ID through submission, delivery attempt and final status. Logs may contain private addresses and message details; remove unrelated information before sharing excerpts publicly.
5. Interpret the delivery result
6. Fix the cause and retest
For DNS errors, verify MX and its target. For connection timeouts, check provider port restrictions and network reachability. For authentication or reputation failures, verify SPF, DKIM, DMARC and PTR. Change one relevant setting at a time and send another unique test.
![[Image: mail-seostack-branded-20261011.png]](https://adminsforum.com/uploads/tutorials/mail-seostack-branded-20261011.png)
External check: our completed SEOStackTools test scored 95/100. It complements logs; it does not report the status of every message.
Continue: Reverse DNS and SEOStackTools delivery testing
Tested Ubuntu lab: aaPanel Free Edition 8.0.6, Mail Server 7.4.1. Postfix and Dovecot were active, /var/log/mail.log existed, and postqueue -p reported Mail queue is empty. Earlier forwarding tests recorded the original alias and successful local delivery. We did not create a deliberate external rejection for this guide.
1. Record the failing message
Write down the sending account, complete recipient address, send time and timezone, unique subject, and exact client error. Determine whether Send failed immediately or the message appeared in Sent. Use a single controlled test, rather than repeatedly sending the same message.
2. Check service status in aaPanel
Open Mail Server → Other Settings → Common settings and find Service Status. Our screen showed Dovecot, Rspamd and Postfix Running. Postfix handles SMTP transport; Dovecot provides mailbox access and can handle local delivery. A Running label does not establish that every message reached a remote inbox.
The same table contains Stop, Restart, Repair and Config controls. Read the error first. Repeated restarts can interrupt clients without fixing DNS, blocked outbound traffic or recipient rejection.
3. Read the queue on Ubuntu
In an authorized server terminal, run this read-only command:
Code:
postqueue -pWhen entries exist, identify the queue ID, recipient and displayed delay reason. A deferred message is pending for retry. Preserve the reason before changing anything. Do not empty the entire queue to troubleshoot one message.
4. Follow the matching log entry
For our Ubuntu installation:
Code:
tail -n 100 /var/log/mail.log
journalctl -u postfix -u dovecot --since '30 minutes ago' --no-pagerSearch for the recipient and queue ID. One message can create several lines. Follow the same ID through submission, delivery attempt and final status. Logs may contain private addresses and message details; remove unrelated information before sharing excerpts publicly.
5. Interpret the delivery result
- status=sent: the selected destination accepted that delivery. For a remote server, read its response; acceptance does not guarantee Inbox placement.
- status=deferred: delivery remains pending. Read the accompanying timeout, DNS or temporary rejection reason.
- status=bounced: permanent failure was reported. Read the remote explanation and any returned delivery-status message.
- Authentication failure: inspect the client username, password and account status before diagnosing remote delivery.
6. Fix the cause and retest
For DNS errors, verify MX and its target. For connection timeouts, check provider port restrictions and network reachability. For authentication or reputation failures, verify SPF, DKIM, DMARC and PTR. Change one relevant setting at a time and send another unique test.
External check: our completed SEOStackTools test scored 95/100. It complements logs; it does not report the status of every message.
Continue: Reverse DNS and SEOStackTools delivery testing