123 Reg SPF, DKIM and DMARC setup, step by step

Quick answer: Use 123 Reg's DNS editor only when it serves the authoritative zone. Publish the sending service's exact TXT or CNAME instructions, preserve existing policies, and then return to the sender to complete activation and verify received mail. Registering a domain at 123 Reg does not establish that 123 Reg hosts its DNS or signs its email.

This guide covers DNS publication, not configuration of 123 Reg mailboxes, Microsoft 365, a hosting control panel or a private mail server. Those senders supply their own authentication settings. No account changes, DNS edits, live message tests or publication were performed for this guide.

Before opening the editor

Identify the exact sending application, intended visible From domain, actual SMTP MAIL FROM domain and provider-issued DKIM selector. Obtain the complete public records from the authorized sender account or support channel, including record type, full owner, value and activation instructions. Do not request private signing keys or copy another customer's public key.

Find the authoritative nameservers for the relevant zone. If they belong to another DNS provider, publish there instead. 123 Reg explicitly warns that changes in its Control Panel do not take effect when its nameservers are not authoritative. A registrar account is not proof of DNS authority. 123 Reg TXT publishing

Before saving anything, inventory existing SPF, DKIM, DMARC, verification and delegation records. Record the current values and TTLs, the proposed diff, the approving owner and the restoration plan. A shared domain may serve staff mail, billing, support and marketing. A new sender must not erase those services' authorizations.

Do not migrate nameservers, change MX routing, modify DNSSEC, switch accounts or remove delegations merely to match this guide. If the sender's packet includes A, MX or NS changes, separate their consequences from authentication publication. Compare their exact targets with an approved routing or delegation plan; stop if that plan is missing. An example packet does not authorize redirecting inbound email or transferring DNS authority.

Open the current 123 Reg DNS editor

The current documented path is:

1. Sign in to the 123 Reg Control Panel.
2. In All Products and Services, select Manage All beside Domains.
3. Choose the intended domain from the domain list.
4. Select DNS, then Add New Record when a new owner/record is genuinely needed.

For TXT, choose TXT, enter Name and the complete Value, retain the appropriate TTL, then Save. The TXT guide recommends the default TTL. If you already have the applicable SPF or DMARC record, update that record through the available editor rather than using Add New Record to create a duplicate. If the account interface differs materially, stop and confirm the current account-specific controls rather than following a guessed legacy path. 123 Reg TXT field instructions

The editor is a publication mechanism. It does not decide which service may send mail, generate a third-party SaaS key, or activate DKIM in that service.

Map full owners to the correct zone

Use the sender's complete DNS owner as the acceptance criterion, then derive the relative Name for the authoritative zone. The names below are deliberately illustrative. s2026 is not a universal selector and example.com is not your domain.

A delegated zone may be hosted elsewhere; this table is DNS naming logic, not a claim that every delegated namespace is available as a separate zone in your 123 Reg account. Publish at the actual authority. Preserve NS delegations and shared dependencies. If the required owner is unsupported in the current editor, coordinate a supported arrangement rather than deleting the delegation.

Check whether the interface appends the selected zone. An accidental s2026._domainkey.example.com.example.com is a different owner and will not authenticate the intended signature. Do not shorten a sender's multi-label owner to only the selector.

Publish SPF as one evaluated policy

SPF evaluates the SMTP MAIL FROM domain, or HELO where applicable, not automatically the visible From. Determine the evaluated identity from the sending route and later from a controlled received message. An apex record does not authorize an unrelated provider-owned envelope domain, and a child envelope identity is not automatically strict-aligned with the parent From domain.

There must be one TXT policy beginning with v=spf1 at the evaluated owner. Other unrelated TXT records can coexist. Merge the new, authorized sender into that policy without deleting legitimate mechanisms or changing the terminal qualifier by accident. If the policy uses redirect, review its effect: an all mechanism causes redirect to be ignored. Do not paste a second complete SPF record beside the first.

