Configure Remote Email Routing in Hostinger hPanel

Your site sits on Hostinger, but your mailboxes live somewhere else—Google Workspace, Microsoft 365, or Namecheap Private Email. A visitor fills out your contact form, hits submit, sees a green success message, and then complete silence. The email never arrives in your inbox.

You’re stuck in a local delivery black hole. Here is how to flip Hostinger hPanel over to remote email routing and get your DNS records aligned so messages actually reach your real mailbox.

The Local Delivery Loop: Why Your Forms Disappear

When PHP sends an email to user@example.com from your server, the underlying mail transfer agent (MTA) checks its own configuration before touching public DNS. If Hostinger thinks it handles mail for example.com, it drops the message straight into a local mailbox on that server.

Because your actual inbox lives externally on Google Workspace or Fastmail, that message goes to a local inbox nobody will ever log into. External people can email you without issues because their mail servers check your public MX records. But any message coming from your own web server—contact forms, WooCommerce receipts, password resets—stalls out quietly.

You have to explicitly tell Hostinger to stop accepting mail locally and force it to look up authoritative MX records across the internet. If you manage nameservers elsewhere, knowing how to point Namecheap DNS to Hostinger without breaking email prevents these routing issues from day one.

Prerequisites and Verifying Your Current MX Records

Before flipping any switches in hPanel, check where your active MX records actually point. You do not want to force remote routing if your public DNS is still pointed at Hostinger’s mail servers.

Fire up a terminal and run dig to see what the internet sees:

dig +short MX example.com

If you’re on Google Workspace, you should see 1 smtp.google.com. or the older aspmx.l.google.com endpoints. If you see mx1.hostinger.com, your public DNS records are wrong and you need to fix those first. Check the Google Workspace MX record documentation if you need to double-check the exact records your provider expects.

Step-by-Step: Changing Email Routing to Remote in hPanel

Hostinger manages this routing flag directly inside the Emails section of hPanel. Here is where the toggle is buried:

1. Log in to hPanel and open Emails from the sidebar.
2. Click on your domain name.
3. Look for Email Services or Manage Email, then find Email Routing (on some account layouts, this is grouped under DNS / MX Records).
4. Find the Mail Routing setting. It defaults to Local Mail Exchanger.
5. Switch it to Remote Mail Exchanger.
6. Click Save or Update.

This rewrites the MTA’s internal transport map on Hostinger’s side. The server now bypasses local delivery entirely and does a fresh DNS query whenever your PHP code fires off an email.

Aligning MX, SPF, and DKIM Records

Flipping the routing toggle solves the delivery path, but external hosts might still bin your mail if your SPF record doesn’t authorize Hostinger’s web server IP. When WordPress sends mail via the default PHP mail() handler, the receiving provider checks your domain’s SPF record against Hostinger’s IP address.

If your SPF string only includes Google or Microsoft, your form submissions will trigger a soft fail or land straight in spam. You can authorize both in the same record. If your nameservers sit at your registrar, follow our guide to configure SPF, DKIM, and DMARC in Namecheap DNS.

Here is an example TXT record for your root domain (@) that permits both Google Workspace and Hostinger web servers:

v=spf1 include:_spf.google.com include:_spf.hostinger.com ~all

Do not publish two separate SPF records. Per RFC 7208, a domain must have only one SPF string. Publishing multiple TXT records for SPF returns a PermError, which kills deliverability faster than having no SPF at all.

Testing PHP Mail After the Routing Change

Don’t wait for a user to report a broken form. You can test mail delivery straight from the command line on your Hostinger account.

SSH into your instance and fire off a quick one-liner using PHP’s CLI:

php -r 'mail("admin@example.com", "Routing Test", "Testing remote delivery from CLI", "From: webmaster@example.com");'

Swap in your real inbox for admin@example.com. Check your inbox within a minute or two. If it shows up, Hostinger successfully handed off the mail to your remote MX host. If it bounces back or ends up in junk, look at the raw headers to see whether SPF or DKIM failed.

