Sometimes a message looks like it sent successfully — your sending tool shows no error, and the mail server even confirms it accepted the message — but the recipient never sees it, and you never get a bounce or failure notice either. Here's how to work through that.

Check this before anything else, especially if the problem affects every message from every mailbox. There is one SMTP submission endpoint for every Maildoso mailbox on every account:

Your IMAP server is a different host, specific to the mail server your mailbox lives on — it looks like imap.<name>.maildoso.com. That host is for reading mail. It is not an SMTP endpoint. If your SMTP settings point at an imap.*.maildoso.com host, the connection can still succeed and the server can still answer 250 OK: queued as ..., but the message never enters our delivery system — so it's never delivered, and no bounce is generated. That is exactly the no-error, no-delivery, no-bounce pattern this article is about.

Node names you may see in your CSV — for example hector, hemera, harmonia, hestia, heracles, horus, helicon or apollo — are IMAP servers only. Never put imap.<node>.maildoso.com into an SMTP field. Port 587 with STARTTLS is the standard; port 465 with SSL also works on smtp.maildoso.com. Mail sent through any other host also won't appear in your Insights, because Insights only counts mail that went through smtp.maildoso.com.

Two things worth knowing while you check:

If your SMTP setting pointed anywhere other than smtp.maildoso.com, correct it, send one fresh test, and confirm the result before troubleshooting further — the rest of this article assumes SMTP is already correct.

Maildoso does not deliver email from one of your Maildoso mailboxes to another Maildoso mailbox — on the same account or on another Maildoso account. The SMTP server accepts the message, but it isn't routed to the destination mailbox, and no bounce is generated. This is by design: the infrastructure is built for outbound outreach to external recipients. So a mailbox-to-mailbox test that never arrives is not a sign that anything is broken, and turning mailbox rotation on or off doesn't change this.

How to test delivery instead:

Once SMTP is correct, a "no bounce" outcome almost always means the message left successfully and was accepted by the recipient's mail server. From that point, delivery issues usually happen on the receiving side. Common reasons a message goes quiet after being accepted:

A newly created mailbox or domain can take up to 24 hours to finish provisioning after it first shows as set up. Messages sent during that window can be accepted (so your sending tool sees no error) without being fully routed yet, and that kind of hold doesn't generate a bounce. If the mailbox or domain is less than a day old, wait for provisioning to complete and re-test before assuming it's a spam-filter issue.

For a domain that was just connected or provisioned, there can be a brief window where DMARC is already active with a reject policy before DKIM has finished publishing on our side. During that window, some receiving servers accept the message and then silently discard it because DKIM alignment fails — no error on send, no bounce, and the recipient never sees it.

In a small number of cases, messages can sit in an internal delivery queue longer than expected — for example during a backend slowdown. This is much rarer than the causes above. If nothing at all is being delivered from any mailbox, that points to the SMTP-host problem at the top of this article rather than a queue delay — a genuine queue delay clears on its own and the messages do eventually arrive. Before reporting one, confirm your SMTP server is smtp.maildoso.com and re-check the recipient well after the original send time. If several sends across different recipients and domains are still missing with no bounce, let us know — and mention that you've verified the SMTP host.

For mailboxes sending through Maildoso, we can look up the delivery record for a specific message and confirm whether it was handed off to the recipient's mail server. If it was accepted on the receiving end, the message was delivered, and the rest of the journey (spam folder placement, internal routing) happens inside the recipient's own mail system, which we can't see. This manual lookup isn't meant for ongoing monitoring, so consider your own monitoring for that. If we have no record of the message at all, it never reached our delivery system — which again points back to the SMTP settings.

About bounces and delivery logs: Maildoso SMTP doesn't return bounce or DSN (delivery status) messages to the mailbox, and there is no bounce feed in the dashboard, the API or a webhook. Bounce notifications are filtered at the system level and this can't be changed per account. The /v1/user/stats API endpoint doesn't return individual recipient addresses or hard-bounce reasons. Rely on SMTP session data (send-time delivery responses) to identify undeliverable recipients, and use your sequencer or a suppression list to manage delivery events. We can look up a specific message by sending mailbox, recipient, date/time and subject and confirm whether it was handed off; we can't share the recipient server's exact response.

With one concrete example, we can pull the delivery record and tell you exactly what happened on our end. Related: My domain shows "missing MX records" or I'm not getting replies · My CC or BCC recipients didn't receive the email.