Count the full evaluation path against the ten DNS-dependent-term limit, including nested mechanisms and modifiers. It is not simply a limit of ten visible include strings. Preserve the sender's current authorization rather than copying an IP snapshot. -all expresses fail, not a guarantee that every receiver rejects a message; ~all is not a universal requirement. SPF processing and limits, RFC 7208

123 Reg's SPF help supplies a specific secureserver.net example for 123 Reg Mail. Do not add it merely because DNS is hosted here. For another sender, use that sender's verified instructions. The same help page warns against multiple SPF records. 123 Reg SPF scope and publishing instructions

Publish the DKIM record type the sender supplied

When the sender supplies TXT

Choose TXT and publish the full tagged public-key value at the supplied selector owner. Preserve the complete v=, k= and p= content when provided; do not truncate the key, paste a screenshot's sample or include a private key. A long TXT answer can be displayed as several quoted character strings that are concatenated as one DNS record. That is different from multiple independent TXT records. Verify the reconstructed value rather than copying display quotes or adding spaces between chunks. DKIM TXT concatenation, RFC 6376 section 3.6.2.2.

123 Reg's DKIM page describes TXT publication and illustrates a hostname. Its example is not your provider-generated selector. Use the exact owner supplied for your sending account, with the standard _domainkey structure where required. The page does not establish that a 123 Reg mailbox signs automatically. 123 Reg DKIM TXT publishing

When the sender supplies CNAME

Choose CNAME, put the required relative owner in Name, and the exact sender-supplied target in Value. 123 Reg instructs you to end the destination with a full stop and recommends the default TTL, normally 3600 seconds. Save and inspect the resulting full owner and target. Do not convert this instruction into TXT or substitute a website-forwarding feature. 123 Reg CNAME publishing

A CNAME owner cannot also hold conflicting TXT, A, AAAA, MX or another CNAME. Check existing usage before replacing a selector. 123 Reg states that its nameservers do not support @ CNAME records. Do not force a required apex alias into the wrong type or alter MX/NS as a workaround; resolve the unsupported shape with the sender and DNS administrator.

The required end state is the sender's literal public alias, not an HTTP proxy address or flattened A/AAAA response. These 123 Reg sources do not establish a customer flattening or proxy toggle, so do not invent one. If another authority or intermediary is involved, check applicable per-record, whole-zone, apex and same-zone processing there. Use DNS-only and turn off relevant per-record flattening where supported; ensure zone-wide processing does not suppress the alias. Do not blindly disable a shared global setting. If mandatory processing cannot preserve the required CNAME, stop and coordinate a supported configuration.

Preserve DMARC policy and approved reporting

DMARC requires a passing authenticated SPF or DKIM identity to align with the visible From. Relaxed alignment uses the Organizational Domain relationship; strict alignment requires exact equality. For visible From example.com, a passing intended signature with d=mail.example.com aligns under relaxed DKIM alignment but not strict alignment; a passing signature with d=example.com aligns under either mode. Keep direct and applicable inherited policy, existing adkim/aspf choices, and approved report destinations. DNS editing is not permission to lower an enforced policy. DMARC alignment and policy, RFC 9989

Only if there is no direct or applicable inherited policy, the owner approves a monitoring start, and a review plan exists, this illustrates a first TXT record:

Type: TXT
Full owner: _dmarc.example.com
Name in the example.com zone: _dmarc
Value: v=DMARC1; p=none; rua=mailto:OWNER_APPROVED_REPORT_MAILBOX

Replace only the mailbox placeholder after mailto: with the actual approved address, or omit rua until reporting is arranged. Do not insert a second mailto: or copy a third party's reporting recipient. Do not create a duplicate policy. Use the child-zone mapping table when the policy owner is below the parent domain, without silently overriding inherited protection.

For a report destination in a different Organizational Domain from the policy domain, the report-generating receiver must check DNS authorization. A destination in the same Organizational Domain is excepted. Follow the report service's exact authorization packet; DNS authorization is not a substitute for the owner's consent to share report data. RFC 9990 section 4

