Hostinger bundles email accounts on every WordPress plan: up to 100 free mailboxes at the hosted domain, with IMAP, POP3, SMTP, webmail, and forwarding. WordPress’s own outbound mail leaves through PHP’s mail() function on the local server unsigned by default, which is the same starting position as most generic shared hosts and the same gap the SMTP plugins exist to fill. Hostinger documents the SMTP host (smtp.hostinger.com:465) for routing WordPress through a bundled mailbox, and the standard submission ports are open for a third-party relay swap. Sending caps are 100 messages per mailbox per day on the free tier and 1,000 or 3,000 per day on the Business Email tiers. The marketing trade-off is that intro prices ($2.99/month Premium) require a 48-month commitment and renew at $10.99/month or more.
Plans renew at $10.99/month (Premium), $14.99/month (Business), and $24.99/month (Cloud Startup), billed annually or longer. Hostinger sits in the budget shared-hosting tier, well below managed-WordPress hosts like Kinsta and WP Engine, and roughly aligned with Bluehost on renewal pricing.
Email on Hostinger
How wp_mail works by default
A fresh WordPress install on Hostinger sends mail through PHP’s mail() function, which hands off to the local server’s sendmail configuration. No SMTP plugin is required to get the default path running; password resets, WooCommerce order confirmations, and comment notifications all leave through this path on a brand-new install.
The gap on the default path is DKIM (the cryptographic signature receiving servers use to confirm a message came from your domain). Hostinger does not sign PHP mail() traffic out of the box. Its hPanel does support SPF and DKIM at the DNS layer (the 
auto-configuration option publishes both when the domain uses Hostinger nameservers), but those records are for the bundled mailbox path, not for PHP mail() going out via the local server. Most operators close this gap by installing an SMTP plugin and pointing it at one of two routes: Hostinger’s own mailbox SMTP (smtp.hostinger.com:465), which signs with the DKIM Hostinger auto-publishes, or a third-party relay that brings its own DKIM. Hostinger’s own WordPress SMTP tutorial walks through both.
Outbound SMTP port status
| Port | Status | Protocol |
|---|---|---|
| 25 | Open | SMTP (legacy) — Hostinger documents that port 25 is not blocked on VPS, subject to a 5-emails-per-minute rate limit; shared hosting behaves the same in practice |
| 465 | Open | SMTPS (implicit TLS) — the port Hostinger’s own tutorial uses for the bundled smtp.hostinger.com mailbox |
| 587 | Open | SMTP with STARTTLS — the standard submission port for external relays |
| 2525 | Open | SMTP (alternate) |
| 993 | Open | IMAPS (incoming, bundled mailboxes) |
| 995 | Open | POP3S (incoming, bundled mailboxes) |
Hostinger does not publish a port-status table of its own. Port 465 is the one its WordPress SMTP tutorial uses, with SSL, for the bundled mailbox path. The remaining outbound rows are based on Hostinger’s VPS port-25 policy applied to the shared infrastructure and on the same plugins (WP Mail SMTP, FluentSMTP, Post SMTP) routinely connecting from Hostinger sites to Postmark and SMTP2GO without trouble.
Sending limits
| Tier | Daily limit (per mailbox) |
|---|---|
| Free email (bundled with hosting) | 100 in / 100 out |
| Business Email Starter | 1,000 in / 1,000 out |
| Business Email Premium | 3,000 in / 3,000 out |
Hostinger’s documented policy treats the daily limit as per-mailbox in each direction; a mailbox sending 1,000 messages and receiving 1,000 in a day is operating at its Business Starter ceiling. The free tier’s 100-a-day-per-mailbox limit is generous enough for one operator’s personal account but tight for any per-mailbox transactional pattern (orders@, noreply@, contact-form senders).
WordPress’s wp_mail() itself does not consume mailbox sending quota when it leaves through PHP’s mail() function on the local server, because the local sendmail handoff bypasses the Business Email mail server entirely. The 100-a-day limit applies only to the mailbox path: sites that route wp_mail() through an SMTP plugin connected to smtp.hostinger.com:465 are subject to the mailbox quota; sites that leave wp_mail() on PHP mail() are subject only to whatever rate limits the shared host’s outbound queue applies. The practical implication is that the bundled limits matter most for sites that have configured WordPress to authenticate against the Hostinger mailbox; sites on the default PHP mail() path face a different ceiling that Hostinger does not publish.
Mailboxes, forwarding, DNS
The free tier supports up to 100 mailboxes per domain on every WordPress plan, with IMAP, POP3, SMTP access for mail clients and webmail through hPanel. Storage per mailbox depends on the plan tier and the bundled-email product version on the account: legacy free mailboxes range from 1 GB to 15 GB; paid Business Email tiers run 5 GB (Starter) or 50 GB (Premium) per mailbox. Forwarding rules are configured in the same hPanel section; no separate forwarding service is needed.
Hostinger manages DNS through hPanel for any domain whose nameservers point at Hostinger. The standard A, CNAME, MX, and TXT record types are editable in the dashboard, and the “Connect domain automatically” option publishes the required SPF and DKIM records for the bundled mailbox in a single step. If DNS lives elsewhere (Cloudflare is the common one), the records are added manually at that provider, and the auto-publish convenience disappears.
Authentication (SPF, DKIM, DMARC)
Hostinger auto-publishes SPF and DKIM when the domain uses Hostinger nameservers and the operator clicks “Connect domain automatically.” The SPF include is spf.mx.hostinger.com; the DKIM record covers the bundled mailbox path. On a domain set up this way, mail leaving through smtp.hostinger.com is already SPF-aligned and DKIM-signed at the mailbox layer, which is the platform’s main authentication asset.
What the auto-publish does not cover is the PHP mail() path on the default wp_mail() route. Mail leaving the local server through sendmail uses neither the mailbox SMTP nor the DKIM key published for the bundled mailbox. That path is unsigned, and the SPF check it relies on depends on the IP address of the shared server rather than the mailbox SPF record. The standard fix is to install an SMTP plugin and route WordPress through smtp.hostinger.com:465 so that wp_mail() traffic inherits both the SPF alignment and the DKIM signature the platform already publishes for the mailbox.
SPF (the DNS record listing which servers are authorised to send mail under the domain) usually needs hand-merging when a third-party relay is also in play. A site that signs through smtp.hostinger.com and uses a third-party relay (Postmark, SMTP2GO, Mailgun) needs the includes for both. Hostinger’s own guidance on the auto-config flow covers the bundled mailbox alone.
DMARC is treated as the operator’s choice. Hostinger does not auto-publish a DMARC policy; the authentication tutorial walks through adding a _dmarc TXT record by hand. p=none with a rua= reporting address is the conservative starting position; tightening belongs after aggregate reports confirm clean alignment.
What Hostinger does not provide
- DKIM on the PHP
mail()path. The defaultwp_mail()route is unsigned. Routing WordPress throughsmtp.hostinger.com:465via an SMTP plugin inherits the auto-published DKIM; a third-party relay brings its own. Either fixes the gap. - A dedicated sending IP. Outbound mail shares the hosting server’s IP with other Hostinger customers on shared plans, and the bundled mailbox path shares Hostinger’s own mail-server IP across tenants. Deliverability isolation requires a relay with a dedicated-IP add-on (Postmark on Dedicated IP; Mailgun on Foundation).
- Per-message delivery logs, bounce tracking, and webhook events. Hostinger surfaces no log of what was sent, what bounced, or what hit spam. Relays with delivery webhooks (Postmark, Mailgun, SMTP2GO) are the way to get that visibility.
- Marketing or bulk sending allowance. Bundled mailbox traffic is for human-to-human and transactional use; broadcast traffic belongs on a dedicated marketing platform (Mailchimp, MailerLite, ConvertKit).
- A custom return-path domain on the mailbox path. The bundled Hostinger mailbox uses the mailbox address as both header and envelope From; on the PHP
mail()path the envelope is whatever the local sendmail config sets. Third-party relays (Postmark, Mailgun) expose a configurable return-path domain.
When a third-party relay is needed
Hostinger’s bundled mail and the smtp.hostinger.com route, used together, are enough for most low-traffic WordPress sites. A personal site, a small WooCommerce store running a handful of orders a day, a membership site with a few hundred active users: all of these sit comfortably inside the 100-a-day-per-mailbox tier with the SMTP plugin pointed at the bundled mailbox.
A dedicated relay is the right call when:
- Mailbox volume crosses the daily cap. A
noreply@ororders@mailbox approaching 100 outbound messages a day on the free tier, or 1,000 on Business Email Starter, should move WordPress to a relay that does not share the mailbox quota. SMTP2GO is the cheapest credible option for low volumes; Postmark is the cleanest fit for transactional sites under 100,000 a month; Mailgun is where higher volumes make economic sense. - A missed email has a real cost. Sites whose business depends on order confirmations and password resets landing in the inbox should not rely on a shared-IP host’s deliverability alone. Layering a relay with bounce webhooks, suppression lists, and event logs is how a site catches and reacts to failed delivery.
- Delivery visibility is required. Per-message delivery, bounce, and complaint events arrive as webhooks from Postmark, Mailgun, and SMTP2GO, with searchable logs and aggregate dashboards. Hostinger’s bundled path surfaces none of this.
- The site needs marketing or newsletter sending. Bundled mailboxes are not the right route. A marketing platform (Mailchimp, ConvertKit, MailerLite) handles the campaign side; a dedicated transactional relay handles the transactional side.
Because the standard submission ports are open, an SMTP plugin connects to any of these providers without an API-only constraint. SMTP is simpler to set up; the providers’ HTTP APIs hold up better when DNS or network changes shift things around. Both work.
Going the other way, sites following the WordPress without the plugin minimum-stack pattern can use Hostinger’s bundled mailbox as the WordPress sender directly and skip the SMTP plugin; the host’s relay is what makes that no-plugin slice viable here.
Verdict
Hostinger is the right pick for budget-conscious operators who want WordPress hosting and bundled mailboxes from one provider, are happy to wire WordPress through an SMTP plugin to inherit the auto-published DKIM, and are willing to plan for the higher renewal prices. The intro pricing genuinely is cheap (Premium at $2.99/month for a 48-month commitment) and the auto-publish DKIM is more than most budget hosts ship. The trade-off is the renewal step at year four ($10.99/month Premium, $14.99/month Business, $24.99/month Cloud Startup), the unsigned PHP mail() default path that needs an SMTP plugin to close, and the 100-a-day mailbox cap on the free tier that any per-mailbox transactional flow will run into. For the WordPress email setup that supplements Hostinger’s default path, see how to configure WordPress email.