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.
First: confirm you're sending through the right SMTP server
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:
Server: smtp.maildoso.com
Port: 587
Encryption: STARTTLS
Username: the full mailbox address
Password: the mailbox password
Your IMAP server is a different host, and it's 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 with 250 OK: queued as ..., but the message never enters our delivery system — so it's never delivered, and no bounce is ever 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:
Mailboxes on the same account can live on different IMAP servers, so the correct IMAP host can differ between your domains. Check each one rather than reusing a single host for all of them — otherwise a message may have been delivered and you're looking for it on the wrong server.
Don't rely on settings you saved weeks ago. Re-export your current connection details from the dashboard (Email Accounts → select your mailboxes → Export selected to CSV) and compare them against what your sending tool actually has.
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.
Mail between your own Maildoso mailboxes is not delivered
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 is not routed to the destination mailbox, and no bounce is generated. This is by design: the infrastructure is built for outbound outreach to external recipients, not for internal mail between mailboxes on the platform.
So a message that is accepted but never arrives when you send it from one of your mailboxes to another of your mailboxes is not a sign that anything is broken. Turning mailbox rotation on or off does not change this.
How to test delivery instead:
Send to an external business mailbox you control — a Google Workspace or Microsoft 365 address on a domain that is not hosted on Maildoso.
Run a placement test in your sequencer (for example Instantly's inbox placement test) and look at the Google and Microsoft rows.
Don't test against personal Gmail/Outlook.com/Yahoo addresses — Maildoso is built for B2B delivery, and results to consumer inboxes aren't representative (see High bounce rates or spam placement when emailing Gmail recipients).
Why this happens
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, not before your message left. Common reasons a message can go quiet after being accepted:
Your SMTP settings point at a host that isn't our submission endpoint, so the message was accepted locally but never entered delivery (see the section above — this is the most common cause when nothing is being delivered).
The recipient's spam or junk filter accepted the message but routed it to a folder you can't see (spam, quarantine, or a corporate mail-security hold).
A corporate mail filter silently discarded the message after accepting it, which some security systems do without ever sending a bounce back.
The recipient address itself has an issue (full mailbox, forwarding rule, or an address that's no longer monitored) that doesn't always trigger a bounce.
The message was sent to an internal test address or a mailbox you don't regularly check, and it's sitting there unread.
The sending mailbox or domain was created very recently and hadn't finished provisioning yet — see below.
If the mailbox or domain was created recently
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 by our system (so your sending tool sees no error) without being fully routed yet, and that kind of hold doesn't generate a bounce. If the affected mailbox or domain is less than a day old, that's the first thing to rule out — wait for provisioning to complete and re-test before assuming it's a spam-filter issue.
If DMARC is already set to reject and DKIM hasn't finished publishing
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 fully finished publishing on our side. During that window, some receiving mail servers accept the message during the SMTP conversation and then silently discard it afterward because DKIM alignment fails — which produces exactly this pattern: no error on send, no bounce back, and the recipient never sees it.
This is most likely if the affected domain or mailbox is brand new (see "If the mailbox or domain was created recently" above) — give it time to finish provisioning first.
If you've waited and it's still happening, or the domain isn't new, contact support with the domain name and we'll check whether DKIM is correctly published and aligned with DMARC on our end. This isn't something you can verify yourself with a third-party DNS checker, since we manage DKIM signing on our own infrastructure rather than publishing a standalone record — see My DKIM or DMARC isn't detected by a third-party checker.
What to check next
Ask the recipient to check their spam, junk, and any quarantine folder, not just their inbox.
Confirm the recipient address is typed correctly and is still active.
If you're sending through a sequencer or a custom sending setup, double-check there isn't a local rule, filter, or throttling setting on that tool holding the message before it even reaches us.
When it's a delay on our side
In a small number of cases, messages sent through Maildoso can sit in an internal delivery queue longer than expected — for example during a backend slowdown. This is much rarer than the causes above and is not the first thing to suspect. In particular, if nothing at all is being delivered from any mailbox, including mailbox-to-mailbox tests, that points to the SMTP-host problem at the top of this article rather than to 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 you've done both and several sends across different recipients and domains are still missing with no bounce, let us know — and mention that you've already verified the SMTP host — so we can check it as a platform issue rather than a one-off.
What we can check for you
For mailboxes sending through Maildoso, we can look up the delivery record for a specific message and confirm whether it was successfully handed off to the recipient's mail server. If our record shows it was accepted on the receiving end, the message was delivered, and the rest of the journey (spam folder placement, internal routing, etc.) happens inside the recipient's own mail system, which we can't see or control from our side. However, this manual lookup process is not scalable for ongoing monitoring, so customers should consider implementing their own monitoring systems for better efficiency. If we have no record of the message at all, that normally means it never reached our delivery system — which again points back to the SMTP settings at the top of this article.
About bounces and delivery logs: Maildoso SMTP does not 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 does not return individual recipient email addresses or hard-bounce failure reasons, and there is no supported API method to retrieve individual hard-bounce records. Customers should rely on SMTP session data (send-time delivery responses) to identify undeliverable recipients and implement a sequencer or suppression list to manage delivery events independently. What we can do is look up a specific message by sending mailbox, recipient, date/time and subject and confirm whether it was handed off to the recipient's server; we can't share the recipient server's exact response.
What to send us
The exact SMTP server, port and encryption your sending tool is configured with.
The sending mailbox address.
The recipient address that didn't receive the message.
The date and approximate time of one example message, and its subject line.
Whether the mailbox or domain involved was created in roughly the last 24 hours.
The recipient's provider (Google Workspace, Microsoft 365, other) — tests to an outside business address are the only meaningful ones, see below.
If you suspect a queue delay rather than a single missed message: roughly how many sends were affected and over what time window.
With one concrete example, we can pull the delivery record for it and let you know exactly what happened on our end.
Still stuck after checking the above? Contact us with the details above and we'll review your specific case.