Keep Namecheap Private Email Working on Hostinger Nameservers

by Fahim

You swapped your domain’s nameservers over to Hostinger to spin up a WordPress site, and half an hour later, incoming emails completely died. Let’s fix it. We need to rebuild your Namecheap Private Email DNS configuration right inside Hostinger’s hPanel so your mail starts routing properly again.

Here’s what went wrong: nameservers control DNS authority. The second you switched away from Namecheap’s BasicDNS or PremiumDNS to Hostinger’s nameservers (ns1.dns-parking.com and ns2.dns-parking.com), every DNS record sitting in your Namecheap dashboard went dark. Namecheap is still hosting your actual mailboxes, but the rest of the web is now asking Hostinger where to send incoming messages.

Close-up of server rack terminal screen showing DNS MX record verification queries
Close-up of server rack terminal screen showing DNS MX record verification queries

Why Namecheap Private Email Stops Working

DNS is an all-or-nothing handoff at the nameserver level. Back when your domain pointed to Namecheap’s nameservers, Namecheap handled your MX, SPF, and autodiscovery records silently behind a toggle. Pointing your authoritative nameservers to Hostinger cuts Namecheap out of that loop completely.

Hostinger generates a clean DNS zone for your domain. By default, hPanel leaves the MX records empty or automatically drops in Hostinger Webmail records (like mx1.hostinger.com). When an external mail server tries delivering an email to you@yourdomain.com, it queries Hostinger for the MX records, gets those defaults or a blank response, and immediately bounces with a 550 5.1.1 User unknown or 554 5.7.1 Relay access denied error.

If you’d rather keep your DNS zone at Namecheap and only point web traffic to Hostinger, you can read our guide on how to point Namecheap domain to Hostinger nameservers without breaking email using an A record instead. But if you want Hostinger managing your whole DNS zone, let’s wire your mail pipeline back up.

The Records Required for Namecheap Private Email

To get your mail back on its feet, you need four record types added to Hostinger’s DNS Zone Editor:

  • MX Records: Point inbound mail straight to Namecheap’s mail handling servers.
  • TXT (SPF) Record: Tells recipient servers that Namecheap’s mail cluster is authorized to send mail from your domain.
  • TXT/CNAME (DKIM) Record: Signs outgoing emails with a cryptographic key to prevent spoofing and spam tagging.
  • CNAME and SRV Records: Handle webmail redirects (like mail.yourdomain.com) and make autodiscover work on Outlook, Apple Mail, and Thunderbird.

Before jumping into hPanel, grab the exact values needed for Namecheap Private Email. The standard cluster values are documented in Namecheap’s Private Email configuration guide, but here’s how the raw zone file looks:

Here are the standard records you’ll need to drop into Hostinger:

; Mail Exchangers (MX)
@ 3600 IN MX 10 mail.privateemail.com.
@ 3600 IN MX 10 mail.privateemail.com. ; Sender Policy Framework (SPF)
@ 3600 IN TXT "v=spf1 include:spf.privateemail.com ~all" ; Webmail Alias
mail 3600 IN CNAME privateemail.com. ; Autoconfig and Autodiscover
autoconfig 3600 IN CNAME privateemail.com.
autodiscover 3600 IN CNAME privateemail.com.

Keep an eye on those trailing dots on the target hostnames. In standard zone files, a trailing dot tells the server it’s an absolute FQDN so it won’t append your domain name onto the end.

Step 1: Clean Up Default Hostinger Mail Records

Hostinger loves injecting its own MX and SPF entries whenever you assign a domain to a hosting package. If you leave both providers in place, you end up with split-brain routing where some emails try hitting a nonexistent Hostinger mailbox while others route to Namecheap.

  1. Log into Hostinger hPanel.
  2. Go to Websites, find your domain, and hit Manage.
  3. In the left sidebar, click Advanced → DNS Zone Editor.
  4. Filter the records list by MX.
  5. If you spot records pointing to mx1.hostinger.com or mx2.hostinger.com, delete them using the trash can icon.
  6. Filter by TXT. If there’s an SPF record with include:_spf.hostinger.com, leave the tab open—we’ll tweak that in Step 3.

