Webcentral SPF, DKIM and DMARC setup, step by step

For an existing Webcentral Titan Mail mailbox, obtain the DKIM TXT hostname and complete public value from Email Reputation, publish them at the authoritative DNS host, then select the publication checkbox and click Verify changes. The expected DKIM status is VERIFIED. Webcentral documents include:spf.titan.email for Titan SPF, but it must be incorporated into the correct existing envelope-domain policy, not pasted over other senders. Official DKIM instructions · Titan DNS instructions.

This guide is for a mailbox already using Webcentral Titan Mail with approved, working routing. Netregistry became Webcentral; that brand continuity does not mean every historical Netregistry mailbox is a Titan mailbox. The rebrand FAQ preserves existing products and plans, rather than documenting an automatic email-product migration. Webcentral rebrand FAQ.

OX Email, Microsoft 365, generic hosting/cPanel mail, a new Titan subscription, mailbox migration and other Titan resellers are outside this procedure. In particular, do not borrow DomainFactory's secureserver SPF or CNAME selectors simply because it also offers a Titan-powered product.

Before you change anything

Confirm the mailbox and domain in the Webcentral Hosting Panel. You need already-authorized administrative access and permission to edit the actual authoritative DNS zone. The documentation's example image shows a Pro plan, but the reviewed procedure does not establish Pro as a universal DKIM eligibility requirement. If your account does not expose the documented controls, ask Webcentral about the specific product instead of buying an upgrade or changing permissions as a workaround.

Record the intended visible From address, the existing mailbox sending route, and a controlled external recipient whose message source you can inspect. Preserve a copy of existing SPF, relevant DKIM records, DMARC, TTLs and delegation records. Identify legitimate applications that share the domain before editing its authentication.

Do not follow the DNS onboarding page's instruction to delete MX records for this authentication-only task. Those steps move inbound delivery to Titan. An already-working mailbox does not need a mail migration merely to publish its DKIM key. Leave MX, nameservers, DNSSEC, forwarding, catch-all settings, passwords and account privileges unchanged. Obtain separate approval and a migration plan if routing really needs to change.

The authoritative DNS host may differ from both Webcentral and the registrar. Confirm which nameservers currently serve the applicable zone before making a record edit. Editing a dormant zone produces no public authentication change.

Retrieve the account's DKIM TXT record

The current Webcentral DKIM procedure uses this route:

1. Sign in to the Hosting Panel using your existing approved access.
2. Open My Emails, locate the intended existing email account and select Manage.
3. Select Admin login.
4. Open Email Reputation.
5. Copy the DNS hostname and complete TXT record value displayed for this domain.

Keep the domain, record type, full hostname and value together in the change worksheet. The public key is supplied by this account's workflow. A generic selector such as default, a sample key or a value from another customer's screenshot is not a substitute. If a value is truncated or the domain is wrong, stop and obtain the complete correct record before publication.

The current Webcentral route explicitly asks for TXT, not a pair of CNAMEs. Do not convert the public key to a hostname target. Copy all tags and the entire public-key value exactly; do not add spaces inside key material or omit its ending. DNS tools may display one TXT record as several quoted character strings. Preserve one logical record with the complete intended value rather than creating several independent key records.

Only public DKIM data belongs in DNS. Webcentral/Titan manages the corresponding signing side; no private key should be requested, pasted into DNS or sent to a diagnostic website. DKIM key-record format.

Publish the TXT at the correct DNS owner

Use the exact issued owner, then translate it to your DNS editor's naming convention. Some editors expect a full domain name; others append the current zone to a relative label. Preview the resulting full owner before saving so the domain is not appended twice.

For illustration only, suppose an account issued SELECTOR._domainkey.mail.example.com. Replace SELECTOR with the real issued selector; this is not a publishable Webcentral value.

These are three alternative DNS-authority arrangements, not three records to publish. Use the zone actually authoritative for the issued owner. Retain existing NS delegations and coordinate with the delegated-zone operator if you cannot edit that zone. Do not remove a _domainkey delegation to make a parent-zone editor accept a key.

At the exact owner, inspect existing records and dependencies first. A CNAME cannot coexist with the required TXT at the same owner. Do not blindly delete it: it may serve an active sender or managed signing service. Resolve that conflict with the responsible operator and Webcentral before proceeding. Preserve other selectors used by other services or key rotation. This TXT workflow does not require HTTP proxy or CNAME-flattening adjustments; do not change unrelated web records.

After the approved edit, query the full issued TXT owner at its authoritative nameserver and through a public resolver. Compare the complete answer with the account value, allowing only legitimate DNS presentation differences such as quoting. An empty answer is not proof that the provider has no key: check authority, delegation, record name and DNS errors first.

Check SPF without replacing the domain's policy

Webcentral's Titan DNS guide publishes this example:

v=spf1 include:spf.titan.email ~all

This is a provider example, not a universal replacement policy. Its include is a published Titan authorization; the appropriate owner and complete resulting policy depend on the actual sending setup.

SPF evaluates the SMTP MAIL FROM domain, or HELO in relevant cases, rather than automatically checking the address displayed in From. Confirm the envelope identity from an authorized existing message or the controlled test below. Do not assume Webcentral supplies a customizable Return-Path or that every mailbox route has the same envelope identity. SPF specification.

