How to add DMARC, SPF and DKIM records on Namecheap

11 June 2026 · 14 min read

Namecheap is one of the most common places small businesses and side projects keep a domain, and its DNS editor is friendly enough that you can add DMARC, SPF and DKIM records without touching a command line. It is also full of small surface-level quirks that trip people up: the @ host versus a blank field, the way Namecheap auto-appends your domain to host names, the 255-character limit on a single TXT string, and the difference between editing records on Namecheap BasicDNS versus pointing your nameservers somewhere else entirely. This guide walks through every record type, the exact values to type into the Namecheap Advanced DNS tab, and the gotchas that cause "I added the record but the checker still says it is missing".

It assumes your domain's nameservers are Namecheap's own (BasicDNS or PremiumDNS). If you have moved nameservers to Cloudflare, Google Cloud DNS or another host, the Namecheap DNS editor will not be authoritative and your changes there will do nothing. We cover how to tell the difference below.

First, confirm Namecheap is actually your DNS host

This is the single biggest reason Namecheap edits "don't work". Owning a domain at Namecheap and using Namecheap for DNS are two separate things.

1. Sign in to Namecheap and open Domain List from the left sidebar.
2. Click Manage next to your domain.
3. Look at the Nameservers panel on the Domain tab.

If it says Namecheap BasicDNS or Namecheap PremiumDNS, you are in the right place and the Advanced DNS tab controls your live records. If instead you see Custom DNS with entries like cloudflare.com or awsdns, then your records live at that other provider and editing the Advanced DNS tab here changes nothing. In that case, add your records at whoever the nameservers point to.

You can also check from the outside. Run your domain through the DMARC checker or the SPF checker; both resolve records the way the rest of the internet sees them, so they reflect your authoritative DNS regardless of which dashboard you are clicking around in. If a record you "added" never shows up in those tools after the TTL window, you are almost always editing the wrong DNS host.

Once you have confirmed Namecheap BasicDNS or PremiumDNS, open the Advanced DNS tab. Everything below happens in the Host Records section, using the Add New Record button.

How the Namecheap host field actually behaves

Namecheap's Host field is the part of the DNS editor people misread most often, so it is worth understanding before you add a single record.

• @ means the root of your domain (also called the apex or naked domain). For example.com, a TXT record on host @ is published at example.com itself.
• A subdomain label is just the label, never the full name. To publish at _dmarc.example.com, the host is _dmarc, not _dmarc.example.com. Namecheap automatically appends your domain to whatever you type.
• Do not include a trailing dot and do not type your domain twice. If you enter _dmarc.example.com as the host, Namecheap stores it as _dmarc.example.com.example.com, which is wrong and invisible to mail receivers.

That auto-append behaviour is the root cause of a huge share of broken DMARC and DKIM records on Namecheap. Whenever a guide elsewhere says "create a record at selector._domainkey.example.com", on Namecheap you type only selector._domainkey into the Host field.

The TTL column controls how long resolvers cache the record. Namecheap's default is Automatic (about 30 minutes). Lower values such as 5 min are useful while you are actively changing records, because they shorten the wait before a fix propagates. Set it back to Automatic once the record is stable. TTL has no effect on whether a record is correct; it only affects how quickly changes are seen.

Adding the SPF record (TXT)

SPF (Sender Policy Framework) lists which servers are allowed to send mail using your domain in the envelope sender. It is published as a single TXT record at the root of your domain.

In Namecheap, click Add New Record and choose TXT Record:

• Type: TXT Record
• Host: @
• Value: your SPF policy, for example:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all

• TTL: Automatic

The exact include: mechanisms depend on who sends your mail. The example above authorises Google Workspace and Microsoft 365. A domain that sends through Mailchimp and a transactional provider might instead look like:

v=spf1 include:servers.mcsv.net include:sendgrid.net ~all

Three SPF rules that matter on Namecheap and everywhere else:

1. One SPF record per domain, full stop. You must not publish two separate v=spf1 TXT records at @. If you do, SPF returns a permerror and validation fails for every sender. When you add a new platform, edit the existing SPF value and append another include:; do not create a second TXT record. Our guides for individual senders, such as email authentication for Mailchimp and email authentication for SendGrid, show the right include for each platform.
2. Stay under ten DNS lookups. Every include:, a, mx, ptr and exists mechanism costs a lookup, and nested includes count too. Exceed ten and SPF hits permerror. The SPF checker counts your lookups for you and tells you which include is expensive.
3. Prefer ~all (softfail) while you are still validating, then consider -all (hardfail) once DMARC reporting confirms every legitimate source passes. Do not jump straight to -all before you have proven your sending sources, or you risk legitimate mail being rejected.

If your SPF is already near the ten-lookup ceiling, flattening it into a single static record can buy headroom. That is a maintenance trade-off because flattened SPF needs re-checking when providers change their IP ranges. Our hosted SPF product handles the flattening and keeps it current automatically.

Adding DKIM records (usually CNAME, sometimes TXT)

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to your outbound mail so receivers can verify it was not altered and genuinely came from a server holding your private key. The public key half lives in DNS under a selector.

A DKIM record lives at selector._domainkey.yourdomain. The selector is a label chosen by your sending platform, for example google, s1, k1, dkim, or a random string like r7a2._domainkey. Your provider tells you both the selector and the value.

There are two formats you will encounter, and Namecheap handles them differently.

CNAME-style DKIM (the most common case today)

Many platforms (Google Workspace via some setups, Microsoft 365, Mailchimp, Klaviyo, Amazon SES, SendGrid, and most marketing tools) give you CNAME records that delegate the DKIM key back to their own DNS. This is the friendliest case on Namecheap because there is no long key to paste and the provider rotates the key for you.

A provider might give you something like:

Host:   s1._domainkey
Points to: s1.domainkey.u1234567.wl.sendgrid.net

In Namecheap:

• Type: CNAME Record
• Host: s1._domainkey (label only, no domain appended)
• Value / Target: s1.domainkey.u1234567.wl.sendgrid.net
• TTL: Automatic

Two Namecheap-specific gotchas with CNAME DKIM:

• Strip the trailing dot from the target if you copy it from documentation. Some providers print the target as ...sendgrid.net. with a dot. Namecheap's CNAME value field expects the hostname without the trailing dot; paste s1.domainkey.u1234567.wl.sendgrid.net and nothing more.
• You usually get two or three CNAMEs, not one. SendGrid and others issue multiple selectors plus a separate link/tracking CNAME. Add each one as its own record. Microsoft 365 issues two: selector1._domainkey and selector2._domainkey. Add both, or DKIM key rotation will eventually break.

A note on CNAME flattening: Namecheap does not flatten CNAMEs, and that is fine here. Flattening matters at the root of a domain where a CNAME is not allowed by the DNS standard. DKIM CNAMEs sit on a subdomain label like s1._domainkey, so the apex restriction never applies. You do not need a flattening feature for DKIM on Namecheap. (Where the apex CNAME problem does bite is if a platform asks you to point your root domain at a hostname; that is a different topic from DKIM.)

TXT-style DKIM (raw public key)

Some providers, and self-hosted mail servers, hand you the public key directly as a TXT record. It looks like this, often very long:

Host:  default._domainkey
Value: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7Vd6...long base64...QIDAQAB

In Namecheap:

• Type: TXT Record
• Host: default._domainkey
• Value: the whole v=DKIM1; ... string
• TTL: Automatic

This is where the 255-character chunking issue appears, covered in detail in the next section, because a 2048-bit DKIM key is longer than a single DNS string can hold.

Whichever format you used, verify the result with the DKIM checker. You give it your domain and the selector, and it fetches the published key and confirms it parses. A DKIM record that is present but malformed (a missing p=, a stray space, a truncated key) fails silently, so checking after you publish is not optional.

The TXT chunking gotcha (and how Namecheap handles it)

