Hostinger SMTP Settings: Ports, Login and Fixes

Do not index

For Hostinger Email, the outgoing server is smtp.hostinger.com on port 465 with SSL/TLS, with port 587 with TLS or STARTTLS as the alternative, and the username is the full mailbox address. Incoming mail uses imap.hostinger.com on port 993, which is separate from sending.

Changing only the port often breaks a working password. That's counterintuitive until the port and encryption mode are treated as one pair. The correct host with the wrong pairing can fail before authentication even starts, so the error looks like a login problem when the login was never reached.

Table of Contents

What Are the Hostinger SMTP Settings?Settings to copy Port 465 or 587: Which Pair Should You Use?How to Configure Hostinger SMTP in an Email Client Configuration steps How to verify it Using Hostinger SMTP in WordPress and Other Apps When WordPress says sent but nothing arrives Hostinger DNS Records That Affect Sending How Do I Verify My Hostinger SMTP Connection?Step 1. Test SMTP sending Step 2. Test IMAP receiving Step 3. Test SPF for the sending domain Why Does My Hostinger Connection Still Fail?Which Common Mistakes Break Hostinger SMTP?Hostinger SMTP Questions Answered Can port 587 be used instead of port 465?Why does login fail with the correct password?Are IMAP settings needed to send email?Does Hostinger support port 2525?Why does the test pass but my app still fails?

What Are the Hostinger SMTP Settings?

Hostinger Email sends through smtp.hostinger.com. The Hostinger email setup documentation pairs port 465 with SSL/TLS and lists port 587 with TLS or STARTTLS for clients that need that method. Sign-in uses the complete mailbox address and the mailbox password for that address.

One check comes first. Open the mailbox details panel in the Hostinger control panel and confirm which service hosts the mailbox before copying anything. A Hostinger Email mailbox lists smtp.hostinger.com as its outgoing server. A mailbox hosted by another provider on the same domain, including Titan mailboxes sold through Hostinger, uses that provider's server instead.

Settings to copy

Setting	Value	Notes
Outgoing server (SMTP) host	smtp.hostinger.com	Use for sending only
SMTP port with SSL/TLS	465	Implicit TLS, encrypted from the first byte of the connection
SMTP port with TLS or STARTTLS	587	Plain greeting, then upgrade to encryption; use when 465 fails
Incoming server (IMAP) host	imap.hostinger.com	Handles receiving and folder sync
IMAP port with SSL	993	Use with SSL for incoming mail
Username	Full mailbox address, such as you@example.com	Enter the complete address including the @ sign
Password	Mailbox password	Hostinger authenticates with the mailbox password for that address

Keep each port with its matching encryption mode when copying the rows into a client. The two fields travel as a pair.

Sending values alone do not authenticate the domain. The Hostinger manual domain setup guide covers the MX, SPF, DKIM, and DMARC records a domain needs, notes that DKIM may be added automatically, and warns that DNS propagation can take up to 24 hours.

Once the values are entered, the free mailX SMTP test connects to the server and reports whether the connection, encryption, and authentication all succeed for a mailbox you control. The mailbox password is used only to run the test and is redacted before the request is saved.

Port 465 or 587: Which Pair Should You Use?

Start with 465 and SSL/TLS. If the client reports an encryption or handshake error on that pair, change both fields to 587 and TLS or STARTTLS. Port and encryption work as a single setting: the port tells the server how the session begins, and the encryption setting tells the client to begin it the same way.

Port 465 encrypts the session immediately, so the client sends no plain SMTP greeting first. Port 587 opens with a plain greeting, sends EHLO, negotiates STARTTLS, validates the certificate, and authenticates only after TLS is active. Each wrong combination produces its own symptom. SSL with 587 makes the client's TLS handshake collide with a server that still expects a plain greeting. STARTTLS with 465 leaves the client waiting for a plain greeting that never arrives, because that port is already encrypted. Both mismatches fail before the password is even checked, which is why a correct login can still produce a connection error.

Hostinger lists the two ports in different places, which reads like conflicting advice. The Hostinger SMTP port tutorial states that Hostinger uses ports 465 and 587 for SMTP submission, stopped supporting port 2525 in 2017, and identifies 587 as the modern default and fallback for encryption issues. The account-configuration reference lists 465 as the normal SSL setting. The practical reading: open with 465 and SSL/TLS, and treat 587 with STARTTLS as the documented fallback.

