
I set up a mailbox on a live Hostinger email hosting account and worked through every configuration path it offers. I’ll walk you through it in the same order I’d actually recommend doing it:
- First, grab your server settings
- Then connect a client using them, then look at whether autodiscover can save you the manual work next time
- And finally, make sure the DNS records behind the scenes are set up correctly so your mail actually gets delivered and trusted.
But before any of this works, you need a mailbox already created under your domain. If you haven’t done that yet, here’s the quick version:
- Go to Emails > Mailboxes in hPanel

- Click Create mailbox

- Enter the address you want (the part before @yourdomain.com) and set a password

- Click Create
Once that mailbox exists, come back here and start with Step 1 below.
Step 1: Get Your Manual Server Settings (IMAP, SMTP, POP3)
Every setup path in this guide eventually depends on three values: your IMAP hostname, your SMTP hostname, and the ports and encryption each one needs.
You’ll find these in hPanel under Emails > Mailboxes > Connect apps & devices > Advanced settings > Server settings.

| Protocol | Hostname | Port | Encryption |
|---|---|---|---|
| IMAP (incoming) | imap.hostinger.com | 993 | SSL/TLS |
| SMTP (outgoing) | smtp.hostinger.com | 465 | SSL/TLS |
| POP3 (incoming) | pop.hostinger.com | 995 | SSL/TLS |
Before you copy these down, it helps to know what each protocol actually does, since that decides which one you should use.
IMAP keeps a live copy of your mail on Hostinger’s servers and syncs read status, folders, and new messages across every device you check email from. If you read an email on your phone, it shows as read on your laptop too.
POP3 works differently. It downloads messages to a single device and, depending on how it’s configured, can remove them from the server afterward. That’s why Hostinger flags POP3 as “Not recommended” on its own settings screen. It’s not that POP3 is broken; it’s that it was built for a time when people only checked one device, and that assumption breaks down fast if you use a phone and a computer for the same inbox. I’d only reach for POP3 if you have a specific reason, like an old application that doesn’t support IMAP.
The encryption setting matters just as much as the hostname. All three protocols here require SSL/TLS on the exact ports listed.
If a client defaults to an unencrypted connection or a different port, like the older port 143 for IMAP or 587 for SMTP, the connection will either fail outright or silently downgrade to something less secure. Confirm the encryption dropdown is set correctly at the same time you enter the hostname, not as an afterthought.
With these three values copied down, you’re ready to actually connect an email app. That’s Step 2.
Step 2: Connect Your Email App Using Those Settings
Hostinger builds guided setup steps for Gmail, Outlook, and Apple Mail, plus a generic path for anything else. I tested all four, and there’s a pattern worth knowing before you start: every guided flow Hostinger provides is written for mobile apps, not desktop clients.
If you’re setting up Outlook on Windows or Thunderbird on a laptop, you’ll use the manual settings from Step 1 directly, since hPanel doesn’t currently walk through desktop setup screens.
Pick whichever of these four matches what you’re setting up.
Connecting Gmail
- Open the Gmail app and tap your profile photo
- Tap Add another account, then choose Other (IMAP)
- Enter your mailbox address, then the password and IMAP settings from Step 1
- Enter the SMTP settings for outgoing mail

Gmail’s flow uses the same IMAP and SMTP values from Step 1, just entered through Gmail’s own account wizard instead of a generic settings screen.
Connecting Outlook
- Open the Outlook app and tap your profile photo
- Go to Accounts > Add account > Email account > IMAP
- Enter your mailbox address, password, and IMAP settings
- Enter the SMTP settings for outgoing mail

This is nearly identical to the Gmail flow. The one difference worth flagging is that Outlook asks for your IMAP password and incoming server settings as one step, then asks for outgoing SMTP settings as a separate step afterward, so don’t assume you’re finished once mail starts loading. Sending won’t work until you’ve also entered the SMTP details.
Connecting Apple Mail
Apple Mail breaks from the pattern the other two follow. Instead of typing settings into fields, Hostinger generates a configuration profile that installs directly onto the device.
- Scan the QR code, or copy the profile link and open it in Safari
- Open Settings on the device and find the downloaded profile
- Tap the profile and select Install
- Enter the mailbox password one more time when prompted

