I spent a session deliberately breaking my own Hostinger mailbox to see what real failures actually look like: sending to fake addresses, hitting attachment limits, and digging through Hostinger’s own delivery logs to see how each failure gets recorded.
What came back wasn’t the vague “check your settings” advice most troubleshooting guides give.
Every bounce had a specific, readable reason attached to it, and once you know how to read that reason, most sending problems stop being mysterious.
Start Here: Check Your Email Logs Before Guessing
Before troubleshooting anything blind, go to hPanel and open Emails → Email Logs. This tool exists to answer “what actually happened to this message,” and most people never look at it.
There are three tabs, and they answer different questions:
- Access logs every IMAP, POP3, and SMTP connection to your mailbox, meaning login events from your email client or webmail. Use this to confirm your device is actually connecting and authenticating successfully.
- Delivery logs the messages themselves: sender, recipient, timestamp, and a status of Sent, Delivered, Bounced, or Partially delivered. This is the one you want when a specific message didn’t arrive.
- Actions covers other mailbox events. If Delivery doesn’t explain your issue, check here next.
Click into any Delivery row, and it expands to show the full server response for that message, the same kind of raw SMTP text a mail server actually exchanges behind the scenes.
That response is where the real answer lives, not the summary status next to it. A message marked “Partially delivered,” for instance, tells you almost nothing on its own, but the expanded result line underneath it will tell you exactly which recipient failed and why.
“Host Not Found”: You’re Sending to a Domain That Doesn’t Exist
This is the cleanest, most unambiguous failure there is, and it’s worth knowing what it looks like so you can rule it out fast.
I sent a test message to a deliberately fake domain and got this back within minutes:
Host or domain name not found. Name service error for name=[domain] type=A: Host not found
This means the domain in the recipient’s address has no DNS record at all, full stop. It’s not a Hostinger problem, not a spam filter, and not a typo you can fix by resending.
If you see this exact wording, double-check the domain portion of the address for a typo, since a single dropped letter (.con instead of .com, for example) produces exactly this error.
“The Email Account You Tried to Reach Does Not Exist”: Invalid Mailbox
This is a different failure from the one above, and the wording makes that clear once you know what to look for. I sent a test to a real, working domain but a mailbox that doesn’t exist on it, and got this back:
550-5.1.1 The email account that you tried to reach does not exist. Please try 550-5.1.1 double-checking the recipient’s email address for typos
That specific “550-5.1.1” formatting is Google’s bounce style, since the test address happened to be on Gmail’s infrastructure. According to Hostinger’s own support team, a missing mailbox on a Hostinger-hosted domain won’t necessarily produce identical wording, since the exact bounce text depends on whatever mail system is actually handling that domain.
The underlying meaning is the same either way: the mailbox portion of the address, not the domain, is what’s wrong.
If a colleague tells you your email “bounced,” ask them to forward you the actual bounce text rather than just the word “bounced,” since 550-5.1.1-style errors and the domain-not-found error above require completely different fixes.
Message Blocked by the Recipient’s Spam Filter
This is the failure most people misdiagnose, and it’s worth explaining carefully because I hit it twice while testing, on two separate messages sent a day apart.
Both times, a message sent successfully to my own Hostinger mailbox but came back blocked when a copy went to a personal Gmail address:
host smtp.mailchannels.net[35.166.226.169] said: 550 5.7.1 [CS] Message blocked. If this is a false positive, please report this to your hosting service provider.
The “[CS]” tag stands for content spam, and this is the critical detail. This bounce fires because the receiving mail server (Gmail, in this case) decided the message content looked suspicious, not because Hostinger failed to send it.
Look closely at the wording: “please report this to your hosting service provider” is Gmail’s suggestion, addressed to Hostinger as the sending infrastructure, not an admission that Hostinger did anything wrong. Your message left Hostinger’s servers successfully. It was rejected on arrival.
This matters because the instinct when you see the word “blocked” is to assume your own email provider is broken. In this case, the fix isn’t on Hostinger’s side at all. It’s about what triggered the content filter: repeated identical test messages, spam-trigger phrasing, suspicious links, or a sending pattern that looks automated rather than human.
If you’re seeing this consistently on real campaigns rather than test messages, that’s a deliverability problem worth fixing at the source with proper SPF, DKIM, and DMARC configuration, not a Hostinger outage.
Attachment Too Large to Send
I attached an oversized file in Webmail and got an immediate, pre-send rejection rather than a bounce after the fact:
Attachments can’t exceed 35 MB limit.
That’s the exact wording the interface shows, and it’s worth flagging a genuine inconsistency here rather than papering over it.
The webmail error message references the 35MB figure, which is the total-message cap, not the narrower 25MB attachment cap it’s actually enforcing in that moment. In practice, treat 25MB as your real ceiling for a single attachment, since that’s the tighter of the two limits and the one most likely to reject your file first.
This limit isn’t unique to webmail either; Outlook, Thunderbird, and any other IMAP or SMTP client draw from the same mailbox-level sending limits, so switching clients won’t get you around it.
If you regularly need to send larger files, the practical fix is a file-sharing link (Google Drive, Dropbox, WeTransfer) rather than a direct attachment, since no email provider is built to move very large files reliably as attachments.
How to Fix Sending and Receiving Issues
Hitting Your Daily Sending Limit
Hostinger caps outbound sending per mailbox on a rolling 24-hour basis, and hitting that cap causes mail to queue or fail rather than send immediately. The limits differ by plan:
| Plan | Daily sending limit |
|---|---|
| Free Business Email | 100 messages/day |
| Business Starter | 1,000 messages/day |
| Business Premium | 3,000 messages/day |
If you’re sending in bulk, running a newsletter through a regular mailbox instead of a dedicated tool, or troubleshooting why messages seem to stall rather than bounce outright, check whether you’re approaching this ceiling before assuming something is broken.
A mailbox that suddenly stops sending after a burst of activity, with no bounce message at all, is a strong sign you’ve hit this limit rather than hit an error.
Sign-In or Authentication Failures in Your Email Client
If your email client rejects your login outright rather than a specific message bouncing, the cause is almost always credential-related rather than a server or network problem.
According to Hostinger’s support team, the most common causes, in order of likelihood, are:
- An old saved password that no longer matches your current mailbox password
- Using just the username portion instead of your full email address as the login (Hostinger mailboxes require the complete address, not a shortened username)
- The mailbox password having been changed recently without updating it in your client
Less common, but worth ruling out if credentials check out: SMTP sending being disabled on the mailbox, the mailbox itself being suspended, or account-level security settings locking access.
A blocked port usually causes a connection timeout rather than an authentication rejection, so if your client can connect but rejects the login, that points toward credentials rather than a network block.
If you’ve recently changed your mailbox password anywhere, that’s the first thing to re-enter in your client’s account settings, especially the outgoing (SMTP) password field, which some clients store separately from the incoming password field and don’t always update together.
When the Problem Isn’t on Your End at All
- Domain-not-found errors mean the recipient’s address is wrong, not your setup.
- Content-block bounces mean the recipient’s spam filter made a judgment call about your specific message, not your account’s standing.
Neither of those is a Hostinger outage, and neither is something a password reset or settings change will fix.
The Email Logs tool is your fastest way to tell the difference between “something’s wrong with my account” and “something’s wrong with this specific message or its recipient.”
Before assuming the worst, check whether the failure is consistent across many recipients (a sign of an actual account or configuration issue) or isolated to one address (almost always a recipient-side or address-specific problem).
For the deeper technical setup behind all of this, including SPF, DKIM, and DMARC configuration that affects how often your outbound mail gets flagged in the first place, I’ve covered that in detail in my Hostinger Email review.
Most “Hostinger Email not sending” problems have a specific, readable reason attached to them in Email Logs, whether that’s a DNS error, a full mailbox, an oversized attachment, a daily limit, or a recipient’s spam filter making its own call.
Check the Delivery tab before assuming your account is broken, since more often than not, the real explanation is sitting there in plain text.