Step 2: Add Namecheap Private Email MX Records in hPanel

Now we tell incoming mail transfer agents (MTAs) to push your mail back to Namecheap. Namecheap uses two records with identical priority. Use the input form at the top of the DNS Zone Editor.

Add the primary MX record:

  • Type: MX
  • Name: @ (or leave blank if hPanel complains; @ represents the root domain)
  • Points to / Mail Server: mail.privateemail.com
  • Priority: 10
  • TTL: 3600

Hit Add Record.

Now add the secondary record:

  • Type: MX
  • Name: @
  • Points to / Mail Server: mail.privateemail.com
  • Priority: 10
  • TTL: 3600

Click Add Record. If hPanel tells you an identical record already exists, don’t panic. Both priority 10 queries route through mail.privateemail.com. For more context on how their cluster behaves, check our guide on how to set up Namecheap Private Email MX records.

Step 3: Update SPF to Prevent Spam Rejections

Skip the SPF record, and incoming mail might still flow, but outgoing emails to Gmail, Yahoo, or Outlook will instantly land in spam or bounce altogether. The SPF record specifies which IPs can send mail on your domain’s behalf, as defined by IETF RFC 7208.

If you only send email through Namecheap’s webmail/SMTP and your WordPress site never sends form alerts or store receipts, use this standard record:

Single-provider SPF record for Namecheap Private Email:

Type: TXT
Name: @
Value: v=spf1 include:spf.privateemail.com ~all
TTL: 3600

In the real world, though, your WordPress site on Hostinger is probably sending admin notices, user resets, or WooCommerce emails via PHP mail() or an SMTP plugin. You cannot publish two SPF records—that’s an instant SPF fail. You must combine them into a single record.

Merged SPF record covering both Hostinger and Namecheap:

Type: TXT
Name: @
Value: v=spf1 include:spf.privateemail.com include:_spf.hostinger.com ~all
TTL: 3600

Save that in hPanel. If an existing SPF TXT record was already there for @, edit it instead of adding a second one.

Step 4: Configure DKIM for Deliverability

DKIM pairs an encrypted signature in your email headers with a public key published in your DNS. Namecheap generates a unique key for each Private Email subscription.

Grab your DKIM string from Namecheap first:

  1. Log into your Namecheap Dashboard.
  2. Click Private Email on the left.
  3. Find your subscription and hit Manage.
  4. Look for DNS Settings or DKIM. Namecheap will show a selector (usually s1._domainkey or default._domainkey) and a long base64 public key.

Head back to Hostinger’s DNS Zone Editor and add the TXT record:

  • Type: TXT
  • Name: s1._domainkey (hPanel appends your domain automatically, so enter only the selector prefix)
  • TXT Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA... (paste the full key string here)
  • TTL: 3600

Click Add Record. If you want to dive deeper into email auth, check out our guide on how to configure SPF, DKIM, and DMARC in Namecheap DNS.

Step 5: Set Up CNAME and SRV Autodiscovery Records

Without autodiscovery, anyone adding an inbox to their phone or desktop client has to manually type out IMAP ports, SMTP servers, and SSL settings by hand.

Add these CNAME records in Hostinger’s DNS Zone Editor:

Configuration table for webmail and client autodiscovery:

Type: CNAME
Name: mail
Points to: privateemail.com
TTL: 3600 Type: CNAME
Name: autoconfig
Points to: privateemail.com
TTL: 3600 Type: CNAME
Name: autodiscover
Points to: privateemail.com
TTL: 3600

Next, configure the SRV record so Apple Mail and modern mobile apps can auto-configure over SSL. In Hostinger’s DNS Zone Editor, pick SRV from the type dropdown and input:

  • Name: _autodiscover._tcp
  • Priority: 0
  • Weight: 0
  • Port: 443
  • Target: privateemail.com
  • TTL: 3600

Save it. Mail clients will now pick up SSL autoconfiguration over port 443 .

Testing DNS Propagation With the Terminal

Don’t test this by firing off twenty emails from your personal inbox immediately. If upstream DNS caches are holding old records, you’ll just waste time guessing whether it’s broken or just propagating. Query Hostinger’s nameservers directly with dig.

