Configure SPF, DKIM, and DMARC Records in Namecheap Advanced DNS

Google and Yahoo will silently trash or outright reject your emails if your SPF, DKIM, and DMARC aren’t dialed in. I learned this the hard way during a production migration last month: our signup confirmation emails suddenly vanished into Gmail’s spam void within 12 hours of flipping DNS. Sender reputation was clean and our IP wasn’t blacklisted. The culprit? A dumb typo in Namecheap’s Host field and two conflicting SPF records clobbering each other.

Here’s how to configure all three records cleanly inside Namecheap Advanced DNS so your transactional alerts and team emails actually hit the inbox.

Verify Your Namecheap Nameserver Configuration

First, make sure Namecheap actually manages your DNS. If your nameservers point off to Cloudflare, Hostinger, or DigitalOcean, adding records in Namecheap won’t do a thing.

• Jump into your Namecheap dashboard and click Domain List.
• Hit Manage next to your domain.
• Scroll down to the Nameservers section.
• Verify it’s set to either Namecheap BasicDNS or Namecheap PremiumDNS.

If you see custom nameservers pointing to another provider, that’s where you need to manage these TXT records. If you pointed nameservers to a host like Hostinger for web traffic, check my guide on how to point Namecheap DNS to Hostinger without breaking email to keep your mail DNS records centralized.

If you’re on BasicDNS or PremiumDNS, head up to the Advanced DNS tab. That’s where we’ll plug everything in.

Step 1: Create a Single, Consolidated SPF Record

Sender Policy Framework (SPF) tells receiving mail servers which IP addresses and services can send mail on your behalf. It lives as a TXT record on your root domain (@).

The cardinal rule here: never add more than one SPF record. The official spec (RFC 7208) explicitly forbids multiple SPF records. The moment a receiving server sees two v=spf1 entries, it throws a PermError and fails authentication immediately.

Take a look at your current records in Namecheap. If there’s already a TXT record starting with v=spf1, don’t click “Add New Record” to add another one. Merge them.

Here’s what a merged record looks like if you run Google Workspace for day-to-day email and Postmark for transactional alerts:

Type: TXT Record
Host: @
Value: v=spf1 include:_spf.google.com include:spf.mtasv.net ~all
TTL: Automatic

If you’re using Namecheap’s own Private Email, your SPF string will look different. For manual setups involving their email infrastructure, check our walkthrough on how to manually configure Namecheap Private Email MX and SRV records.

Breaking down the syntax:

• v=spf1: Identifies the record as SPF version 1.
• include:...: Whitelists a third-party sending service.
• ~all: Soft fail. Mail from unauthorized IPs usually lands in spam rather than bouncing outright. Use this while testing.
• -all: Hard fail. Unauthorized mail gets dropped at the edge. Switch to this once you know all senders are accounted for.

In Namecheap, set Type to TXT Record, Host to @, paste your merged string into Value, leave TTL on Automatic, and save it with the green checkmark.

Step 2: Add Your DKIM Records Without Host Field Errors

DomainKeys Identified Mail (DKIM) attaches a cryptographic signature to every outgoing email header. The receiving mail server grabs your public key from DNS to verify the message wasn’t tampered with in transit.

Your mail provider (Google Workspace, Postmark, SES, etc.) generates the key pair. They’ll hand you two values: a Selector and a Value (the public key string).

Here’s the Namecheap trap that catches almost everyone: Namecheap automatically appends your domain name to whatever you put in the Host field. If your provider tells you your DKIM host is google._domainkey.example.com, and you paste that entire thing into Namecheap, it actually saves as google._domainkey.example.com.example.com. Your DKIM validation will silently fail for weeks without warning.

Always strip your apex domain out of the Host input. Only enter the selector prefix.

Type: TXT Record
Host: google._domainkey
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0...[rest of public key]...
TTL: Automatic

Some providers (like AWS SES or SendGrid) use CNAME-based DKIM instead of raw TXT records. The same naming rule applies—strip the domain:

Type: CNAME Record
Host: s1._domainkey
Value: s1._domainkey.u1234567.wl.sendgrid.net.
TTL: Automatic

Add the record under Advanced DNS and hit the checkmark. If you send through multiple providers, add a separate DKIM record for each one under its own selector.

Step 3: Implement DMARC with a Safe Rollout Policy

DMARC ties SPF and DKIM together. It tells receiving servers what to do when an email claiming to come from your domain fails both checks.

According to Google’s Email Sender Guidelines, anyone sending to Gmail needs DMARC enabled. Period.

Don’t jump straight to a strict drop policy. If you immediately configure p=reject without checking reports first, you’ll probably kill legitimate transactional emails from your billing system or support desk.

Start with this passive monitoring DMARC record:

Type: TXT Record
Host: _dmarc
Value: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; pct=100; sp=none
TTL: Automatic

Notice the host name is just _dmarc. Don’t write _dmarc.example.com, or Namecheap will double your domain again. Swap dmarc-reports@example.com for a mailbox you can filter, or use an aggregate reporting tool like Postmark DMARC or Valimail.

What these flags mean:

