Hostinger Email Settings: Three Products, Three Hosts

Reading time: 12 min · Last verified: August 2026 · SMTPedia editorial team

Most hosting companies sell one mailbox product and publish one settings table for it. Hostinger sells three, and its own help center says so out loud: the article that answers Does Hostinger support POP3, IMAP and SMTP? confirms the protocols are enabled by default on all its servers, then immediately forks the reader into three separate configuration guides, one for Hostinger Email, one for Titan Email, and one for cPanel Email. Those three guides do not carry the same hostnames. That is the single most useful thing to know before you type anything into a mail client, and it is the one thing no summary of the hostinger email settings currently bothers to mention.

If you bought a plan in the last couple of years and manage your mailboxes in hPanel, you are on Hostinger Email and the hosts below are yours. If your mailbox was sold to you as Titan, or you log in through Titan webmail, your outgoing server is not a Hostinger domain at all. If your plan runs cPanel, Hostinger publishes no hostnames in public, on purpose, because they depend on your server.

The Settings Hostinger Publishes for Hostinger Email

These values are transcribed from two Hostinger support articles, How to get email account configuration details for Hostinger Email and Set up Hostinger Email on your applications and devices, and cross-checked against the developer documentation at docs.hostinger.com. The three sources agree on every host and every port, which is not something we can say about every provider in this cluster.

Two details in those tables carry more weight than they look. The first is that POP3 is published with a caveat in Hostinger’s own words: IMAP keeps mail in sync across all devices, while POP3 downloads and typically removes it from the server. Hostinger also notes that a POP3 client no longer empties the mailbox invisibly, since messages stay reachable in webmail until you delete them there. If you are choosing between the two protocols rather than copying a setting someone gave you, the trade is set out in our references on IMAP configuration and on POP3 configuration.

The second is the prerequisite list, which Hostinger states before the table rather than after it: the mailbox has to exist, the domain has to point to Hostinger, and the domain needs correct MX records. That ordering is deliberate. A client that cannot log in because the mailbox was never created looks exactly like a client with the wrong hostinger imap settings, and people spend an afternoon retyping ports over a problem that lives in the domain’s MX records.

Three Products, Three Sets of Hostnames

This is the part that makes Hostinger unusual. The company has resold Titan mailboxes for years, it sells its own Hostinger Email today, and some plans still ship cPanel, whose mail accounts are handled by cPanel itself. A mailbox from each of those three lines takes a different outgoing server, and none of them will accept the other two.

The Titan row is transcribed from Hostinger’s own Titan configuration article, and it matches what Titan publishes directly. Titan is worth understanding on its own terms, because it is resold under a dozen brands and its regional infrastructure changes the hostnames for buyers outside the United States: the full picture, including the variant hosts that European resellers hand out, is in our page on Titan Email settings and its two prerequisites. Hostinger customers are on the standard hosts, so if a settings table gave you a numbered variant of imap.titan.email, it did not come from Hostinger.

The cPanel row is the one we will not fill in, and the reason matters. Hostinger’s cPanel article tells you to open Email Accounts, click Connect Devices, and read the values under Mail Client Manual Settings, adding only the instruction to always use the secure SSL and TLS block. It publishes no hostname and no port, because on a cPanel server the answer is generated for your account. That is the same convention HostGator uses when it makes your server name the mail host, and it is the opposite of the single shared host that DreamHost gives every mailbox it runs. Copying a cPanel value from another customer is how you reach a real server that refuses your password.

Multi product hosting brands are becoming the norm rather than the exception in this cluster. GoDaddy answers the same question two different ways depending on whether you bought Microsoft 365 or its own Workspace mail, and Bluehost sells two email products that share a support section. What is specific to Hostinger is that the three lines are all still live at once, and that the newest one took the plain hostinger.com hostnames, which makes older Titan instructions look wrong rather than obsolete.

What the AI Answer Gets Right, and the Question It Never Asks