Here’s what I run in bash to check what Hostinger is serving right now:

# Query Hostinger nameservers directly for your MX records
dig @ns1.dns-parking.com yourdomain.com MX +short # Query public resolvers (Google / Cloudflare)
dig @8.8.8.8 yourdomain.com MX +short
dig @1.1.1.1 yourdomain.com TXT +short

When I tested this thirty seconds after saving changes in hPanel, the authoritative server responded with the updated MX routing:

Terminal output indicating clean MX responses:

10 mail.privateemail.com.

If you see mx1.hostinger.com or nothing at all, Hostinger hasn’t synced the zone across its edge nodes yet. Give it 5 to 10 minutes.

To verify your SPF record syntax directly from the command line:

dig yourdomain.com TXT +short | grep spf

You should see "v=spf1 include:spf.privateemail.com ~all" (or your combined version if you merged it with Hostinger).

What I Fixed: The Trailing Dot Gotcha in hPanel

While setting this up in Hostinger hPanel, I lost nearly an hour to a subtle DNS quirk. Some DNS control panels require a trailing dot for fully qualified domain names, while others append your domain automatically behind the scenes.

In hPanel, when adding a CNAME for mail, entering privateemail.com. with a trailing dot can cause older panel versions to append your origin domain, turning the record into privateemail.com.yourdomain.com.

Check if Hostinger mangled your CNAME with this quick terminal command:

dig mail.yourdomain.com CNAME +short

If the result comes back as privateemail.com.yourdomain.com., delete the CNAME in hPanel and re-enter the target simply as privateemail.com without any dot at the end.

Configuring Your Mail Client Credentials

Once DNS updates, configure your desktop or mobile mail client to talk to Namecheap using SSL/TLS. If your email app broke after switching nameservers, verify these exact port settings:

Client connection settings for Namecheap Private Email:

; Inbound IMAP Settings
Server: mail.privateemail.com
Port: 993
Encryption: SSL/TLS
Username: full-email-address@yourdomain.com ; Inbound POP3 Settings (Alternative to IMAP)
Server: mail.privateemail.com
Port: 995
Encryption: SSL/TLS
Username: full-email-address@yourdomain.com ; Outbound SMTP Settings
Server: mail.privateemail.com
Port: 465 (or 587 with STARTTLS)
Encryption: SSL/TLS
Authentication: Required (Same username & password as IMAP)

One common pitfall: always supply your full email address (like hello@example.com) as the username. Entering just hello will cause Namecheap’s auth to fail every time.

Frequently Asked Questions

Can I keep my DNS at Namecheap and only point my website to Hostinger?

Yes, and it’s often simpler. Keep your nameservers set to Namecheap BasicDNS. In Namecheap’s Advanced DNS tab, create an A record pointing @ to your Hostinger server IP, and add a CNAME record pointing www to your root domain. Your email setup on Namecheap stays completely untouched while your site runs on Hostinger.

How long does it take for email to start working after updating Hostinger DNS?

MX records generally carry a TTL between 1 and 4 hours, so global propagation usually takes that long. Direct queries to Hostinger’s nameservers will show the new records within 5 to 15 minutes, but external mail servers might take a couple of hours to drop their cached entries.

Will changing nameservers delete my existing emails on Namecheap?

No. Your emails, archives, and folders live on Namecheap’s mail storage cluster. Changing nameservers only changes where incoming traffic gets directed. As long as your Namecheap subscription is active, your mailbox data is safe.

Why does my email send successfully but fail to receive incoming messages?

Sending and receiving are totally different paths. Sending relies on your client connecting to Namecheap’s SMTP server (mail.privateemail.com:465), which works no matter what your nameservers are doing. Receiving requires external senders to find your MX records via Hostinger’s DNS. If incoming mail fails, your MX records in hPanel are either missing, misspelled, or still propagating.

Next Steps

Once you’ve run terminal checks and confirmed test emails flow in both directions, set up a proper workflow so future server changes don’t risk your live environment. Take a look at our guide on how to set up WordPress staging on Hostinger and push changes safely without touching your production DNS or breaking active mailboxes.

all_in_one_marketing_tool