Setting	Port 465	Port 587
Encryption mode	Implicit SSL/TLS	TLS through STARTTLS
How the session starts	Encrypted from the first byte	Plain SMTP greeting, then EHLO and STARTTLS upgrade
Client setting to select	SSL/TLS	TLS or STARTTLS
Where Hostinger lists it	Account-configuration reference as the normal SSL setting	SMTP transmission documentation as the modern default and fallback
When to use	Start here when the client supports implicit TLS	Switch here when 465 gives encryption or compatibility errors

Readers who want to check a configured pair can verify SMTP connectivity with mailX before trusting it in production. A client hard-coded to 2525 needs reconfiguration to a supported pair, because no password correction can fix an unsupported port.

How to Configure Hostinger SMTP in an Email Client

The finished result is simple. The mail client sends through Hostinger, receives a connected status, and delivers a test message to an inbox under the reader's control. Each step below changes one thing, which makes later errors easier to trace.

Configuration steps

Open mailbox details: Open the mailbox configuration details in the Hostinger control panel and copy the username as the full mailbox address, because the login matches the mailbox, not a short name. Exact menu labels can change, so current Hostinger documentation should confirm screen names.

Choose manual setup: In the app, choose custom or manual outgoing server setup, because automatic discovery may guess the wrong encryption mode.

Enter the host: Enter smtp.hostinger.com as the outgoing server, because that host handles submission rather than folder sync.

Set the first pair: Set port 465 and select SSL/TLS, because implicit TLS must match the port from the first byte.

Enter credentials: Enter the full mailbox address and the mailbox password, because Hostinger authentication checks that specific mailbox.

Match the sender: Set the sender address to the same mailbox address, because a mismatched From address can trigger rejection or suspicion.

Save and test: Save the settings, then send a test message to an address under the reader's control, because arrival confirms the saved values were accepted.

Change the pair if needed: After a TLS or handshake error, change to port 587 with TLS or STARTTLS, save again, and resend the test, because a retest confirms the new pair took effect.

A common stumble happens at step 5. Entering only the part before the @ sign looks tidy, but the server expects the complete address. Another stumble happens when the incoming IMAP host gets pasted into the outgoing field during manual setup. Receiving then works while sending fails.

How to verify it

Run the mailX SMTP test with smtp.hostinger.com, the chosen port and encryption pair, the full mailbox address, and the mailbox password. Then send a message to an address under the reader's control and confirm arrival.

A good result means connection, encryption, and authentication all succeed. A TLS error points back to the port and encryption pair. An authentication error points to the username or password, assuming the handshake completed first.

Using Hostinger SMTP in WordPress and Other Apps

A WordPress contact form can flash "Message sent" while nothing reaches the inbox. The gap usually sits in the outgoing setup, which relies on the same five fields from the email client steps, just dressed in different labels.

An SMTP mail plugin collects those values on one screen. Look for an option labeled other, custom, or manual SMTP, then map each Hostinger value to the plugin's field names. Two fields cause most of the confusion. The From Email field should hold the Hostinger mailbox address, because sending from an address the account doesn't own invites rejection. The password field takes the Hostinger mailbox password; a WordPress admin login or a hosting account login belongs to a different system and fails authentication.

Mobile apps and desktop clients reuse the same outgoing fields. Incoming IMAP settings stay on a separate track that handles receiving and folder sync, so a phone that pulls in mail confirms nothing about whether WordPress can send.

Once the plugin's test email arrives, contact forms, order receipts, and password resets all ride the same configuration.

When WordPress says sent but nothing arrives

Start with the plugin's own test screen or mail log, since a password-reset email that never arrives tells you little while the log entry names the stage that broke. A TLS or handshake error means the port and encryption pair mismatched: the server expected one mode and received the other. Switch both together, for example to port 587 with STARTTLS, instead of flipping fields at random. An authentication error narrows the fault to the username or password.

When the plugin log stays vague, the mailX SMTP test reports whether connection, encryption, and authentication succeed for the mailbox, and it can send a test email to an address you control. The password is used only to run the test. That result shows which field deserves attention before anything else gets changed.

Hostinger DNS Records That Affect Sending

SMTP gets a message out the door. DNS records help receiving systems decide whether that message should be trusted. Four record types matter most for a Hostinger Email domain, and each one fails in a recognizable way when its value is wrong.

