Name.com SPF, DKIM and DMARC setup, step by step

No customer account, DNS change or message test was performed.

In an authoritative Name.com zone, open MY DOMAINS, select the domain and choose Manage DNS Records. Publish the exact TXT or CNAME records supplied by your sending service, then verify DNS and a real message separately. Name.com registration or DNS hosting does not itself enable that sender's DKIM signing.

This guide covers DNS publication. It does not configure a Name.com mailbox, cPanel signing, a third-party mail account, API integration or nameserver migration. If you need sender-side setup, obtain the current instructions for your actual sending product and account before proceeding.

Confirm authority and prepare the change

Name.com's TXT documentation requires its nameservers for its DNS editor to control public answers. Check public delegation and the DNS administrator's zone inventory, not just where the domain was purchased. A parent domain and a delegated child can use different DNS operators.

If another service is authoritative, edit there. Do not make parallel changes in an inactive Name.com zone or move nameservers merely to match these instructions. Keep MX, DNSSEC, parent NS, forwarding, credentials and existing website records unchanged unless a separate approved plan requires them.

Create a worksheet containing:

• Account owner, selected zone, authoritative servers and change approver.
• Actual sending service, product, region, visible From domain and envelope identity.
• Issued full DNS owners, types and complete public values for that account.
• Existing records, TTLs, legitimate senders, DKIM selectors and direct or inherited DMARC policy.
• Approved replacement, rollback owner and controlled-message test plan.

Ask the sender for all issued selectors and any signing-activation requirement. Do not use another tenant's key, invent a target from a pattern, or assume that DNS ownership verification turns on signing. If an issued packet includes A, MX, NS or forwarding changes, compare their destinations and consequences with the approved routing plan before accepting them.

Add a TXT record in the Name.com editor

The TXT instructions, show:

1. Sign in and open MY DOMAINS.
2. Select the domain, then Manage DNS Records.
3. Select TXT in Type.
4. Enter the relative owner in Host and the complete value in Answer.
5. The documented default TTL is 300 seconds. Use the approved TTL for the change.
6. For a new, nonconflicting record, select Add Record.

The SPF article, uses this same TXT workflow. Its linked SPF_record.png screenshot shows an empty Host field with the selected domain displayed underneath. Thus, for an apex TXT owner in this documented editor, leave Host empty. Do not copy the screenshot's example SPF value.

When a policy already exists, do not use Add Record to create a second one. The current add-record articles do not document the complete existing-record editing workflow. Confirm the correct update control in your account or with Name.com support before replacing an existing policy. Stop if you cannot establish that the operation updates the intended record rather than adding a duplicate; do not delete working mail policy simply to bypass that uncertainty.

Translate full owners into Host fields

Name.com's screenshots display the selected domain suffix outside the Host input. Enter the relative part, not the same domain twice. These examples explain DNS ownership, not account-issued selector values:

Replace selector and the example domains with actual approved values. For delegated child zones or _domainkey namespaces, use the editor at the child authority and its naming rules. These rows do not claim that your Name.com account has a child-zone hosting feature. Parent-zone data below a delegation does not override the child's authoritative answers. Preserve shared NS delegations rather than removing them to make an individual selector work.

Inspect the resulting full owner after saving. An answer at selector._domainkey.example.com.example.com is not the requested answer at selector._domainkey.example.com.

Publish SPF without breaking other senders

There is no universal SPF include to add merely because Name.com hosts DNS. Obtain the actual sender's approved record and determine the domain SPF evaluates: SMTP MAIL FROM, or HELO in applicable cases, not automatically the visible From address. A provider-controlled bounce domain may be outside your DNS authority. Do not invent a custom envelope configuration or move the sender's documented record by guessing.

Maintain one v=spf1 TXT policy at each evaluated owner. Inventory and preserve other legitimate sender permissions and existing qualifiers. Unrelated TXT verification records can coexist. Do not concatenate two complete SPF policies; incorporate approved mechanisms into the reviewed policy before all. A redirect is ignored whenever an all mechanism is present.

The limit is ten evaluated DNS-dependent terms across the evaluation, including nested dependencies, not ten visible includes. include, a, mx, ptr, exists and redirect consume the budget; ip4, ip6 and all do not. Review the resulting evaluation before saving. Qualifiers do not guarantee inbox placement or rejection. See RFC 7208 and EmailAuth's multiple-SPF-record repair guide.

Publish the sender's complete DKIM packet

DKIM records come from the sending service, not the DNS record type selector. Keep all issued public-key tags, the entire key, selector and signing domain intact. Do not publish private keys. Complete any sender verification or signing activation after DNS publication.

For a TXT packet, paste the complete public value into Answer. A lookup can display one TXT resource record as several quoted character strings. For example:

Illustrative single TXT resource record, not a usable key:
"v=DKIM1; k=rsa; " "p=ABCD"
Reconstructed text:
v=DKIM1; k=rsa; p=ABCD

The strings in that one record concatenate without an inserted separator. This is not permission to publish separate TXT records as key fragments. Name.com's current TXT article does not document manual long-value chunking. If the editor refuses or truncates the full value, stop and get its supported entry method; never shorten the key. Compare the authoritative reconstructed value with the issued data. The selector/domain lookup relationship is defined in RFC 6376.

If the issued type is CNAME

