Publish email-authentication records in Namecheap Advanced DNS only when the domain uses BasicDNS, PremiumDNS or FreeDNS. Private Email uses include:spf.privateemail.com for SPF and a subscription-specific DKIM TXT value. Its DKIM owner is privateemail._domainkey for newer subscriptions, or default._domainkey for subscriptions purchased before 2 June 2026. Always copy the complete record from the actual subscription. Namecheap DNS publication, Private Email DNS and Private Email DKIM
Namecheap can be your registrar, DNS host, mailbox provider, or several of these. This guide explains where to publish records and includes the Private Email branch. It does not treat cPanel mail, a website's local mail function or a third-party marketing service as Private Email simply because the domain is registered at Namecheap.
Choose the correct DNS editor and mail product
Before changing anything, check the domain's delegated nameservers and the outgoing server used by each application. Use this decision table:
| Situation | Where records belong | Where authentication values come from |
|---|---|---|
| BasicDNS, PremiumDNS or FreeDNS | Namecheap account, Domain List → Manage → Advanced DNS | The actual sending service |
| Namecheap Web Hosting DNS | Hosting cPanel DNS editor | Private Email subscription if it sends the mail; hosting mail configuration if cPanel sends it |
| Custom or third-party nameservers | That provider's authoritative DNS | The actual sending service |
| Domain merely registered at Namecheap | Determine the active DNS host first | Registration does not supply a sending authorization |
These DNS-host branches are documented by Namecheap. Do not switch nameservers to reveal an editor. That can affect the website and incoming mail as well as authentication.
If a form sends through a third-party relay, configure that relay. If it submits through a Private Email mailbox, validate that exact SMTP route. Keep domain aliases and subdomains on the worksheet rather than assuming the primary address's result covers them.
Record the existing configuration
Save a copy of the current DNS entries and the approved change. Include full owners, types, values, TTLs and the person who can restore each record. Preserve MX records, website records, unrelated verification tokens, all legitimate SPF authorizations and other services' DKIM selectors.
Private Email's automated setup under Mail Settings → Private Email configures service records. Its manual setup includes MX entries as well as authentication. Neither workflow should be used casually to repair one TXT record on a domain with working mail elsewhere. Namecheap distinguishes automated setup for Private Email alone from manual setup for multiple mail services or subdomain MX records. Private Email setup choices
For an authentication-only repair, make a bounded change to the intended record. If the account offers a bulk or automated action, inspect its proposed effects before continuing. A copied setup example is not permission to migrate inbound mail.
Publish records without duplicating the domain name
On BasicDNS, PremiumDNS or FreeDNS:
- Open Domain List, then Manage for the domain.
- Open Advanced DNS and the Host Records section.
- Edit the existing policy when appropriate, or choose Add New Record for a new owner.
- Select the record type supplied by the sender. SPF and DMARC are TXT; DKIM may be TXT or CNAME depending on the sending service.
- Enter the relative Host, complete Value and appropriate TTL, then Save all changes.
Namecheap's Host field appends the domain. Within the example.com zone, enter @ for example.com, privateemail._domainkey for privateemail._domainkey.example.com, and _dmarc for _dmarc.example.com. For a record at _dmarc.news.example.com, enter _dmarc.news. Do not enter the full domain into a field expecting the relative label. Namecheap host-field requirements
A sender's request for a CNAME should stay a CNAME. Do not paste its target into a TXT field because another tutorial uses TXT for DKIM. A CNAME owner cannot also hold a conflicting TXT or another service's record. Resolve the collision or use a provider-supported alternative selector; do not delete the old sender's working key blindly.
For an issued signing domain such as news.example.com, a full owner SELECTOR._domainkey.news.example.com is SELECTOR._domainkey.news relative to the parent example.com zone, or SELECTOR._domainkey in a separately delegated news.example.com zone. If _domainkey.news.example.com itself is delegated, the relative owner there is SELECTOR. Replace the selector placeholder with the issued value, preserve the account’s exact type and public value, and publish at the actual authority without removing the NS delegation. This example explains name placement, not automatic product eligibility for a new domain. DKIM owner construction, relative DNS names.
For authentication records that actually use CNAME, retain a literal CNAME answer to the issued target and use DNS-only rather than HTTP proxying. Turn the relevant per-record Flatten setting off where available, and ensure applicable whole-zone settings do not suppress the alias. On Cloudflare, flatten-all cannot be overridden per record; apex CNAMEs are flattened by default, and same-zone targets are flattened regardless of that setting. These are DNS-host behaviors, not assumed controls in the sending application. If mandatory behavior or shared settings cannot preserve the required CNAME answer, stop and coordinate a supported layout without breaking other services or removing shared NS delegations. Do not blindly disable features across the whole zone. Cloudflare verification guidance, flattening controls and limits.
Configure Private Email SPF without dropping other senders
Namecheap's Private Email DNS guide specifies this TXT value at the domain root for a Private Email-only configuration:
v=spf1 include:spf.privateemail.com ~all
If an SPF policy already exists, add the necessary authorization to that policy, before its terminal all, while retaining other legitimate senders. Do not create one SPF policy for cPanel and a second for Private Email at the same owner. Do not replace a multi-service policy with the example above. Official SPF value and consolidation guidance
If an existing SPF policy uses redirect=, preserve its intended authorizations and final semantics through a reviewed merge. Any all mechanism causes redirect to be ignored, so appending a canned policy or an all without reviewing that dependency can change which senders are authorized. SPF redirect semantics.
Keep the established qualifier unless its owner has approved a policy change. The documented ~all produces softfail for an unmatched sender; it is not the same as an authorization pass. Inspect nested includes and other lookup-causing terms against SPF's ten-term evaluation limit. Duplicate policies, syntax errors and over-budget evaluation can cause permerror; authorizing everybody with +all is not a safe fix. SPF specification
SPF checks the SMTP MAIL FROM identity. The visible From address alone does not tell you which domain was checked. Query the domain reported as smtp.mailfrom on a received message, and separately compare it with the visible From for DMARC alignment. Do not promise that every Private Email route always uses an aligned return path, or omit the official SPF authorization because an unrelated provider-domain path happened to pass once.
Obtain and publish the correct Private Email DKIM record
Open Private Email → Manage beside the subscription. Use Show DKIM to retrieve an existing record; if no record exists, follow the available Generate workflow. Copy the complete DNS Record value, not only the displayed beginning of the public key. The current documentation says the record is unique to the subscription and available on ordering. Do not generate an unrelated key using an external tool. Private Email key workflow
Check the subscription cohort and the actual account display:
| Subscription | Documented TXT Host in the parent zone |
|---|---|
| Purchased on or after 2 June 2026 | privateemail._domainkey |
| Purchased before 2 June 2026 | default._domainkey |
The value is account-specific. There is no shared public key to paste from this article. Preserve the entire string beginning with v=DKIM1, including its complete p= value. The official DKIM instructions contain both selector names; older tutorials showing only default are insufficient for newer subscriptions.
BasicDNS can create the record automatically during generation. Inspect DNS before adding a duplicate. PremiumDNS needs manual publication; Web Hosting DNS uses cPanel, and third-party DNS uses its own editor. The same documentation also describes manual publication when copying an existing record, so check what actually exists rather than relying on an automation assumption.
The documented workflow is generation or retrieval followed by publication and verification. Do not invent a separate Start Signing switch. If a fresh message remains unsigned after DNS is correct, ask Private Email support to confirm signing for the subscription and route. A record displayed in the account is not evidence that outgoing messages already use it.
Long TXT values may be represented as several quoted strings within one DNS record. Receivers concatenate those strings. Publishing each piece as a separate TXT record at the same selector is not equivalent. Never truncate the key, add unexplained whitespace inside it or publish a private key. DKIM TXT representation
Retain the intended DMARC policy and reporting destination
First inspect _dmarc at the visible From domain and any applicable parent policy. Leave an established quarantine or reject policy, alignment mode and reporting destination intact unless the domain owner approves a specific change. A missing child-domain record does not establish that the child has no DMARC protection. DMARC policy discovery
For a first monitored rollout only, with no existing applicable policy, the owner can approve a value such as:
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
This uses example.com illustratively. Replace the report address with a working, authorized mailbox or your reporting service's exact destination. The full owner _dmarc.example.com maps to Host _dmarc in the example.com zone. For a deliberately separate policy at news.example.com, the full owner _dmarc.news.example.com maps to _dmarc.news in the example.com zone, or to _dmarc in a separately delegated news.example.com zone. Coordinate any child exception with the parent policy owner.
Do not copy a vendor example's reporting tenant, add failure reporting by default or downgrade a policy to obtain a green result. For an external reporting destination, follow its external-authorization instructions. Reports can disclose mail infrastructure and should go only to an approved recipient. Review aggregate reports across all real senders before proposing stronger enforcement. Reporting and external destinations
Compare the Organizational Domain of the aggregate-report URI host with the Organizational Domain of the domain where the DMARC policy was found, not automatically the visible From domain. If they differ, the report-generating receiver must check the destination’s DNS authorization. A destination in the same Organizational Domain as that policy domain is excepted, even when its hostname differs. This protocol check does not replace the domain owner’s separate approval to share report data with that recipient. RFC 9990 section 4.
DMARC needs either aligned SPF pass or aligned DKIM pass. Relaxed alignment uses organizational domains; strict alignment requires exact domain equality. Neither DNS publication nor a generic dkim=pass for an unrelated provider domain establishes that your branded setup is complete.
Validate public DNS before validating delivery
Use these read-only patterns after replacing the uppercase placeholders. Choose the DKIM selector from the actual subscription or delivered signature, not by guesswork.
dig +short NS DNS_ZONE
dig +short TXT MAIL_FROM_DOMAIN
dig +short TXT privateemail._domainkey.SIGNING_DOMAIN
dig +short TXT default._domainkey.SIGNING_DOMAIN
dig +short TXT _dmarc.FROM_DOMAIN
dig @AUTHORITATIVE_NS TXT SELECTOR._domainkey.SIGNING_DOMAIN
The two selector queries are diagnostic alternatives. The intended selector for your subscription must return the complete expected public key; an absent unused selector is not itself a failure. If a separate sending service supplies CNAME DKIM records, query its CNAME and follow the target to the public key instead.
Compare the authoritative answer with a recursive lookup. Confirm one SPF policy at the evaluated owner, the intended DKIM key and exactly the approved DMARC policy. Check inherited policy when no direct record exists. Namecheap estimates roughly 30 minutes for ordinary host records and up to 60 minutes in its DKIM guide. These are estimates, not proof of propagation. A doubled Host suffix or wrong DNS editor requires correction, not more waiting.
Next, an authorized administrator should send through the actual Private Email webmail or SMTP application to a controlled external mailbox. Repeat for critical aliases, subdomains and other senders sharing the SPF policy. Read the receiver's trusted Authentication-Results and retain sanitized results with the timestamp. Interpreting trusted authentication results
Use receiver-controlled diagnostic output, or have the receiving administrator establish which fields were generated inside its known processing boundary and document how externally supplied Authentication-Results are removed or distinguished. A familiar authserv-id string or header position alone does not establish provenance. Ignore attacker-inserted or otherwise untrusted results, including a forged field naming the expected receiver. Operational receiving-boundary requirements.
For acceptance, require:
- DKIM pass for the intended branded
header.d, using the account's active selector, not merely another provider's passing signature. - SPF pass for the intended direct envelope route, or a resolved explanation and correction for its error.
- DMARC pass for the actual visible From under the domain's alignment settings.
- No regression in the other legitimate routes affected by the shared SPF change.
A DMARC pass supplied only by SPF must not conceal missing branded DKIM. Public DNS checks and delivered-message checks answer different questions. Neither proves future inbox placement.
Complete this branded-DKIM setup only when the intended Private Email signature has trusted dkim=pass, its actual d= aligns with the intended visible From under the effective adkim mode, and the trusted receiver reports dmarc=pass for that From. DMARC success through SPF alone does not establish that this DKIM deployment works; neither does an unnoticed provider-domain From rewrite. Diagnose SPF independently at the actual smtp.mailfrom: fail or softfail calls for checking sender authorization, temperror indicates a transient evaluation failure such as DNS availability, and permerror calls for checking invalid syntax, duplicate policies and lookup limits. Investigate these even if aligned DKIM supplies DMARC pass; a passing but unaligned provider envelope is a different outcome. DMARC alignment, SPF result meanings.
Troubleshooting by failure pattern
The record is saved, but public DNS cannot find it
Check the active nameservers, relative Host and exact owner. A Namecheap registration with Custom DNS does not serve records saved in Advanced DNS. Query the authoritative server to separate a publication mistake from a cached older answer.
DKIM is missing or fails after a plan change
Compare the purchased subscription's selector and current public key with the delivered signature. Do not replace default with privateemail solely because a tutorial is newer. Check complete key content, duplicate TXT entries and CNAME conflicts. If the intended key resolves but fresh direct messages lack the branded signature, escalate to the mail provider with sanitized headers.
SPF returns permerror, temperror or softfail
For permerror, inspect duplicate SPF policies, invalid mechanisms and the complete nested lookup path. For temperror, investigate DNS availability and retry after the transient cause clears. For fail, softfail, neutral or none, identify the actual MAIL FROM domain and sending server before adding authorization. A cPanel or separate relay route cannot be diagnosed solely from the Private Email subscription screen.
SPF and DKIM pass but DMARC still fails
Inspect which identities passed. A successful provider-domain signature and unrelated return path may both be unaligned. Repair the intended branded route rather than weakening the domain policy.
Another sender broke after this change
Compare the before-and-after SPF and selector records. Restore the affected value after checking for intervening edits. Avoid restoring the whole DNS zone and undoing someone else's website or verification changes.