This is a meaningfully faster setup if you’re on an iPhone or iPad, since it skips manual entry of hostnames and ports entirely.
The tradeoff is that it only works through Safari on the device itself. You can’t generate the profile on a desktop browser and transfer it over, since the QR code and download link are tied to that specific setup session.
Connecting Any Other IMAP Client
For anything outside these three, the “Other” tab in hPanel gives generic steps without app-specific menus:
- Choose IMAP as the account type, not POP3
- Enter the mailbox address and password
- Enter the IMAP settings for incoming mail
- Enter the SMTP settings for outgoing mail

This is really just Step 1’s manual configuration, presented as a checklist. If you’re setting up a desktop client like Thunderbird, this is the path you’ll actually follow, even though Hostinger doesn’t have a dedicated Thunderbird flow.
Once one device is connected and mail is flowing both ways, you’re done with the core setup. The next two steps are optional but worth doing, since they cover setting up future devices faster and making sure your mail is actually trusted by the people you send it to.
Step 3: Skip Manual Entry Next Time With Automatic Setup
If Steps 1 and 2 felt like a lot of copying and pasting, there’s a way to skip most of it for future devices.
Under the same Connect apps & devices page, a section called Automatic setup lets you toggle on “Enable automatic email app setup,” which adds two CNAME records to your domain’s DNS:
| Type | Host | Points To | TTL |
|---|---|---|---|
| CNAME | autodiscover | autodiscover.mail.hostinger.com | 300 |
| CNAME | autoconfig | autoconfig.mail.hostinger.com | 300 |

These records let compatible clients detect your mail server settings on their own, without you entering a hostname or port anywhere.
Outlook’s desktop app is the most common client that actually uses this, since it checks for an autodiscover record before asking you to configure anything manually. Most mobile setups, including the Gmail and Outlook flows in Step 2, don’t rely on this and ask for the values directly regardless.
I’d still keep the Step 1 settings handy even with autodiscover enabled. Not every client checks for these records, and if you ever set up something that doesn’t support autodiscover, you’ll want the IMAP and SMTP values on hand rather than digging back through hPanel at that moment.
That covers getting mail into a client. Now for the part that decides whether the mail you send actually reaches anyone.
Step 4: Set Up the DNS Records That Control Delivery and Trust
Everything up to this point gets you connected to a mailbox, but whether your email is actually trusted and delivered reliably depends on a separate set of DNS records that most setup guides skip over.
These records tell the wider internet, other mail servers, spam filters, inboxes you’re sending to, that your domain is legitimately sending mail and that nobody’s impersonating it.
I checked all four record types Hostinger manages for this domain, and one of them, DKIM, actually has two different configurations that aren’t interchangeable, which is worth understanding before you touch either one.
4a. MX Records: Where Incoming Mail Gets Routed
MX records tell the internet which servers should receive mail addressed to your domain. Without them, mail sent to your address has nowhere to go. Hostinger sets two:
| Type | Name | Value | Priority | TTL |
|---|---|---|---|---|
| MX | @ | mx1.hostinger.com | 5 | 14400 |
| MX | @ | mx2.hostinger.com | 10 | 14400 |

The priority number determines order, and lower numbers get tried first. So incoming mail attempts delivery to mx1 before falling back to mx2 if the first server doesn’t respond. Having two MX records rather than one gives your mailbox a fallback path, which matters more than it sounds like during any brief server hiccup on Hostinger’s end.
4b. SPF: Stopping Spoofed Mail From Your Domain
Next, check the SPF record. SPF (Sender Policy Framework) is a single TXT record that lists which servers are allowed to send mail claiming to be from your domain:
| Type | Name | Value | TTL |
|---|---|---|---|
| TXT | @ | v=spf1 include:_spf.mail.hostinger.com ~all | 3600 |
Without this record, nothing technically stops someone else from sending mail that appears to come from your address, since receiving servers have no reference point to check against.

