Hostinger SMTP

Server settings

Hostinger publishes smtp.hostinger.com as the outgoing host, with SSL encryption on port 465. The incoming services use separate hostnames on their own ports, imap.hostinger.com on 993 and pop.hostinger.com on 995.

Port 587 with TLS or STARTTLS is the documented alternative. Hostinger frames it as the setting to use if SSL encryption causes problems rather than as an equally recommended default.

The username is the full email address including the domain. The password is the mailbox password, so no application-specific credential is required, which distinguishes Hostinger from Google and Yahoo.

Prerequisites before the settings work

An email account must exist before a client can authenticate to it. Hostinger lists this first, because a correct hostname and port still fail where no mailbox has been created.

The domain must point at Hostinger's servers. A domain resolving elsewhere is served by another provider's mail infrastructure, and the credential will not authenticate against it.

The MX records must be correct. Those govern where mail for the domain is received rather than how it is sent, so a client that sends successfully but receives nothing is usually an MX problem rather than an SMTP one.

Missing records are the single most common cause of mail going out from the wrong address, and it is quieter than it sounds. Nick found thirteen accounts in one pass that were not sending from the address their owners intended, purely because records were absent. Nobody had reported a fault. The mail was sending, it was simply sending as something other than what the owner believed.

That is the argument for verifying rather than assuming. A hosting control panel showing a mailbox as active tells you the mailbox exists; it does not tell you that the domain is authorised to send, and those two facts are routinely confused.

Finding the details in hPanel

The configuration values are shown in the account rather than needing to be guessed. In hPanel the Emails section lists each domain, and the manage view exposes the connection details for that mailbox.

The connect apps and devices view carries the manual configuration data for a specific mailbox. Reading them from there rather than from a third-party article removes the chance of applying settings that belong to another provider.

Reset the mailbox password from the same panel if it is lost. The mailbox password is the SMTP credential, so resetting it changes what every configured client must present.

What the settings do not cover

Authenticating to the submission server is not the same as being authorised for the domain. SPF, DKIM and DMARC are DNS records evaluated by the receiving server, and no client setting substitutes for publishing them.

This layer is checkable rather than guessable. We built deliverability checks into Nitrosend that read a domain's SPF, DKIM and DMARC configuration and report bounce rates back, which is exactly the half of sending that a client settings page cannot see.

Shared hosting mailboxes are provisioned for a person rather than an application. Hostinger's setup article does not publish a sending rate for third-party SMTP submission, so any specific figure quoted elsewhere is unverified.

The protocol confirms acceptance rather than delivery. A message the submission server accepts can still bounce or be filtered afterwards, and neither outcome is reported back to the client that sent it.

Application mail on a hosting mailbox

An application authenticating as a mailbox inherits that mailbox's lifecycle. A password reset, a suspension or a staff departure stops the application, because the credential and the person are the same object.

There is no per-message status to query. Diagnosing one undelivered message means asking the recipient, since the mailbox exposes no record of what happened after the server accepted it.

Reputation on shared hosting is shared. Mail leaves infrastructure used by many tenants, so a sender neither accumulates their own sending history nor can repair damage another tenant caused.

Shared reputation is also why our own forwarding relay is locked down the way a hosting mailbox never is. On our relay, TCP 2525 is firewall-restricted to our API host, TLS and exact SMTP authentication are mandatory, and every one-recipient route and MX snapshot is HMAC-signed. Arbitrary destinations, extra recipients, unsigned or replayed requests and multiple forwarding hops are all rejected.

Setting up sending properly used to be the slow part, and George's account of doing it the old way is worth keeping in mind before hand-rolling this: porting email to an existing tool took hours of setup, then weeks of warming and optimisation, and ran to a three-month project overall. The DNS and MX work is the part people underestimate, because each individual record is trivial and the sequence is not.

The modern shortcut is automatic provisioning of the DKIM, MX and verification records rather than typing them by hand, which is what we built for own-domain sending. Whichever route you take, the destination is the same: a domain you control, authorised to send, with the records actually present rather than assumed.

Go deeper