Name.com's CNAME instructions, use MY DOMAINS → selected domain → Manage DNS Records, with Type CNAME, the subdomain in Host, the issued hostname in Answer, TTL and Add Record. Use the actual DKIM owner instead of the article's website example www.

Keep Host nonempty for a CNAME. The same owner must not contain conflicting TXT, A, AAAA, MX or another CNAME. A target is a hostname, not an IP address, https:// URL or path. Investigate collisions with other services before changing anything.

Do not substitute ANAME. Name.com's ANAME reference, describes automatically maintained A/AAAA answers, also called ALIAS or CNAME flattening. Those address answers are not a required literal authentication CNAME. URL forwarding likewise cannot publish a DKIM alias.

The required end state is an observable literal CNAME chain to the issued target. If another authoritative DNS service is involved, keep authentication aliases DNS-only rather than HTTP-proxied. Check per-record, zone-wide, apex and same-zone flattening behavior. Turn off an applicable per-record flatten control where available and ensure applicable zone settings do not hide the alias. Do not make blanket global changes to unrelated records. If mandatory behavior prevents the required answer, coordinate a supported configuration rather than deleting delegations. No undocumented Name.com proxy or global flatten switch is assumed here.

Set DMARC only after the policy decision

Find the policy that applies to the intended visible From domain, including inherited policy. Preserve existing enforcement, alignment settings and authorized report recipients. Do not create a second _dmarc policy, downgrade an existing policy to p=none, or copy a reporting address from an example.

Only if no direct or applicable inherited policy exists, the owner approves monitoring and someone will review reports, this first-policy example can be adapted:

Selected zone: example.com
Full owner: _dmarc.example.com
Type: TXT
Host: _dmarc
Answer: v=DMARC1; p=none; rua=mailto:YOUR_APPROVED_REPORT_MAILBOX
TTL: 300

Replace the domain and replace YOUR_APPROVED_REPORT_MAILBOX with the approved mailbox address only, not another mailto: prefix. p=none requests monitoring, not enforcement. The TTL is the documented editor default, not a global propagation promise.

A reporting destination in a different Organizational Domain requires the report-generating receiver to check DNS authorization; a destination within the same Organizational Domain is excepted. A different hostname alone is not sufficient to classify it as external. See RFC 9990 section 4. Obtain the reporting provider's authorization arrangement and the domain owner's data-sharing approval; these are separate requirements.

Do not tighten policy from a single successful test. RFC 9989 governs alignment and policy; its section 7.4 warns about indirect-mail interoperability. A domain publishing p=reject must not rely solely on SPF and must apply valid DKIM signatures. General-purpose mail and mailing-list use need particular care.

Verify public answers and the actual message

The following commands are examples, not executed tests. Replace all example domains, selectors and the nameserver placeholder with the approved worksheet values. Query the actual envelope owner for SPF and the actual s= plus d= owner for DKIM.

dig NS example.com +short
dig @YOUR_AUTHORITATIVE_NAMESERVER TXT example.com +noall +answer
dig @YOUR_AUTHORITATIVE_NAMESERVER TXT selector._domainkey.example.com +noall +answer
dig @YOUR_AUTHORITATIVE_NAMESERVER CNAME selector._domainkey.example.com +noall +answer
dig @YOUR_AUTHORITATIVE_NAMESERVER TXT _dmarc.example.com +noall +answer

Query each authoritative server and compare the owner, type, complete value and TTL. For CNAME packets, check the exact alias and that its target resolves to the expected public key. Then check recursive answers after relevant positive or negative caches expire. Distinguish NXDOMAIN, no answer and SERVFAIL. A stated twenty-four-hour estimate is not evidence that your records are correct or that every cache has refreshed.

Once the actual sender's activation is complete, send harmless content through the intended production route to a controlled external recipient. Retain the original message, timestamp, message ID, From, Return-Path, connecting IP and every DKIM d=/s= pair. Test separate applications and forwarding paths independently.

Use only results produced within the receiving service's known processing boundary. Confirm from its documentation or administrator how external Authentication-Results are removed or isolated; use receiver logs when header provenance is uncertain. Neither position in the header nor a familiar authserv-id string establishes trust. Ignore attacker-supplied result fields. See RFC 8601 section 7.1.

Accept the newly configured branded DKIM route only when the intended signature passes, its d= aligns with the intended visible From under the actual adkim mode, and the trusted receiver reports dmarc=pass. Strict alignment requires identical domains; relaxed alignment compares Organizational Domains. A child envelope domain does not guarantee strict SPF alignment. SPF-only DMARC pass, a passing unrelated signature or a rewritten provider From does not prove successful branded DKIM configuration.

Inspect SPF independently using the evaluated smtp.mailfrom. Diagnose fail/softfail, transient temperror and policy/dependency permerror separately, even if aligned DKIM yields DMARC pass. DNS resolution alone cannot establish any message-level result.

Troubleshooting and rollback

Do not use Show DNS Templates → Update DNS records as a generic authentication repair. Templates can configure a different service; review their actual records and routing consequences first. No API token, integration grant or security-setting change is required for this manual workflow.

Keep the old record set and an approved rollback plan. Restore only the affected owner after checking concurrent changes, then re-query and retest. DKIM rollback must match the sender's active key; restoring an obsolete public key alone is insufficient. Do not reset the whole zone. If support is needed, supply the domain, record owner/type, timestamps and redacted message evidence, not passwords, API secrets or private keys.