We measured the AI Overview served on the query hostinger email settings in the United States this month. Unlike the four provider summaries we checked before it, this one is accurate. It prints the three Hostinger Email hosts, the right ports, the right encryption labels, and it even carries the 587 fallback with the correct condition attached.

The defect is not in any value. It is in the shape of the answer. Hostinger’s own help center refuses to answer this question with one table and sends the reader to pick a product first. The generated summary picks for you, silently, and it picks the newest line. A Titan customer who follows it will enter smtp.hostinger.com against a mailbox that lives on smtp.titan.email, and a cPanel customer will do the same against a server that never had that name. Neither failure is loud. Authentication rejections read like a bad password, which is the misdiagnosis catalogued on our page for 454 4.7.1 relay access denied and, when the server does not recognise the account at all, on 550 5.1.1 user unknown.

Worth noting too: three of the four sources cited under that summary are Hostinger support pages, and the fourth is a third party blog. The blog is where the authentication detail comes from. When a generated answer reaches outside the vendor for a fact the vendor publishes, it is a signal that the vendor’s own page was harder to parse than the copy of it, not that the copy is better.

465 or 587: Hostinger’s Own Pages Lead With Different Ports

Hostinger’s configuration articles are consistent: 465 with SSL is the value in the table, and 587 with TLS or STARTTLS is what you switch to if you hit encryption issues. Its tutorial on email that will not send takes the other stance, describing 587 as the modern default for sending mail securely, 465 as a secure option that encrypts the connection from the start, and 25 as the original port now blocked by most internet providers. Both pages are Hostinger’s. Nothing in either is false, and a reader who lands on the wrong one first will configure the port the other page treats as the fallback.

This is a milder version of the contradiction we measured on another host in the same week, where IONOS published 465 in one place and 587 in another for the same mailbox. The practical guidance for a Hostinger mailbox is simple and does not depend on which page you read: set 465 with SSL first, and move to 587 with STARTTLS only if the connection fails or your network blocks the implicit TLS port. Both are documented, both work, and the distinction between a session encrypted from the first byte and a session upgraded mid conversation is explained in our reference on SMTP, IMAP and POP3 ports and their TLS requirements.

One warning about the middle ground: some clients expose a security dropdown that does not match the port they send on, and the mismatch surfaces as a hang rather than an error. If your client offers SSL, TLS and STARTTLS as three separate choices, the pairing that matters is 465 with SSL and 587 with STARTTLS, never crossed. Our guide to setting up SSL and TLS for email covers the dropdown labels client by client, and a server that demands the upgrade you did not offer answers with 550 must issue a STARTTLS command first.

What Resolves, What Does Not, and the mail.hostinger.com Trap

We resolved every hostname a Hostinger user is likely to type, five times each, plus two invented names as negative controls. The results are a snapshot taken this month from one vantage point, not a promise about tomorrow, and they are reported here because two of them change what you should do.

The first useful result is that incoming and outgoing sit on different addresses. IMAP and POP answer on one, SMTP on another. That is the opposite of DreamHost, where all three published names currently answer on a single address, and it means a firewall rule or a route problem can take out your sending while your mail keeps arriving. If that happens, the symptom is a client that syncs perfectly and refuses to send, which people almost always read as a password problem.

The second is mail.hostinger.com. It resolves, so a client accepts it without complaint, and Hostinger’s own help center mentions it as the place your messages remain readable after a POP3 download. But it answers in a completely different address block from the mail hosts, because it is the webmail front end you log into with a browser. Typed into the incoming server field of a mail client, it is not a mail server, and the failure mode is a timeout rather than a clean rejection.

Because there is no wildcard on the domain, a mistyped host fails at resolution instead of landing on some other machine that asks for a password. That is a small mercy worth knowing: if your client is prompting you for credentials again and again, the host you typed exists, and the problem is somewhere else. Ports were not probed. Outbound mail ports are blocked from the environment these checks ran in, so no handshake is claimed anywhere on this page, and every port above is quoted from Hostinger’s documentation rather than tested.

