Point Namecheap Domain to Hostinger Nameservers Without Breaking Email

Switching your nameservers wipes out your active DNS zone on the registrar side the second the new delegation propagates. If your business email runs through Google Workspace, Microsoft 365, or Namecheap Private Email, pointing your Namecheap domain to Hostinger without pre-configuring your mail records first will silently drop inbound messages and send senders straight into bounce-back purgatory.

I hit this exact headache during a client migration to Hostinger. The web redesign went live cleanly, but their sales team suddenly stopped getting leads because their Namecheap webmail records vanished from public DNS. Here is how to audit your MX, SPF, DKIM, and DMARC records, stage them inside Hostinger’s DNS Zone Editor beforehand, verify everything via CLI, and flip the switch without losing a single incoming email.

Why Switching Nameservers Breaks Active Mailboxes

When you register a domain at Namecheap, it defaults to Namecheap BasicDNS. Every DNS query for your website, subdomains, and mail exchangers resolves against Namecheap’s infrastructure. The second you change those authoritative nameservers to Hostinger (ns1.dns-parking.com and ns2.dns-parking.com), recursive resolvers around the world stop asking Namecheap and start asking Hostinger.

The trap is that Hostinger provisions a generic DNS zone for new domains. By default, that fresh zone either has no MX records or points them to Hostinger’s internal email servers. When outside mail servers look up your domain, Hostinger tells them to deliver locally. Since those mailboxes don’t exist on Hostinger, the messages bounce immediately with unresolvable host or user-not-found errors.

To avoid this, you have to extract your live DNS zone from Namecheap and stage every single email record on Hostinger before you touch the nameserver settings.

Step 1: Audit and Export Current DNS Records from Namecheap

Log in to Namecheap, head to your Domain List, click Manage next to the domain, and jump to the Advanced DNS tab. You need a complete inventory of your email routing and security records before touching anything else.

Copy these four record types into a scratchpad text file:

• MX Records: The mail servers handling inbound routing (like mail.privateemail.com or Google’s aspmx.l.google.com) along with their priorities (10, 20, etc.).
• SPF Records: The TXT record starting with v=spf1 that lists which IPs and hosts are allowed to send mail for you.
• DKIM Records: The TXT or CNAME record storing your public signing key (usually tucked under a selector like default._domainkey).
• DMARC Records: The TXT record at _dmarc.yourdomain.com that instructs receivers what to do if SPF or DKIM fails.

If you need a refresher on how these records link together, check out our guide on how to configure SPF, DKIM, and DMARC in Namecheap DNS. Running Namecheap’s hosted email? Follow the manual values in our walkthrough to configure Namecheap Private Email MX, SPF, and DKIM records manually.

Before moving on, verify what the world currently sees by running dig against public resolvers:

dig +short MX yourdomain.com
dig +short TXT yourdomain.com
dig +short TXT _dmarc.yourdomain.com

Save that terminal output. You’ll want it side by side with your post-migration checks later.

Step 2: Add Domain and Stage Mail Records in Hostinger hPanel

You don’t need to delegate nameservers to populate Hostinger’s zone file. We can stage the entire DNS zone inside hPanel while Namecheap is still handling live traffic.

1. Log into your Hostinger hPanel.
2. Go to Websites > Add Website (or Create or Migrate a Website).
3. Select your platform and choose Use an Existing Domain. Type in your Namecheap domain name.
4. Once Hostinger creates the site container, navigate to Advanced > DNS Zone Editor.

Look at the default MX records Hostinger creates: they typically point to mx1.hostinger.com and mx2.hostinger.com. Delete both immediately. Leaving them will route inbound mail straight into dead mailboxes on Hostinger’s cluster.

Now, add your real MX records one by one. For example, if you are running Google Workspace:

Type: MX
Name: @
Points to: aspmx.l.google.com
Priority: 1
TTL: 3600 Type: MX
Name: @
Points to: alt1.aspmx.l.google.com
Priority: 5
TTL: 3600