Monitoring does not request quarantine or rejection. Do not increase enforcement until all legitimate senders are assessed, and do not use obsolete pct rollout assumptions.

Verify authoritative publication before testing mail

These are read-only query shapes, not example successful results. Replace example.com, s2026 and AUTH_SERVER with the exact domain, selector and authoritative server established for your change:

dig NS example.com
dig @AUTH_SERVER TXT example.com +norecurse
dig @AUTH_SERVER TXT s2026._domainkey.example.com +norecurse
dig @AUTH_SERVER CNAME s2026._domainkey.example.com +norecurse
dig @AUTH_SERVER TXT _dmarc.example.com +norecurse

Use TXT or CNAME according to the supplied DKIM record, not as interchangeable alternatives. Check the answer owner, type, complete content and authoritative response. For an alias, query its actual target and confirm the appropriate public key resolves there. Query the authority for a delegated child instead of assuming the parent's nameservers answer it.

Compare all authoritative servers if answers disagree, then an independent recursive resolver. Correct authoritative publication can coexist with cached old data; previously absent records can be negatively cached. 123 Reg's 24–48-hour guidance is not proof that waiting fixes wrong authority or malformed data. Treat NXDOMAIN, SERVFAIL, missing answers and unexpected targets as distinct diagnostics.

Keep the saved change and DNS evidence. If a rollback is necessary, restore only the approved changed records after checking that no later legitimate change would be overwritten. Do not erase the zone or remove unrelated selectors.

Complete sender activation and require received-message evidence

Return to the actual sending service and complete its documented domain verification and DKIM signing activation. Publishing records in 123 Reg does not do that work. If the service does not supply a supported native signing route, do not invent one or silently substitute a different SMTP provider.

Send a fresh message through the real intended application to a controlled external mailbox. Record the visible From, envelope identity, DKIM d= and s=, provider verification state and receipt time. For newly configured branded DKIM, require the intended signature to pass and align under the current policy, plus trusted receiver dmarc=pass. A rewritten provider From, an unrelated signature, or an SPF-only DMARC pass does not establish the intended branded DKIM route.

Use Authentication-Results produced inside the receiving service's known processing boundary. Verify its documented treatment of incoming externally supplied results through trusted original-message or administrative tooling. Header position and a matching authserv-id string alone are not trustworthy; ignore attacker-inserted fields. Authentication-Results trust, RFC 8601

Investigate SPF fail, transient DNS temperror and policy permerror separately, even if aligned DKIM makes DMARC pass. Separate raw signature verification from alignment: EmailAuth's raw DKIM and aligned policy results explains why both matter. No DNS result guarantees delivery or inbox placement.

Troubleshooting and common questions

The record saved but nobody can find it. Check the active authoritative service, delegated zone, actual saved owner and doubled suffix before blaming caches. A saved record in an unused 123 Reg zone has no effect.

CNAME cannot be added. Look for an occupied owner or unsupported apex CNAME. Preserve the existing dependency and coordinate a different supported selector or arrangement with the sender; do not delete live records merely to silence the warning.

TXT appears in quotes or multiple chunks. Inspect the reconstructed single value. Representation by a lookup tool is not proof of extra stored punctuation, and separate records are not equivalent to chunks of one record.

DNS passes but email fails. Confirm activation in the sender, the actual selected From/route, matching selector/key and receiver trust. Then inspect alignment and any message modification. DNS publication alone cannot demonstrate signing.

Should I use 123 Reg's SPF value for Microsoft 365 or my CRM? No. Use the actual sender's current authorization and account-issued DKIM records, preserving the shared domain's other legitimate senders.

When is the work complete? When the approved records are authoritative, the sending service is activated, and controlled messages from each affected route meet the intended authentication and alignment criteria. Keep those results and retest after DNS migrations, sender changes or key rotation.