You bought Namecheap Private Email, but your nameservers point somewhere else—Cloudflare, Route 53, Hostinger, or DigitalOcean. Namecheap’s one-click email setup only works if your domain uses Namecheap BasicDNS. Because your nameservers point elsewhere, that automated setup does absolutely nothing, leaving your mailbox dead in the water.
To get mail flowing, you have to manually copy the raw MX, TXT, and CNAME records over to wherever your DNS actually lives. I ran into this exact headache last week after moving an app’s DNS to an external provider while keeping our operational inbox on Namecheap. Here is how to wire up the records correctly without breaking existing mail or bouncing incoming messages.
Why External DNS Breaks Namecheap’s One-Click Setup
When your domain uses Namecheap’s default nameservers, their backend automatically injects the right zone records whenever you toggle “Private Email” in the dashboard. But the moment you delegate nameservers to an outside host, Namecheap’s internal DNS zone file stops resolving globally.
Whenever a mail server tries to send you a message, it queries your authoritative nameservers. If your external DNS host doesn’t have Namecheap’s mail servers listed, incoming messages will bounce immediately with 550 5.1.1 or 554 No MX record found.
Whether you’re running your site on a VPS or trying to keep Namecheap Private Email working on Hostinger nameservers, your external DNS host is the sole authority. Every mail routing instruction has to live there.
Gather Your Required Namecheap MX and Mail Records
Namecheap Private Email uses two redundant mail exchangers. You need both in your DNS so inbound mail keeps working even if one node undergoes maintenance.
Here are the MX hostnames and priorities straight from the Namecheap Knowledgebase:
- Primary MX:
mx1.privateemail.com(Priority: 10) - Secondary MX:
mx2.privateemail.com(Priority: 10)
On top of MX routing, you need an SPF TXT record so outgoing messages don’t dump straight into spam, plus a couple of CNAME records for webmail access and autodiscovery.
Step 1: Add the MX Records to Your External DNS
Head to the dashboard of whatever service controls your DNS (Cloudflare, Route 53, Vercel, or Hostinger) and find your domain’s DNS management page.
Check your current records before adding anything. If this domain previously used Google Workspace, cPanel mail, or another host, delete those old MX records now. Leaving old MX records active alongside Namecheap will cause your inbound mail to split randomly between servers.
Add these two MX records:
Type: MX
Name: @ (or your naked domain: example.com)
Mail Server: mx1.privateemail.com
Priority: 10
TTL: 3600 (or Auto) Type: MX
Name: @ (or your naked domain: example.com)
Mail Server: mx2.privateemail.com
Priority: 10
TTL: 3600 (or Auto)If your DNS provider won’t accept @ in the host field, put in your bare root domain (like yourdomain.com). If you’re on Cloudflare, make sure these MX records are set to DNS-only—Cloudflare can’t proxy raw mail traffic over its HTTP proxy.
Step 2: Set Up SPF Without Breaking Existing Senders
MX records handle inbound mail; SPF handles outbound deliverability. Miss this step and providers like Gmail and Outlook will flag your emails as spoofed spam. Under IETF RFC 7208, your domain must only have one SPF TXT record at the root apex.
If Namecheap Private Email is the only tool sending mail from your domain, drop this TXT record at the apex:
Type: TXT
Name: @
Value: v=spf1 include:spf.privateemail.com ~all
TTL: 3600Here’s the trap that bites people: if you’re also sending transactional emails through Postmark, SendGrid, or Mailgun, don’t create a second SPF record. Multiple SPF records cause an automatic PermError, which fails SPF checks entirely.
Merge your senders into a single string instead. For example, if you send app notifications via Postmark alongside your Namecheap inbox, your unified record looks like this:
v=spf1 include:spf.privateemail.com include:spf.mtasv.net ~allCheck out our walkthrough on how to configure SPF, DKIM, and DMARC in Namecheap DNS if you’re building a more complex setup with multiple senders.
Step 3: Extract and Inject the DKIM TXT Record
DKIM adds a cryptographic signature to outbound email headers. Without it, you’ll fail modern sender authentication requirements enforced by Gmail and Yahoo.
Because your DNS is hosted externally, Namecheap can’t inject this key automatically. You have to grab it yourself:
- Log in to Namecheap.
- Go to Apps > Private Email > hit Manage next to your subscription.
- Select your domain and locate the DKIM section.
- Turn it on if it’s disabled. Namecheap will hand you a DNS Host selector and a long public TXT string.
The selector is usually default._domainkey or s1._domainkey. Hop back to your external DNS manager and create the TXT record:
Type: TXT
Name: default._domainkey
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...
TTL: 3600Copy the whole key string cleanly without extra spaces or line breaks. Some DNS dashboards like to strip trailing semicolons, so double-check that the saved value matches Namecheap’s dashboard character for character.
Step 4: Configure Autodiscover and Webmail CNAME Records
You don’t strictly need these to send or receive mail, but they save you from having to type in raw IMAP/SMTP hostnames and ports whenever you connect an email client like Apple Mail, Outlook, or Thunderbird.
For a deeper dive into these sub-records, see our guide on how to manually configure Namecheap Private Email MX and SRV records. On your external DNS host, set up these CNAMEs:
Type: CNAME
Name: mail
Target: privateemail.com
TTL: 3600 Type: CNAME
Name: autoconfig
Target: privateemail.com
TTL: 3600 Type: CNAME
Name: autodiscover
Target: privateemail.com
TTL: 3600The mail CNAME gives you a clean webmail URL at mail.yourdomain.com so you don’t have to remember Namecheap’s generic login link.
Test DNS Propagation with Terminal Commands
Don’t test this setup by emailing yourself from the same webmail account. That routes internally through Namecheap’s mail cluster and completely bypasses public DNS.
Open your terminal instead and query public resolvers like Google (8.8.8.8) or Cloudflare (1.1.1.1) using dig.
First, check the MX records:
dig +short MX yourdomain.com @1.1.1.1You should see both records returned with priority 10:
10 mx1.privateemail.com.
10 mx2.privateemail.com.Next, verify your SPF TXT record:
dig +short TXT yourdomain.com @1.1.1.1Confirm that include:spf.privateemail.com shows up. If you still see references to old mail hosts, purge them from your DNS panel.
Finally, confirm that your DKIM key is resolving:
dig +short TXT default._domainkey.yourdomain.com @1.1.1.1If that returns your public key payload, receiving servers can successfully verify your outbound signatures.
The Trailing Dot Gotcha That Broke My Inbound Mail
This exact quirk cost me 45 minutes of troubleshooting last week: some DNS engines handle fully qualified domain names (FQDN) differently when pointing to external targets.
When I pasted mx1.privateemail.com into a custom DNS panel, the provider assumed it was a relative subdomain and automatically tacked my root domain onto the end. The record silently became:
mx1.privateemail.com.yourdomain.com.Because that target doesn’t exist, every single incoming email bounced with host lookup failures. When you run dig, verify whether the answer shows a trailing dot (mx1.privateemail.com.) or if your domain got appended to the end.
If your DNS manager uses raw BIND syntax, add the trailing dot yourself: mx1.privateemail.com.. If it handles FQDNs automatically (like Cloudflare or Route 53), leave the dot off. Just inspect the raw terminal output to be certain.
Troubleshooting Namecheap Private Email on External DNS
How long does it take for MX records to start working?
It depends on the TTL of your previous DNS records. If your old MX records had a 24-hour TTL (86400 seconds), external mail servers might keep querying your old provider for up to a day. If you created brand new records with a standard 3600-second TTL, propagation usually settles within 15 to 45 minutes.
Why are sent emails going to spam even though MX records are correct?
MX records only handle incoming mail. Deliverability for outbound mail depends on SPF, DKIM, and DMARC. If your messages hit spam, make sure you published the include:spf.privateemail.com TXT record and added the DKIM key under default._domainkey.
Can I keep using Namecheap Free Email Forwarding instead?
No. Namecheap Free Email Forwarding and Private Email are separate products and can’t run on the same domain at the same time. Free forwarding uses mailhub.namecheap.com, while Private Email requires mx1.privateemail.com. If you just need inbound mail piped to a personal inbox, check out our guide on free email forwarding in Namecheap DNS to Gmail instead.
What incoming and outgoing mail server settings should I use in my email client?
Once your DNS records propagate, plug these settings into your email app:
- Incoming Server (IMAP):
mail.privateemail.com| Port 993 (SSL/TLS) - Outgoing Server (SMTP):
mail.privateemail.com| Port 465 (SSL/TLS) or 587 (STARTTLS) - Username: Your full email address (e.g.,
you@yourdomain.com) - Authentication: Password
Next Steps
With your DNS records resolving, send a test email from an outside account (like a personal Gmail address) to make sure messages land in your inbox. Once incoming delivery works, set up a basic DMARC record (_dmarc.yourdomain.com) so you can catch spoofing attempts and monitor auth failures across receiving providers.