Add all secondary records your provider requires (such as alt1.aspmx.l.google.com through alt4.aspmx.l.google.com) with their matching priority numbers.

Step 3: Replicate SPF, DKIM, and DMARC in Hostinger

Inbound mail might work with just MX records, but your outbound emails will land directly in spam—or get dropped outright—if you miss SPF and DKIM. Authentication headers must remain consistent across nameserver hops.

In Hostinger’s DNS Zone Editor, create a new TXT record for SPF. Leave the Host field as @ and paste your exact SPF string into the TXT value box:

Type: TXT
Host: @
TXT Value: v=spf1 include:_spf.google.com ~all
TTL: 3600

Next, set up DKIM. DKIM uses a subdomain selector, usually something like google._domainkey or s1._domainkey. In Hostinger, only paste the selector prefix into the Host field; don’t paste your full domain name or Hostinger will double-append it:

Type: TXT
Host: google._domainkey
TXT Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0wJ...IDAQAB
TTL: 3600

Finally, recreate your DMARC policy:

Type: TXT
Host: _dmarc
TXT Value: v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@yourdomain.com
TTL: 3600

Double-check your A and CNAME records here too so your web traffic hits the right server once nameservers update. If you run standalone apps alongside your main site, see our setup for how to deploy a web app on Hostinger with Namecheap DNS and StackPath CDN.

Step 4: Update Nameservers in Namecheap

Now that Hostinger’s zone editor is completely staged with your existing mail configuration, it’s safe to flip the switch at Namecheap.

1. Head back to the Namecheap Dashboard.
2. Find your domain and hit Manage.
3. Under the Nameservers section, swap Namecheap BasicDNS to Custom DNS.
4. Enter Hostinger’s authoritative nameservers:

Nameserver 1: ns1.dns-parking.com
Nameserver 2: ns2.dns-parking.com

Click the green checkmark to save. Namecheap warns you that propagation can take up to 48 hours, but in practice, recursive DNS resolvers pick up the new NS delegation within 15 to 45 minutes.

Step 5: Verify DNS Propagation and Mail Integrity

Don’t just wait around hoping emails come through. Query Hostinger’s nameservers directly from your terminal to verify they are already serving your staged records:

# 1. Check if public resolvers see the new nameservers
dig NS yourdomain.com @8.8.8.8 +short # 2. Query Hostinger's nameservers directly for your MX records
dig MX yourdomain.com @ns1.dns-parking.com +short # 3. Query Hostinger directly for your SPF TXT record
dig TXT yourdomain.com @ns1.dns-parking.com +short # 4. Verify DKIM record response
dig TXT google._domainkey.yourdomain.com @ns1.dns-parking.com +short

If Hostinger’s nameserver answers back with your real mail provider’s hosts and not parking records, your inbound mail flow is safe. Any external mail server that picks up the new nameservers will get pointed to the right place immediately.

You can monitor public resolver uptake using whatsmydns.net, and send a test message to Mail-Tester to verify your SPF and DKIM signatures still pass muster.

What I Ran: Real Migration Script to Verify Zero Mail Drops

Instead of manually spamming dig commands every two minutes during a migration, I run this quick loop in a terminal window. It checks Cloudflare (1.1.1.1) and Google (8.8.8.8) every 60 seconds to watch the nameserver transition happen in real time:

#!/usr/bin/env bash DOMAIN="yourdomain.com"
RESOLVER="1.1.1.1" echo "Tracking MX records for $DOMAIN using resolver $RESOLVER..." for i in {1..15}; do TIMESTAMP=$(date +"%T") CURRENT_MX=$(dig +short MX "$DOMAIN" @"$RESOLVER" | tr 'n' ' ') CURRENT_NS=$(dig +short NS "$DOMAIN" @"$RESOLVER" | tr 'n' ' ') echo "[$TIMESTAMP] NS: $CURRENT_NS" echo "[$TIMESTAMP] MX: $CURRENT_MX" if [[ "$CURRENT_MX" == *"hostinger"* ]]; then echo "[ALERT] Detected Hostinger default mail server! Fix DNS zone now." fi sleep 60
done