The Limits Are Two Numbers, and People Only Ever Read One

Hostinger publishes a parameters and limits page for its Business Email plans, and it contains a distinction that catches people out. There is a daily message rate, and separately a total message allowance for the plan. Hitting either one stops your mail.

Note the shape of the daily figures: Standard and Premium share the same 3000 a day, so paying up from Standard buys storage, aliases and total allowance rather than a faster send rate. Trial plans are capped far lower, at 100 messages a day in each direction. Filters and rules are also capped per tier, with the top plan uncapped, though the published table is ambiguous enough about the two lower numbers that we are not printing them here.

The 100 recipient ceiling is the one that turns into a support ticket. It counts every address in the envelope, so one message to a 120 person list is a failure, not a slow send, and splitting the list is the fix. If you are sending to a list at all, Hostinger’s position is explicit: solicited mail is fine, opted in newsletters are fine, and anything larger belongs in a marketing product rather than a mailbox. That is the same boundary we describe on our page about transactional email and where mailbox sending stops, and the reason a business email hosting plan is priced per mailbox rather than per send.

Sizes are published in three separate numbers, which is unusually precise: 50 MB for an inbound message including attachments, 35 MB for an outbound message including attachments, and 25 MB for the attachment itself on the way out. That last pair is the interesting one, because encoding sits between them: a file that measures 25 MB on disk does not weigh 25 MB on the wire once it is encoded, and the arithmetic that catches people is worked through on our page about email attachment size limits. A message that exceeds the ceiling is refused rather than trimmed, and the mailbox on the far side may answer with 452 4.2.2 out of storage space for an unrelated reason, which is worth telling apart before you start deleting files.

App Passwords, Two Factor Authentication, and What Your Client Wants

Hostinger’s documentation states the rule plainly: the username is the full email address, and the password is the mailbox password, or an app password if the mailbox uses two factor authentication or the application does not support your regular login. Two factor authentication is switched on inside webmail itself, per mailbox, and an administrator can turn it off again from the mailbox table. App passwords are created and named individually, shown once, and revocable one by one.

Two practical consequences. First, an app password grants full access to that mailbox, so it is a credential and not a convenience: name them per device so revoking one does not lock out everything. Second, if you enabled two factor authentication and then watched an older client start failing, nothing broke, the client simply cannot complete the second step and needs an app password instead. This is the pattern followed by Infomaniak, which requires an application password for external clients, and it is exactly the feature DreamHost states it does not offer on mailboxes at all, which is why advice written for one host is so often wrong on the next.

The password your client wants is never your hPanel account password. That is the login for the control panel where mailboxes are created; the mailbox has its own password, set when it was created and resettable from the same screen. This is the single most common cause of a hostinger smtp settings failure that looks like a server problem and is not.

The Domain Side: Two MX, One SPF, Three DKIM

Before any client setting matters, the domain has to be pointed at the service. Hostinger documents the shape of the record set for a manual setup: two MX records to receive, one TXT record for SPF to send, three CNAME records for DKIM, and one TXT record for DMARC, which it marks as highly recommended rather than required. The values themselves are shown inside hPanel under the domain’s email settings and are not published in the support article, so read them from your own panel rather than copying them from anywhere, including here.

The three CNAME shape for DKIM is worth registering, because plenty of providers hand out a single TXT record instead and instructions do not transfer between the two models. What each record does, and what breaks when one is missing, is covered on our pages for MX records, SPF records and the DMARC record. If you are assembling the SPF value by hand because you also send from a marketing tool, our free SPF record generator and free DKIM record generator will keep the syntax valid, which matters more than it sounds: a second SPF record on the same domain invalidates both.

Sending from a website on the same hosting account is a separate question from mailbox settings. A WordPress site that uses the default PHP mail path is not authenticated by any of the above, and Hostinger’s own troubleshooting page points at an authenticated SMTP connection as the fix. Point that plugin at smtp.hostinger.com with the mailbox credentials rather than leaving it to the server default, and the rest of our SMTP setup guide applies unchanged.