With it in place, a receiving mail server can look up your domain’s SPF record and see that only Hostinger’s mail servers are authorized to send on your behalf. Mail claiming to be from you but originating elsewhere gets flagged or rejected instead of landing in someone’s inbox looking legitimate.
4c. DKIM: Two Separate Setups That Aren’t the Same Thing
After SPF, DKIM is the record I’d genuinely slow down on, because Hostinger splits it across two different tools in hPanel, and mixing them up causes real confusion.
The first lives on the same Domain settings page as MX and SPF, under “Keep your emails out of the spam folder.” It adds three CNAME records automatically:
| Type | Name | Value | TTL |
|---|---|---|---|
| CNAME | hostingermail-a._domainkey | hostingermail-a.dkim.mail.hostinger.com | 300 |
| CNAME | hostingermail-b._domainkey | hostingermail-b.dkim.mail.hostinger.com | 300 |
| CNAME | hostingermail-c._domainkey | hostingermail-c.dkim.mail.hostinger.com | 300 |
This is the setup that’s already active and verified if your domain uses Hostinger’s nameservers. It needs no action from you at all.

The second is a separate menu item in the Emails sidebar called Custom DKIM, and it generates a single TXT record instead:
| Type | Name | Value |
|---|---|---|
| TXT | hostingermail1._domainkey | v=DKIM1; k=rsa; p=[unique key generated per domain] |
I’d reach for this second option if your domain’s DNS is managed outside Hostinger.

It gives you one record you control directly and can regenerate whenever you want, rather than depending on three CNAME records that only resolve correctly through Hostinger’s own DNS infrastructure. What I wouldn’t do is set up both at once on a domain already using Hostinger’s nameservers, since having two active DKIM configurations pointing to different keys can cause verification conflicts rather than adding extra protection.
Either way, what DKIM actually does is attach a cryptographic signature to outgoing mail that receiving servers can verify against the public key published in this DNS record. If the signature checks out, the receiving server has real confidence the message wasn’t altered in transit and genuinely came from where it claims.
This is one of the bigger factors in whether your mail lands in an inbox or a spam folder, so it’s not a record worth skipping even though it looks like the most technical piece of this setup.
4d. DMARC: Deciding What Happens When Checks Fail
Last in this section, DMARC builds on top of SPF and DKIM by telling receiving servers what to actually do when a message fails those checks.
| Type | Name | Value | TTL |
|---|---|---|---|
| TXT | _dmarc | v=DMARC1; p=none | 3600 |
The p=none policy Hostinger sets by default is intentionally the gentlest option available. It tells receiving servers to monitor failures rather than reject or quarantine the mail outright.

That’s a sensible default for getting started, since a stricter policy applied too early, before you’re confident every legitimate source of your outgoing mail is properly authenticated, can end up blocking your own mail.
If you want stricter enforcement later, like quarantining or rejecting mail that fails authentication, you’d need to edit this record’s policy value yourself. Hostinger doesn’t offer a stricter preset through the interface.
Hostinger auto-generates every DNS record email needs, including a genuinely useful second DKIM option for domains managed outside its own nameservers, something most competitors don’t offer at all.
Where this setup asks a bit more of you is understanding what each record actually protects against, and recognizing that none of it applies automatically unless your domain’s DNS is pointed at Hostinger in the first place.
With all four steps done, an app connected and DNS confirmed, your setup is complete. If something still isn’t working, the section below covers the issues I’d check first.
Troubleshooting: What to Check If Something’s Not Working
Most setup failures trace back to one of a few specific causes, and it’s worth checking these in order rather than assuming the whole configuration is broken.
- Client won’t connect at all. This is almost always either the wrong port, missing SSL/TLS encryption, or a typo in the hostname. Go back to the Step 1 settings and verify each field individually rather than retyping the whole thing from memory.
- Mail sends but doesn’t receive, or the reverse. IMAP and SMTP are configured separately in most clients, and it’s easy to finish one and assume you’re done. If incoming works but outgoing doesn’t, or vice versa, check that both sets of settings were actually saved.
- DNS records show as unverified. DNS propagation isn’t instant, particularly for TXT and CNAME records, so give it some time before assuming something’s wrong. Use the Check status button on the Domain settings page rather than guessing.
- DKIM verification looks broken. Confirm you’re not running both the automatic CNAME-based DKIM and a manually added Custom DKIM record at the same time on a domain managed through Hostinger’s nameservers, since that combination is a common source of conflicting results.
- Autodiscover isn’t picking up settings. Not every client checks for autodiscover records, and support varies by client and even by version. If it’s not working, fall back to the Step 1 manual settings rather than troubleshooting the autodiscover records themselves.

