[ DNS-provider guides ]

Publish email-authentication records in 123 Reg: configuration and verification

Publish the right TXT or selector record in 123 Reg, then distinguish authoritative DNS success from actual sender authentication.

By the EmailAuth research team · 4 min read

[ Key points ]

  • Publish only at the authoritative DNS service.
  • Preserve the sender’s exact record type and selector owner.
  • DNS publication and sender activation need separate proof.
On this page

[ Takeaway ]

DNS publication and sender activation need separate proof.

[ By role ]

What this means for you

Choose your role for practical next steps.

IT / Mail Admin

Verify the actual route

Keep a before-and-after record set and capture one message from each affected sending application.

Next steps

  1. Compare generated owners against every authoritative server.
  2. Test one message from each affected application after publication.
  3. Retest after a sending-domain or DNS-provider change.

CISO / SecOps

Control the authorization boundary

Approve the precise trust being added and retain a recovery plan for selector or policy conflicts.

Next steps

  1. Reject unplanned nameserver migrations.
  2. Record which active selectors and reporting destinations must be preserved.
  3. Retain the approved recovery and supplier-retirement decisions.

Founder / Non-technical

Own the sending decision

Assign one DNS change owner across all senders so a marketing request cannot silently replace employee-mail authorization.

Next steps

  1. Name the owner of every service sharing the SPF policy.
  2. Approve the specific DNS edits and fallback window.
  3. Require the controlled-message acceptance record before launch.

[ FAQs ]

Frequently asked questions

Does registering my domain with 123 Reg make it the DNS host?

No. Confirm the authoritative nameservers before editing its zone.

123 Reg TXT publishing

Can I paste the example DKIM hostname from the help page?

Use your sending service’s generated selector and complete owner instead. A documentation example is not your configuration.

123 Reg DKIM publishing

Should a DKIM CNAME be entered as TXT?

No. Preserve the sender-specified record type and use the appropriate editor workflow.

123 Reg DKIM publishing

Can I add a second SPF TXT record?

Not at the same SPF owner. Combine legitimate authorizations into one evaluated policy.

Why is a saved record absent from public DNS?

Check authority, the final owner name, delegation and whether the record was actually saved before blaming caches.

Are quotation marks in dig output extra characters?

Not necessarily. DNS tools display TXT strings with quotes; inspect the reconstructed value rather than copying presentation punctuation.

Does publishing DKIM switch on signing?

No. The sending application must sign with the matching private key and selector.

When is the change complete?

When authoritative publication, sender activation and a controlled received-message alignment check all meet the change plan.

[ Sources ]

Sources

  1. 123 Reg TXT publishing

    Sections TXT setup and authoritative nameserver prerequisite

  2. 123 Reg DKIM publishing

    Sections TXT DKIM publishing workflow

  3. RFC 7208 SPF

    Sections §3.2 Multiple DNS Records · §4.6.4 DNS Lookup Limits

  4. RFC 6376 DKIM

    Sections §3.5 The DKIM-Signature Header Field · §3.6 Key Management and Representation · §6 Verifier Actions

  5. RFC 9989 DMARC

    Sections §4.4 Identifier Alignment Explained · §5.3 Mail Receiver Actions

  6. RFC 1034 DNS concepts

    Sections §3.6.2 Aliases and canonical names · §4.2 How the database is divided into zones

  7. RFC 2308 DNS negative caching

    Sections §5 Caching Negative Answers

[ Glossary ]

Glossary

Alignment
The required relationship between a passing authentication domain and the visible From domain for DMARC.
Selector
The DKIM label used with the signing domain to locate its public key in DNS.
Authoritative DNS
The nameserver service responsible for publishing the relevant zone records.
Return-Path
The received-message trace of the SMTP reverse path, useful when investigating the envelope 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