SPF authorizes sending servers. The Hostinger SPF support article lists a TXT record at the root host @ with the value v=spf1 include:_spf.mail.hostinger.com ~all and a TTL of 300 seconds or the DNS provider's default. For a subdomain, the host field changes from @ to that subdomain's label.

Only one SPF record should apply to a host. Other legitimate senders belong inside that same record, merged carefully, never in a second TXT record starting with v=spf1. Type a duplicate SPF record into the DNS panel and it saves without a warning, but a receiver then finds two policies on the same host and the SPF check fails instead of combining them.

MX records route incoming mail to the right servers. Copy the exact server names and priorities from Hostinger's setup screen, because those values can change and a guessed entry routes mail nowhere.

DKIM publishes a public key at a selector host so receivers can verify a cryptographic signature. The selector and the key both come from Hostinger's screens. A wrong selector returns no key at all, even when a valid key exists under a different selector, so the signature check fails on an empty lookup.

DMARC starts as a monitoring policy for many domains. A TXT record at _dmarc with v=DMARC1; p=none collects reports before enforcement gets tightened.

Record	Host	Value	Notes
SPF (TXT)	@	v=spf1 include:_spf.mail.hostinger.com ~all	TTL 300 seconds or provider default; merge other senders into this record, never duplicate it
MX	@	Enter the mail servers shown in Hostinger's setup screen	Each priority number must match its server name exactly
DKIM (TXT)	Selector host shown in Hostinger's screen	Paste the public key exactly as shown	The selector name is part of the record; status can take time to update
DMARC (TXT)	_dmarc	v=DMARC1; p=none	Monitoring policy; tighten after reviewing reports

Each record maps to a check. MX lookup confirms routing, TXT lookup shows the published strings, the DKIM checker tests the selector, and the DMARC checker reads the policy. To validate your SPF record, run the domain through mailX after DNS changes have propagated. Confirm every record is present and matching before a failed send gets blamed on the SMTP configuration.

How Do I Verify My Hostinger SMTP Connection?

Verification belongs after configuration and before launch. Three checks separate connection problems from receiving problems and domain authentication problems.

Step 1. Test SMTP sending

Run the check to verify SMTP login and TLS using smtp.hostinger.com, the chosen port and encryption pair, the full mailbox address, and a mailbox under the reader's control. A good result shows connection, encryption, and authentication succeeding. A test message should then arrive at an address under the reader's control.

Bad results route to different fixes. A connection failure points to the network or port. A TLS failure points to the pair. An authentication failure points to the username or password.

Step 2. Test IMAP receiving

Run an IMAP check against imap.hostinger.com on port 993. A good result means login and folder access succeed. A login failure points to mailbox credentials, while successful receiving with failed sending suggests the IMAP host was entered as the outgoing server somewhere.

The password handling is narrow. mailX asks for the mailbox password to run SMTP and IMAP connection tests on the website, API, and MCP server. The password is used only to run the test and is redacted before the request is saved.

Step 3. Test SPF for the sending domain

Run the SPF checker on the sending domain. A good result is one SPF record that includes Hostinger's include mechanism and ends with a single all mechanism. Two SPF records or a missing include points to DNS editing. A lookup count above 10 points to too many included services or chained includes.

Each bad result has a matching repair path. Connection and TLS failures start with network and pairing checks. Authentication failures start with credentials. SPF failures start in DNS, not in the mail app.

Why Does My Hostinger Connection Still Fail?

The symptom usually names the layer that failed. Read that layer correctly and you fix the cause instead of changing random fields.

The Hostinger email configuration support article separates explicit TLS on port 587 via STARTTLS from implicit TLS on port 465, recommends 587 with TLS or STARTTLS when 465 produces encryption errors, states that port 2525 is not supported, and notes that support for TLS 1.0 and 1.1 has ended. Each symptom class points somewhere different: timeouts to filtering, handshake errors to pairing or old TLS, authentication failures to credentials.