You’ll see the nameservers switch over to dns-parking.com while your MX responses stay rock solid on your mail provider throughout the entire window.

The Gotcha I Fixed: Hostinger Webmail Auto-Routing Overwrite

Here is an edge case that bit me hard on an earlier client site: even when your MX records point to Google or Namecheap, Hostinger has an internal setting called Email Routing that can hijack local forms.

If Hostinger sees your domain attached to an active hosting plan, its local Postfix service assumes it should handle email locally. When a user submits a WordPress contact form or PHP script on the site, the server tries to route that notification internally instead of looking up the external MX records on the internet. Since the mailbox doesn’t live on Hostinger, the email simply vanishes.

Here is how to shut that down:

1. In Hostinger hPanel, head to Emails > Email Services.
2. Select your domain.
3. Find Mail Exchange (MX) records setting or Email Routing.
4. Change it from Hostinger Automatic to External / Custom Mail Exchanger.

This tells Hostinger’s local mail transfer agent: “Never deliver mail locally for this domain. Always resolve MX records via public DNS.” If your contact form alerts break after a move, this is almost always why.

Alternative Strategy: Keep Namecheap DNS and Point A Records

If this nameserver shuffle feels like unnecessary overhead, you don’t actually have to change nameservers at all. If you have complex DNS zones, staging records, or secondary routing already running smoothly on Namecheap, keep them there.

Leave your domain on Namecheap BasicDNS and just point your web traffic to Hostinger using standard records:

• Keep nameservers set to Namecheap BasicDNS.
• Find your Hostinger server IP inside hPanel under Websites > Hosting Details > Server IP.
• In Namecheap Advanced DNS, point your apex @ (A record) to the Hostinger IP.
• Point your www record (CNAME) to yourdomain.com.
• Leave every single MX, SPF, DKIM, and DMARC record right where it is.

This completely eliminates email downtime risks because your authoritative DNS never leaves Namecheap. The main trade-off is losing Hostinger’s auto-configured subdomains and automatic DNS management for add-on services. If you prefer this route, see our guide on how to deploy an apex domain on Hostinger behind StackPath CDN with Namecheap DNS.

Frequently Asked Questions

Will existing emails inside my mailboxes be deleted during this change?

No. Your emails live on your actual mail provider’s infrastructure (Google, Microsoft, or Namecheap Private Email). DNS only dictates where future messages get delivered. Changing nameservers doesn’t touch your existing inbox data at all.

How long does it take for MX records to update globally?

MX TTLs typically sit between 300 seconds (5 minutes) and 86400 seconds (24 hours). Because you pre-staged matching MX values in Hostinger before switching nameservers, there is zero gap: both old and new authoritative nameservers answer with the exact same mail destination throughout the entire transition.

Why does Hostinger say “Domain is not pointing to Hostinger”?

Hostinger caches dashboard-level DNS checks aggressively. Even after your terminal shows that 8.8.8.8 resolves to Hostinger’s nameservers, hPanel’s UI can lag behind by 1 to 4 hours. As long as running dig NS yourdomain.com returns ns1.dns-parking.com, you can safely ignore the dashboard warning.

Do I need to copy CNAME records for autodiscover and mail clients?

Yes. If your desktop or mobile mail clients rely on autodiscovery (records like autodiscover.yourdomain.com or mail.yourdomain.com), copy those CNAMEs from Namecheap into Hostinger’s DNS Zone Editor alongside your MX records.

Next Steps for Your Setup

Now that your domain points to Hostinger without touching your inbound email pipeline, lock down the rest of your server setup. If this is a WordPress site, check out our guide on how to replace WP-Cron with a Linux system cron on Hostinger to keep background jobs, scheduled posts, and transactional emails firing reliably.