A single DNS TXT string can hold at most 255 characters. A 2048-bit DKIM public key, and occasionally a long SPF or DMARC value, exceeds that. The DNS standard solves this by allowing one TXT record to contain multiple quoted strings that resolvers concatenate back together. In raw zone-file syntax it looks like:

default._domainkey IN TXT ( "v=DKIM1; k=rsa; p=MIGfMA0GCS...first 255 chars..."
                            "...remaining base64...QIDAQAB" )

Here is the Namecheap-specific good news and the trap:

• The good news: Namecheap's web editor lets you paste a value longer than 255 characters into the Value box, and Namecheap splits it into 255-character chunks for you behind the scenes. You generally do not manually add quotes or break the key yourself. Paste the full key, including v=DKIM1; k=rsa; p=, as one continuous string.
• The trap: Do not paste the value with quote marks or line breaks already in it. If you copied the multi-line zone-file version above, with literal " characters and a newline in the middle, Namecheap will store those quotes and newlines as part of the value and the key will not parse. Strip it back to one clean unbroken string with no surrounding quotes, then paste.
• The other trap: Watch for invisible whitespace. Copying a key from a PDF or a styled web page sometimes drags in a stray space or a non-breaking space mid-key. The base64 in p= must be contiguous. If the DKIM checker reports the key does not validate even though it "looks right", suspect a hidden character and re-paste from a plain-text source.

If you ever do need to hand-chunk a value, the rule is simple: break it into pieces of at most 255 characters, wrap each piece in double quotes, and put them one after another with no commas. But on Namecheap BasicDNS this is rarely necessary because the editor does it for you.

Adding the DMARC record (TXT)

DMARC ties SPF and DKIM together with a policy and, crucially for ongoing monitoring, a reporting address. It is a TXT record published at the fixed subdomain _dmarc.

In Namecheap, Add New Record, choose TXT Record:

• Type: TXT Record
• Host: _dmarc
• Value: start in monitor-only mode, for example:

v=DMARC1; p=none; rua=mailto:reports@yourdomain.example; fo=1; adkim=r; aspf=r

• TTL: Automatic

Breaking that down:

• p=none means "do not change how my mail is treated, just observe and send me reports". This is where every domain should start. It is safe: it cannot cause a single legitimate message to be quarantined or rejected.
• rua=mailto:... is the address that receives the daily aggregate XML reports. Without it, you publish a policy but learn nothing, which defeats the purpose of starting at p=none. Point it at an inbox you actually monitor, or at a reporting service that parses the XML for you.
• fo=1 asks receivers to send failure samples when either SPF or DKIM fails, useful for diagnosis.
• adkim=r and aspf=r set relaxed alignment, which is the sensible default for most setups.

The most common Namecheap mistake here is, again, the Host field. People type _dmarc.yourdomain.com and Namecheap stores _dmarc.yourdomain.com.yourdomain.com. The DMARC record then does not exist at _dmarc.yourdomain.com and every checker reports it missing. The host is exactly _dmarc, nothing more.

Confirm with the DMARC checker. It parses your published policy, flags syntax errors, and tells you whether your rua is set so reports will actually flow. If you want a policy generated for you with the right tags, the DMARC record generator builds a valid string you can paste straight into the Namecheap Value box.

From p=none to p=reject without breaking mail

Publishing p=none is the start, not the finish. The point of DMARC is to reach an enforcement policy (p=quarantine or p=reject) so that nobody can spoof your domain. But you only move there once the aggregate reports prove that every legitimate sender is aligned under SPF or DKIM. Move too early and you bin your own invoices and newsletters.

The honest, low-risk sequence on Namecheap looks like this:

1. Publish p=none with a working rua. Collect at least a week or two of aggregate reports so you see your full sending picture, including the marketing tool someone set up two years ago that you forgot about.
2. Read the reports. Each XML file lists sending IPs and whether they passed SPF and DKIM alignment. Anything legitimate that fails needs its SPF include or DKIM selector fixed at the source. The DMARC report analyzer turns those XML files into a readable list of who is sending and what is failing, which is far quicker than reading raw XML by hand.
3. Fix each failing legitimate source by adding its SPF include (one record, remember) and its DKIM CNAME or key.
4. Tighten the policy in stages: p=none, then p=quarantine; pct=25, ramping the percentage up, then p=quarantine at full, and finally p=reject. Each step is a single edit to the DMARC TXT value in Namecheap's Advanced DNS tab.