Symptom	Likely cause	Fix
Connection timeout	Firewall, DNS or egress filtering blocks the port	Test from another network, then rerun the mailX SMTP test
TLS handshake or encryption error	SSL chosen with port 587, STARTTLS with port 465, or an outdated client TLS version	Pair 465 with SSL/TLS or 587 with TLS/STARTTLS, and update the client
Authentication failed	Username is not the full address, or the password is wrong	Use the full mailbox address and the mailbox password
Sending fails on port 2525	Port 2525 is no longer supported by Hostinger	Change the port to 465 or 587
Receiving works but sending fails	The IMAP host imap.hostinger.com was entered as the outgoing server	Set smtp.hostinger.com as the outgoing server

Work through the table top to bottom. A timeout blocks every step after it, so network access comes first. Encryption pairing comes second, because a client that cannot complete the handshake never reaches the login step. Credentials come last.

Timing matters during repair. Changing a port pair or username takes effect as soon as the client saves it. DNS changes take time to propagate, so repeated SMTP edits will not speed up a DNS wait.

One distinction helps with stubborn login failures. An authentication error that appears after the encryption layer succeeds points to the username or password, and readers sorting that class of error can troubleshoot SMTP login errors with that sequence in mind. Change one field at a time and rerun the mailX SMTP test after each change. A failure that moves to a different layer means the last fix worked and a new problem surfaced; a failure that stays put means the cause sits elsewhere in the table.

Which Common Mistakes Break Hostinger SMTP?

A correct password does not validate the rest of the setup. DNS records, DKIM selectors, record types, and login details can each break sending while the password stays perfectly valid, so a successful authentication only clears one layer of the configuration.

Duplicate SPF records: Two TXT records begin with v=spf1 on the same host, so receivers cannot apply one clear policy. The SPF checker detects the duplicate.

More than 10 DNS lookups: Included services push SPF evaluation past the 10-lookup limit, causing SPF to fail. The SPF checker shows the lookup count.

Wrong DKIM selector: The public key sits at a different selector host than the selector used for signing, so no key is found. The DKIM checker should query the exact selector shown in Hostinger's screens.

CNAME instead of TXT: A CNAME record exists where a TXT record is required. CNAME lookup and TXT lookup together reveal the record type mismatch.

Mismatched port and encryption pair: The valid pairings from section 2 are 465 with SSL/TLS and 587 with TLS or STARTTLS; any other combination fails at the handshake before credentials are tested.

Wrong password used: SMTP login takes the mailbox password, the same credential that opens the inbox, rather than the hosting account password or an older saved one.

A pre-launch checklist keeps the fix order sane. Confirm one SPF record, all real senders included, DKIM found at the right selector, the correct port pair, a full-address username, and a passed SMTP test. The connection error table above covers symptom-specific repairs; this list catches configuration defects before launch day.

Hostinger SMTP Questions Answered

Can port 587 be used instead of port 465?

Yes. Port 587 works when TLS or STARTTLS is selected with it, and it is the fallback Hostinger recommends when port 465 produces encryption or compatibility errors. Change the pair rather than the number alone: SSL on 587 can fail during the handshake before authentication begins.

Why does login fail with the correct password?

The username may be incomplete. Hostinger authentication expects the full mailbox address plus that mailbox's own password. A short username, a hosting account password, or an old saved password can all look like a server failure, so credentials should be corrected before the port gets changed.

Are IMAP settings needed to send email?

No. IMAP on port 993 handles receiving and folder synchronization, while SMTP through smtp.hostinger.com handles sending. A WordPress plugin or sending app works without IMAP settings; a mail client that also reads the inbox needs both.

Does Hostinger support port 2525?

No. Hostinger states that support for port 2525 ended in 2017. Any client still configured for it should move to 465 with SSL/TLS or 587 with TLS or STARTTLS.

Why does the test pass but my app still fails?

A passed SMTP test confirms the host, port pair, and credentials worked at that moment. The app can still fail if it overrides the entered port with a default, kept an old saved configuration, or received the password with extra characters during a paste. Entering the exact pair that passed and restarting the app forces it to reload the settings.

Run the relevant check before launch through mailX. The free web tools explain SMTP, IMAP, SPF, DKIM, and DMARC failures in plain English with concrete fixes, with no signup. SMTP and IMAP connection tests run on the web tools, the REST API, and the MCP server for Claude or Cursor, using credentials the user provides for a mailbox they control, and those credentials are not stored. The app inside ChatGPT covers the record checks, such as SPF, DKIM, and DMARC lookups. A mailbox under the reader's control and the exact Hostinger pair entered in the client are enough to start.