Entering These Values in a Client

Nothing on Hostinger requires a client specific trick, which is why this section is short. In Outlook, the automatic account setup often finds nothing for a custom domain and hands you the manual IMAP screen, which is where the four values above go. In Apple Mail, choose Other Mail Account rather than a named provider, and expect to correct the outgoing server after the first attempt, since it likes to guess. In the Gmail app on Android or iOS, the path is Other, then a choice between IMAP and POP3, and Hostinger publishes a dedicated guide for it. Any client that asks for a server and a port rather than a provider name will work; the full list of what runs where is in our email clients directory.

If a send fails immediately after setup, read the error before changing anything. A refusal to relay points at authentication that is off or a From address that does not match the mailbox, described on 550 5.7.1 relaying denied. A temporary refusal under load, or a client that opened too many sessions at once, shows up as 421 4.7.0 too many connections or 421 4.2.1 please try again later, and the answer to both is to stop retrying. The full reference is our list of SMTP error codes.

Frequently Asked Questions

What is the SMTP server for Hostinger email?

For Hostinger Email, the hostinger smtp server is smtp.hostinger.com, on port 465 with SSL, or port 587 with TLS or STARTTLS if 465 is blocked or your client objects. Authentication is required and the username is your full email address. If your mailbox is a Titan mailbox sold by Hostinger, the outgoing server is smtp.titan.email instead, and if your plan uses cPanel, the server name comes from the Connect Devices screen in cPanel.

Is Hostinger email POP3 or IMAP?

Both are supported and enabled by default, and Hostinger recommends IMAP. The hostinger pop3 settings are pop.hostinger.com on port 995 with SSL, and the IMAP equivalent is imap.hostinger.com on 993 with SSL. Hostinger’s own documentation flags POP3 as the lesser choice because it downloads mail to one device instead of keeping every device in sync, though messages remain visible in webmail after a POP3 download rather than disappearing from the server.

What are the settings for the Hostinger email server?

The complete hostinger email server settings for Hostinger Email are: incoming imap.hostinger.com port 993 SSL or pop.hostinger.com port 995 SSL, outgoing smtp.hostinger.com port 465 SSL, username your full address, password the mailbox password. Before those values work, the mailbox must exist, the domain must point to Hostinger, and the MX records must be in place.

Should I use port 465 or 587 for Hostinger?

Start with 465 and SSL, which is what Hostinger’s configuration table publishes first. Switch to 587 with TLS or STARTTLS if you hit encryption problems or a network that blocks 465, which Hostinger documents as the supported alternative. Do not pair 465 with STARTTLS or 587 with SSL: the port and the encryption mode go together, and crossing them produces a connection that hangs rather than an error message that tells you why.

Why is my Hostinger email not sending?

Four causes account for most of it. The password entered is the hPanel account password rather than the mailbox password. The mailbox has two factor authentication on and the client needs an app password. The message has more than 100 recipients across To, Cc and Bcc, or the plan’s daily message count is spent. Or the outgoing host belongs to a different Hostinger product than the one your mailbox is on. Incoming and outgoing also answer on different addresses, so mail arriving normally does not prove the sending path is healthy.

Do I need an app password for Hostinger email?

Only if the mailbox has two factor authentication enabled, or if the application cannot handle the normal login. Hostinger states both conditions in its documentation. App passwords are generated per application inside the mailbox, shown a single time, and can be revoked individually, so create one per device rather than reusing a single value everywhere. Each one carries full access to the mailbox.

Can I use mail.hostinger.com as my mail server?

No. It is the webmail address you open in a browser, and Hostinger references it as the place mail stays readable after a POP3 client downloads it. It resolves, so a mail client will accept it without complaint, but it answers in a different address block from the actual mail hosts and it is not published as a client setting. Use imap.hostinger.com, pop.hostinger.com and smtp.hostinger.com.

The Short Version