[ DNS-provider guides ]

Publish authentication DNS records in Name.com and verify their owners

Use the authoritative Name.com zone, translate the intended owner correctly, and verify DNS and received mail separately.

By the EmailAuth research team · 5 min read

[ Key points ]

  • Verify the active service and authoritative DNS before editing.
  • Preserve record types, owner names and existing authorized services.
  • Verify public answers and actual aligned mail separately.
On this page
  1. Key points
  2. Takeaway
  3. By role
  4. Frequently asked questions
  5. Sources
  6. Glossary
  7. Related guides

[ Takeaway ]

Verify public answers and actual aligned mail separately.

[ By role ]

What this means for you

Choose your role for practical next steps.

IT / Mail Admin

Keep Name.com DNS configuration evidence reproducible

Separate the DNS values, sender settings and received-message results.

Next steps

  1. Capture previous records and exact account scope.
  2. Compare authoritative answers with the issued worksheet.
  3. Keep the exact route and selector in the evidence record.

CISO / SecOps

Require scoped assurance for Name.com DNS

Documentation alone does not prove the organization’s live mail is authenticated.

Next steps

  1. Retain provider scope and human review gates.
  2. Reject unsupported authentication guarantees.
  3. Review residual risk before removing the release hold.

Founder / Non-technical

Protect the Name.com DNS change window

Avoid turning a single authentication record change into an unnecessary nameserver migration.

Next steps

  1. Name the business owner and pause authority.
  2. Require a controlled acceptance test before broad rollout.
  3. Budget time for the provider and DNS owner to resolve exceptions.

[ FAQs ]

Frequently asked questions

Does registration with Name.com prove it hosts my DNS?

No. Confirm the delegated authoritative nameservers before editing.

Name.com adding TXT records Name.com SPF records SPF RFC 7208 DKIM RFC 6376 DMARC RFC 9989

Where do I add a TXT record?

The documented path is MY DOMAINS, select the domain, then Manage DNS Records, with TXT selected.

Name.com adding TXT records Name.com SPF records SPF RFC 7208 DKIM RFC 6376 DMARC RFC 9989

Which fields contain the host and value?

Use Host for the supplied subdomain or host and Answer for the TXT value.

Name.com adding TXT records Name.com SPF records SPF RFC 7208 DKIM RFC 6376 DMARC RFC 9989

What host represents the root SPF owner?

The accessible TXT/SPF text does not explicitly settle the apex-input convention. Confirm the current interface or provider guidance, then verify the final authoritative owner rather than guessing.

Name.com adding TXT records Name.com SPF records SPF RFC 7208 DKIM RFC 6376 DMARC RFC 9989

Should every DKIM setup use TXT?

No. Use the type issued by the signing service. A provider can require CNAME delegation rather than a public TXT key.

Name.com adding TXT records Name.com SPF records SPF RFC 7208 DKIM RFC 6376 DMARC RFC 9989

Can I add a second SPF record?

Do not add a competing SPF policy. Merge approved authorization into the single policy at the evaluated name.

Name.com adding TXT records Name.com SPF records SPF RFC 7208 DKIM RFC 6376 DMARC RFC 9989

Does the documented TTL guarantee instant visibility?

No. Authoritative publication and recursive caches must be checked separately; a UI estimate is not a global deadline.

Name.com adding TXT records Name.com SPF records SPF RFC 7208 DKIM RFC 6376 DMARC RFC 9989

What remains untested?

The current account UI, long-value behavior, authoritative before-and-after answers and a controlled received message remain open evidence gates.

Name.com adding TXT records Name.com SPF records SPF RFC 7208 DKIM RFC 6376 DMARC RFC 9989

[ Sources ]

Sources

  1. Name.com adding TXT records

    Sections Nameserver prerequisite19; TXT Host/Answer/TTL22–31

  2. Name.com SPF records

    Sections TXT/Host/Answer19–28; does not explicitly state apex blank convention in accessible prose

  3. SPF RFC 7208

    Sections §3.2; 3.3; 4.6.4

  4. DKIM RFC 6376

    Sections §3.5; 3.6.2; 6.1

  5. DMARC RFC 9989

    Sections §4.4; 4.7; 4.10; 5

[ Glossary ]

Glossary

Authoritative DNS
The servers responsible for publishing the domain’s DNS data.
Envelope domain
The SMTP sender domain evaluated by SPF.
DKIM selector
The label identifying a public key under the signing domain.
Alignment
The required relationship between the visible From domain and a passing authentication identity.

Enterprise provenance

Why top financial institutions and governments retired their email security dashboards.

Traditional email authentication platforms sell you a dashboard and ask your engineers to do the labour. In high-stakes environments, manual oversight means delayed enforcement, configuration drift and unmonitored shadow domains.

EmailAuth is the agentic email provenance platform. Our agents enforce p=reject, keep third-party senders aligned and move your domains to full RFC 9989 compliance, the new DMARC standard,, with human-in-the-loop auditability.

Governments Large enterprises Tier-1 financial institutions

SaaS · Dedicated tenancy · Air-gapped on-prem · BYOK encryption

Knowledge Base