• If the applicable owner already has an SPF TXT policy, review it and merge the needed Titan authorization into that one policy with the domain owner's approval. Preserve legitimate existing senders and the approved final qualifier.
• Do not create a second v=spf1 record, append a second policy string or replace a restrictive policy with the example's ~all simply to match the tutorial.
• If no SPF exists at the evaluated domain, the example is appropriate only after confirming this is the correct owner and Titan is the only required authorization. Include all actual senders in the approved design.
• Check the limit of 10 evaluated DNS-dependent terms, including nested mechanisms and redirects. It is not merely a limit of 10 visible includes. An all mechanism makes a redirect modifier ineffective.
• If mail uses an envelope domain you do not control, do not try to fix its SPF by adding records to your visible From domain. Confirm the route with Webcentral instead.

In the documented administration interface, Connect Domain shows DNS status for MX and TXT. It can be useful for checking the established setup, but do not use it as permission to replace working MX. Its VERIFIED labels and the Email Reputation DKIM status are separate observations; neither proves authentication of a delivered message.

Complete Webcentral's DKIM verification

Once the correct TXT is published:

1. Return to Email Reputation for the same domain.
2. Select I've added TXT records in my DNS control panel only after confirming publication.
3. Click Verify changes.
4. Look under Current status for DKIM Record: VERIFIED.

The current instructions and actual verification screenshot support this checkbox-and-button sequence. The procedure describes enabling DKIM through this workflow; it does not document an additional signing toggle. Do not invent a separate “Start authentication” step from another provider.

Webcentral says changes can take up to 24 hours to propagate, usually less. That is not a guarantee or a reason to ignore a wrong record. Check public authoritative answers and resolver caching before repeating verification. If the correct record is visible but status remains unresolved, provide Webcentral with the domain, public owner/value, timestamp and non-sensitive diagnostic results through an approved support channel. Never include mailbox passwords or private keys.

Preserve DMARC and check alignment

Read the existing direct and applicable inherited DMARC policy before proposing an edit. Keep its protection level, alignment modes and authorized report destinations. A missing direct _dmarc answer on a subdomain does not establish that no policy applies; inherited policy or a DNS lookup failure may explain it.

Only when no applicable policy exists, the owner approves monitoring, and a monitoring plan is in place, a first policy may use this minimal TXT value:

v=DMARC1; p=none

Publish at _dmarc relative to the intended policy domain's authoritative zone, for example full _dmarc.mail.example.com for mail.example.com. In the parent example.com zone the relative name would be _dmarc.mail; in a delegated mail.example.com zone it would be _dmarc. Confirm the actual authority rather than placing both. This conditional example does not request aggregate reports or replace an existing policy. Do not duplicate DMARC, downgrade protection or use obsolete pct rollout advice. Current DMARC specification.

When the report destination's Organizational Domain differs from the Organizational Domain of the domain where the policy was found, the receiver generating aggregate reports must check DNS authorization. A destination within that same Organizational Domain is excepted. RFC 9990, section 4. Separately obtain the domain owner's approval for report-data sharing and destination privacy; DNS authorization is not that approval.

For DKIM alignment, compare the actual signature's d= with the visible From domain under adkim. Relaxed alignment compares Organizational Domains; strict alignment requires an exact domain match. SPF alignment similarly compares the authenticated MAIL FROM domain under aspf. A child envelope domain may align in relaxed mode but not strict mode. This guide does not promise strict alignment or prescribe a custom envelope setting that Webcentral has not documented.

Verify an actual Titan mailbox message

Use an existing approved sending route for the intended Webcentral Titan mailbox. Send a harmless, authorized test to a controlled external recipient, without customer data, mailing lists or forwarding loops. Do not reroute through Gmail, an application SMTP service or a different mailbox product just to obtain a passing result. Test additional legitimately used routes separately if they matter to your acceptance criteria.

At the recipient, inspect the original full message source and authentication results generated within the receiving service's known processing boundary. Confirm how that service handles externally supplied Authentication-Results fields. A familiar authserv-id string or topmost header placement alone cannot distinguish genuine receiver results from attacker-inserted text. Ignore untrusted result fields. Authentication-Results trust guidance.

Record these observations:

A DMARC pass achieved only through SPF is not successful DKIM acceptance. A DNS answer or VERIFIED dashboard is not delivered-message proof. Conversely, a valid DKIM signature can be unaligned and therefore insufficient for DMARC. See raw DKIM results versus aligned DKIM policy results.

Retain the public record snapshot, provider status and redacted test evidence separately. Authentication success does not guarantee inbox placement; recipient policy, reputation and content still affect delivery. No live customer test was performed in preparing this guide.

Troubleshooting by symptom

Sources and scope of verification

This is not a provider publication date. Current Webcentral operative instructions and three relevant interface screenshots were inspected; DNS, accounts, sending and website deployment were not tested.

• Webcentral: setting up DKIM for Titan Mail.
• Webcentral: Titan DNS records and status.
• Webcentral: managing Titan Mail accounts.
• Webcentral: Netregistry rebrand FAQ.

This is an evidence-based configuration guide, not an automated configuration tool or certification of a particular sender-and-DNS combination. Customer-specific changes require their own approved values, execution and delivered-message validation.