Updating the policy is just editing that one _dmarc TXT record and changing p=none to p=quarantine or p=reject. You never need a new record; you edit the existing value. Because TTLs are short, a change is live within minutes, which makes it easy to step back to a looser policy if a report surprises you.

This staged ramp, the report reading, and the "did I just break something" anxiety are exactly what our done-for-you service removes. We host your DMARC, SPF, DKIM, MTA-STS and BIMI, watch the reports, and only advance the policy when the data says it is safe. See the DMARC product page for how the managed path differs from doing it by hand on Namecheap.

The two records people forget: MTA-STS and BIMI

If you are already in the Namecheap DNS editor, two related records are worth knowing about even if you add them later.

• MTA-STS enforces TLS on inbound mail and needs a TXT record at _mta-sts plus a policy file served over HTTPS at mta-sts.yourdomain. The DNS half is a TXT record like v=STSv1; id=20260101000000. Validate the whole setup, DNS and policy file together, with the MTA-STS checker.
• BIMI displays your logo next to authenticated mail, but only after you reach p=quarantine or p=reject. It is a TXT record at default._bimi. There is no point adding it before enforcement, because mailbox providers ignore BIMI on unenforced domains. Check readiness with the BIMI checker.

Both follow the same Namecheap host rules: type only the label (_mta-sts, default._bimi), never the full domain.

Namecheap-specific gotchas, collected in one place

A quick reference for the mistakes that cost the most time on Namecheap specifically:

• Wrong DNS host. Records edited in Advanced DNS do nothing if your nameservers point to Cloudflare or another provider. Check the Nameservers panel first.
• Domain appended twice. Typing _dmarc.example.com into Host produces _dmarc.example.com.example.com. Use the bare label.
• @ versus blank. For root records (SPF, sometimes verification TXTs) the Host is @. Leaving it blank on some forms is ambiguous; use @.
• Duplicate SPF records. Two v=spf1 TXTs at @ cause a permerror. Merge them into one.
• SPF over ten lookups. Counts as permerror even though the record "looks fine". Use the SPF checker to count.
• Quotes and newlines pasted into a TXT value. Namecheap chunks long values automatically; do not paste pre-quoted multi-line zone syntax.
• Trailing dots on CNAME targets. Remove the final dot when pasting a DKIM CNAME target.
• Editing the right host but the wrong account. If you manage several domains, confirm you clicked Manage on the correct one before adding records.
• Impatience with TTL. Changes are not instant. Lower the TTL while testing, wait out the cache window, and re-check from outside rather than trusting the editor view.

Verify, then keep watching

Adding the records is the easy ten minutes. The value is in confirming they are correct and then catching the day six months from now when someone edits the SPF record, a DKIM key rotates, or a new sending tool appears and quietly breaks alignment.

After you save your records in Namecheap, run the trio of free checks: DMARC checker, SPF checker and DKIM checker. They read your live, authoritative DNS, so they are the honest answer to "did it work", not the Namecheap dashboard view. If you are unsure which records your specific senders require, our per-platform walkthroughs, like email authentication for Mailchimp, SendGrid and Amazon SES, list the exact records to add on Namecheap for each.

The practical takeaway: confirm Namecheap is your real DNS host, type bare labels into the Host field (@, _dmarc, selector._domainkey), keep SPF to a single record under ten lookups, let Namecheap chunk long DKIM keys for you, and start DMARC at p=none with a working rua before tightening towards p=reject. Then turn on continuous monitoring so a future DNS change does not silently undo all of it.

If you would rather not babysit the ramp or watch the reports yourself, set up emailed monitoring with change alerts so you hear about a broken record the moment it happens, or hand the whole thing to our done-for-you hosted service and let us take your Namecheap domain from p=none to p=reject without an email outage.