Fixing WordPress SMTP When Remote Routing Still Fails

Even with remote routing enabled, relying on PHP’s built-in mail() function on shared hosting is fragile. Shared IP ranges get abused, and services like Outlook or Gmail frequently flag them. The real fix for production WordPress sites is setting up authenticated SMTP.

Instead of storing credentials in plain text inside your WordPress dashboard, you can define them in wp-config.php:

define('WPMS_ON', true);
define('WPMS_SMTP_HOST', 'smtp.gmail.com');
define('WPMS_SMTP_PORT', 587);
define('WPMS_SSL', 'tls');
define('WPMS_SMTP_AUTH', true);
define('WPMS_SMTP_USER', 'you@example.com');
define('WPMS_SMTP_PASS', 'your-app-password');
define('WPMS_MAIL_FROM', 'you@example.com');

Most modern SMTP plugins pick up these constants automatically. This bypasses the local mail server completely; your site connects straight to your provider over TLS on port 587. If you use a custom mailbox setup instead of Google, check our guide on how to keep Namecheap Private Email working on Hostinger nameservers for the right ports and hostnames.

What I Ran: Debugging a Dropped Form Submission

I ran into this exact issue during a site migration last month. A client’s Elementor form returned a clean 200 OK on submission, but leads were completely vanishing. When I checked the mail activity on the server, messages were bouncing locally with an unknown user error.

I checked how the server was resolving the domain using host:

host -t mx example.com

Public DNS pointed cleanly to Microsoft 365, but the server’s local MTA was still trying to dump messages into /var/mail/example.com. The hPanel routing flag was still on Local Mail Exchanger. The moment I flipped it to Remote Mail Exchanger, the queue flushed out to Microsoft 365 within three minutes, and backlogged submissions finally landed in the inbox.

Common Routing Gotchas to Watch Out For

• Conflicting Zone Files: If your domain uses Cloudflare or Namecheap nameservers, changing MX records in Hostinger hPanel does nothing for public lookups. You still have to set Remote Routing in hPanel, though, just to stop Hostinger’s internal mail server from intercepting the traffic.
• Subdomain Overrides: Subdomains like staging.example.com inherit primary zone rules unless you specifically define separate MX records for them.
• Greylisting Delays: Some mail servers temporarily reject the first connection from an unfamiliar web server IP with a 451 Try again later code. Give it ten to fifteen minutes before deciding something broke. Check the IANA SMTP Enhanced Status Codes directory if you need to decipher weird bounce codes.

Frequently Asked Questions

What is the difference between Local, Backup, and Remote mail routing?

Local Mail Exchanger forces the server to deliver mail to inboxes hosted on that same machine. Backup Mail Exchanger holds mail in a queue if your primary external server goes down. Remote Mail Exchanger tells the server to ignore local mailboxes entirely and send everything to external MX records.

Do I need to change email routing if I use Hostinger Webmail?

No. If your mail is hosted on Hostinger and you use their webmail or native IMAP/POP3 servers, leave it set to Local Mail Exchanger or Automatic.

Why are form notifications going to spam after switching to Remote routing?

Your external provider is receiving mail claimed to be from your domain, but sent by Hostinger’s web server IP without authorization. Add include:_spf.hostinger.com to your domain’s SPF record so the receiving server accepts it.

How long does the routing change take to propagate?

The routing toggle inside hPanel updates almost instantly—usually under two minutes. But if you also had to change public MX records in your DNS zone, those can take anywhere from fifteen minutes to a few hours depending on TTLs.

Next Steps

Once remote routing is in place, your forms and transactional notifications should route straight to your inbox without getting intercepted. If your site handles scheduled publishing, backups, or e-commerce workflows alongside email, take a look at our guide on how to disable WP-Cron and set up a real cron job in Hostinger hPanel to keep background tasks running reliably.