• v=DMARC1: Protocol version identifier.
• p=none: Monitoring mode. Nothing gets blocked or sent to spam on DMARC failure yet.
• rua=mailto:...: Where daily aggregate XML reports get delivered.
• pct=100: Applies the policy to 100% of outbound messages.
• sp=none: Sets subdomains to the same policy.

Run this for two to three weeks. Read the reports, ensure every legit sender passes, then bump p=none to p=quarantine (sends unaligned mail to spam). After another clean testing window, lock it down with p=reject.

Verify Your Records with the Command Line

Don’t rely on web UI checkers to tell you if your DNS is ready. Web checkers cache old queries and give you false comfort. Use dig in your terminal to see exactly what public resolvers return.

Query your SPF record:

dig TXT example.com +short

You should see your single SPF record along with any site verifications you’ve got on the root:

"v=spf1 include:_spf.google.com include:spf.mtasv.net ~all"

Query your DKIM selector (replace google with your provider’s selector):

dig TXT google._domainkey.example.com +short

Query your DMARC record:

dig TXT _dmarc.example.com +short

The answer section should spit out your exact policy:

"v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com; pct=100; sp=none"

If you get empty results or stale records, check Namecheap’s authoritative server directly. Grab the nameserver with dig NS example.com, then query it straight:

dig @dns1.registrar-servers.com TXT _dmarc.example.com +short

If Namecheap’s nameserver returns your new record, your configuration is good. You’re just waiting on local ISP caching to expire, which usually takes 15 to 30 minutes.

The Gotcha That Bit Me: Multi-Service SPF PermErrors

Here’s a mess I had to untangle on a client migration that cost me two hours of head-scratching. The client had an existing site on shared hosting, Google Workspace for team mail, and Mailgun handling app receipts.

Someone had added two separate SPF records in Namecheap:

; Record 1
Type: TXT
Host: @
Value: v=spf1 include:_spf.google.com ~all ; Record 2
Type: TXT
Host: @
Value: v=spf1 include:mailgun.org ~all

When emails arrived at Gmail, Google saw two distinct SPF strings. Per the RFC spec, a parser can’t guess between multiple records, so it throws spf=permerror. Because our DMARC policy required SPF alignment, DMARC failed too.

To make things trickier, SPF enforces a hard ceiling of 10 DNS lookups per evaluation. Every include: statement burns at least one lookup under the hood. Chain too many services together and you blow past that limit, hitting another PermError.

The fix is straightforward:

1. Delete the extra TXT record so only one v=spf1 remains.
2. Combine your includes into that single record, keeping lookups under 10:

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

You can check your lookup count using dmarcian’s SPF Survey tool before pushing the record live.

Testing End-to-End Email Delivery

Once terminal lookups look right, test real delivery. The simplest way without third-party tools is sending a test email to a personal Gmail account.

1. Send an email from your domain to Gmail.
2. Open the message in Gmail webmail.
3. Click the three dots next to the “Reply” button.
4. Select Show original.

Look at the summary box at the top. You want clean passes across the board:

SPF: PASS with IP 209.85.220.41
DKIM: 'PASS' with domain example.com
DMARC: 'PASS'

If DKIM shows FAIL, double-check that the selector configured on your outbound mail server matches what you put in Namecheap’s Host field. If you use aliases or forwarding, read our walkthrough on free email forwarding in Namecheap DNS routed to Gmail to see how headers behave when forwarding messages.

Frequently Asked Questions

Can I use both Namecheap email forwarding and Google Workspace SPF records?

Yes. If you forward addresses through Namecheap while sending via Google, merge them into one line: v=spf1 include:spf.efwd.registrar-servers.com include:_spf.google.com ~all. Keep both includes inside that single record.

Why does my 2048-bit DKIM key fail to save in Namecheap?

A single DNS TXT record string can’t exceed 255 characters without splitting. Namecheap handles this behind the scenes. Paste the entire 2048-bit string directly into the Value field without adding manual quotes or spaces—Namecheap splits the chunks automatically.

What should I do if my domain sends zero outbound emails?

If you own an apex domain that only runs a landing page and never sends mail, lock it down so spammers can’t spoof it. Add a null SPF record (v=spf1 -all) and a drop DMARC record (v=DMARC1; p=reject). That signals to mail servers that anything claiming to come from that domain is fake.

How long do DNS updates take in Namecheap Advanced DNS?

Namecheap sets default TTLs for TXT records to 30 minutes, though you can drop this to 1 minute while testing. In practice, Namecheap’s nameservers answer with updated records within 60 to 180 seconds, but local ISP resolvers can cache old answers for up to half an hour.

Next Steps

With SPF, DKIM, and DMARC working together, your mail won’t get flagged for spoofing. Keep your DMARC policy at p=none for a couple of weeks to surface any stray sending services you might have forgotten about (like Zendesk or an old cron job). Once reports look clear, step it up to p=quarantine, and finally p=reject.

If you’re hosting web services on the same root domain, make sure those records don’t clash with your mail setup. Check out our guide on how to point an apex domain to a CNAME in Namecheap DNS with ALIAS records to keep your root records organized without breaking your authentication TXT records.